OAuth 2.0 정리

소셜 로그인을 하기 위해서는 OAuth 2.0에 대한 기본적인 이해가 필요합니다.

OAuth 2 IN ACTION 책을 기반으로 OAuth 2.0의 간략한 내용을 정리하고, 이후에 Spring을 이용하여 실제 OAuth 2.0을 테스트 하는 코드를 작성할 예정입니다.

<OAuth 2 IN ACTION>

OAuth 2.0 스펙에는 다음과 같이 정의되어 있습니다.

OAuth 2.0 SPEC Abstract

The OAuth 2.0 authorization framework enables a third-party

application to obtain limited access to an HTTP service, either on

behalf of a resource owner by orchestrating an approval interaction

between the resource owner and the HTTP service, or by allowing the

third-party application to obtain access on its own behalf.

간단하게 정리하자면 Client가 Resource Owner를 대신해 Resource Server의 Protected Resources에 접근 하는 것을 승인하는 인가 프레임워크입니다.

OAuth를 활용하면 사용자의 Google이나 Facebook의 정보들을 Client가 받아오거나 조작할 수 있게 되는거죠.

OAuth는 다음 4가지의 역할을 정의합니다.

Roles

- Resource Owner 

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

- Client

An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

- Authorization Server

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

- Resource Server

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

Resource Owner 는 Resource Server에 자신의 정보를 가지고 있는 사용자를 말합니다. 

Client는 Resource Owner를 대신해 Resource Server의 Protected Resources에 접근하는 소프트웨어입니다. 

Authorization Server는 Resource Owner의 인가를 받은 Client에게 Access Token을 발급하는 서버입니다.

Resource Server는 Google, Facebook과 같이 Resource Owner의 정보를 가지고 있는 서버입니다. 일반적으로 Authorization Server와 같은 서버입니다. (하나의 Authorization Server에서 다수의 Resource Server에 접근할 수 있는 Access Token을 발행할 수도 있습니다.) 인가 받은 Client의 Access Token을 받아 검증 후 해당하는 Protected Resources를 응답해 줍니다.

그리고 가장 중요한 OAuth 2.0의 흐름은 다음과 같습니다.

Protocol Flow

(A) Client는 Resource Owner에게 인가를 요청하고,

(B) Resource Owner가 인가를합니다.

(C) Client는 인가 받은 권한을 Authorization Server에 전달하고,

(D) Authorization Server는 Client에게 Access Token을 발급합니다.

(E) Client는 발급 받은 Access Token을 Resource Server에 전달하면,

(F) Resource Server는 Protected Resources를 Client에게 보내줍니다.

A-B 과정에서 Client는 Authorization Code를 발급 받는데, 이는 Access Token을 발급 받기 전 Resource Owner가 Client에게 접근 권한을 위임했다는 것을 나타냅니다. 

C-D 과정에서 Client는 Authorization Server에 Authorization Code와 Client ID, CIient Secret를 전달하여 Access Token을 발급 받을 수 있습니다.

E-F 과정에서 Client는 Access Token을 통해 해당하는 Protected Resource를 응답 받을 수 있습니다.

다음 포스트에서는 OAuth 2.0을 활용하여 Google의 Email 주소를 받아오는 테스트 코드를 작성해 보도록 하겠습니다.

OAuth 2.0으로 Google의 Email 주소 받아오기(1)