✔ OAuth란,

🧐 외부 소셜 계정을 기반으로 특정 서비스(원티드)에 간편히 회원가입을 한 경험이 있나요?
클릭 한 번으로 쉽게 가입도 가능할 뿐만 아니라, 특정 서비스(원티드)에서는 페이스북, 애플, 구글 등에서 제공하는 기능을 간편히 사용할 수 있습니다! 이때 사용되는 것이 OAuth입니다.

• 구글, 페이스북 등 다양한 플랫포의 특정한 클라이언트의 데이터에 접근하기 위해서 서비스가 해당 클라이언트의 접근 권한을 위임받을 수 있는 표준 프로토콜.

• 즉, 특정 서비스를 이용하는 유저의 타사 플랫폼 정보에도 접근하기 위해 권한을 타사 플랫폼으로부터 권한을 위임받는 것이다.

✔ OAuth 참여자

1. Client

Resource Server의 자원을 이용하고자 하는 서비스. 보통 우리가 개발하려는 서비스가 됨.
OAuth를 사용해 서비스 제공자에게 접근하는 웹사이트 or 애플리케이션이라고 생각하면 됨.
*Authorization Server의 입장에서는 우리가 개발한 서비스가 클라이언트임을 헷갈려선 안된다! Resource Owner와 구분짓자.

2. Resource Owner

웹 서비스를 이용하려는 실제 유저. 즉, 우리가 개발한 서비스를 이용하면서, 구글/페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자.

3. Authorization & Resource Server

• Authorization Server

  인증에 사용할 권한을 부여해주는 서버(아래의 이미지에서는 PAYCO 서버). Resource owner는 이 서버로 ID, PW를 넘겨서 Authorization code를 발급받으며 서비스를 넘겨줌. 서비스는 다시 Authorization server로 넘기면 액세스 토큰을 발급받는다.(로그인 성공)

• Resource Server(API server)

  사용자의 개인정보를 가지고 있는 어플리케이션. 페이스북/구글 등이 이에 속함. 액세스 토큰을 통해 자원에 접근할 수 있는 권한을 확인한다.

  Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이라고 한다.

✔ OAuth 동작과정

1. Resource owner. 즉, 사용자가 맨 처음 개인 서비스 웹사이트에서 로그인 버튼(Google, Kakao, FB, Twitter)을 누른다.
2. 서비스는 해당 Authorization server에 Authorization code 발급 요청을 보낸다.
3. Authorization server는 사용자에게 로그인 페이지를 제공하며 인증(ID/PW)을 요청한다.
4. 사용자는 로그인 정보를 Authorization server에 보내는데 이 때 다음과 같은 상황이 발생한다.

+) 4-1. 사용자 입장에서 서비스는 자신의 정보를 대신 사용하기 때문에 서비스는 사용자에게 어떠한 자원을 사용하는지 명시하고 사용자의 동의를 구한다.

5. 그 후 사용자가 인증은 했지만 Resource server 입장에서 아직 서비스가 정말 사용자에게 서비스를 제공하는지 확신할 수 없으므로(서비스를 아직 신뢰할 수 없으므로) 사용자에게 Authorization code를 전해준다.
6. 사용자는 받은 Authorization code를 다시 서비스에게 전달해 준다.
7. 서비스는 사용자에게 받은 Authorization code를 Authorization server에 전달해 주며 Access token을 요청한다.

5~7의 과정을 거치는 이유? Authorization server 입장에서 서비스를 아직 신뢰할 수 없기 때문에 인증을 마친 사용자에게 Authorization code를 전달후 사용자는 서비스를 신뢰하므로 받은 Authorization code를 전달해 주며 서비스는 이를 다시 Authorization server에 전달해 서비스로의 신원을 확인시켜 준다.

8.서비스의 확인을 마친 Authorization server는 마침내 Access token을 서비스로 발급한다. 이때부터 서비스는 발급받은 Access token을 자체적으로 저장, 관리해야 한다.
9. 인증 완료 및 로그인 성공.
10. 사용자가 서비스가 필요할 경우 Access token과 함께 서비스 서버에 요청.
11. 사용자로부터 요청을 받은 서비스는 API server에 Access token과 함께 호출한다.
12. API server는 Access token 검증 후 자원을 서비스 서버에 제공한다.
13. 서비스 서버는 제공받은 자원을 가공해 사용자에게 서비스를 제공한다.

• 참고 : https://gyoogle.dev/blog/web-knowledge/OAuth.html, https://hudi.blog/oauth-2.0/, https://velog.io/@kon6443/CS-OAuth-2.0-OpenID-Connect-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EC%B0%A8%EC%9D%B4-%EA%B3%BC%EC%A0%95-wi6edsx3