OAuth2

OAuth2

아래 내용은 다음 링크를 참조하여 작성하였습니다.

RFC 6749: The OAuth 2.0 Authorization Framework

개요

A에서 이미 인증을 한 상태, B에서도 같은 OAuth방식으로 인증을 하려한다. 이 때 ID, 비밀번호로 로그인하는 것이 아닌, B가 A 어플리케이션에게 인증정보를 요청한다. A 어플리케이션은 사용자에게 B에게 인증 정보를 전달해도 되는지 묻고 이를 적용한다.

---

OAuth 2.0 용어

EX] React Web을 OAuth 2.0 인증(구글 로그인)을 하려한다.

용어	설명	예시
자원 Resource Server)	OAuth 2.0 서비스를 제공하고 자원을 관리하는 서버	Google
자원 소유자 (Resource Owner)	Resource Server의 계정을 소유하고 있는 사용자	사용자
클라이언트 (Client)	Resource Server의 API를 사용하여 데이터를 가져오려고 하는 사이트	React Web
인가 서버 (Authorization Server)	Client가 Resource Server의 서비스를 인증할 수 있게 인증하고 토큰을 발행해주는 서버	Google (OAuth2.0 Server)
Access Token	Resource Server에 자원을 요청할 수 있는 토큰
Refresh Token	Authorization Server에 Access Token을 요청할 수 있는 토큰

---

기본 흐름

다음은 Resource Server로 부터 Resource를 얻기 까지의 기본 흐름이다.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

(A) Client가 Resource Owner에게 인가를 요청한다. Authorization은 Resource Owner가 직접 만들 수도 있고, Authorization Server를 통해 간접적으로 만들 수 있다.

EX] React Web에서 Google Login을 하기 위해 사용자에게 요청한다. 사용자는 직접 Authorization을 만들거나 Google (OAuth 2.0 Server)를 통해 인가를 받는다.

(B) Client는 아래 서술할 4가지 승인 유형 중 하나를 사용하거나, 확장 승인 유형을 사용하여 자격 증명 즉 Authorization을 받는다.

(C) Client는 Authorization Server로 인증하고 Access Token을 요청한다.

(D) Client는 Authorization Server로부터 Access Token을 받는다.

(E) Client가 Resource Server에게 Access Token을 이용하여 Protected Resource를 요청한다.

(F) Resource Server가 Access Token을 검사하고 유효한 경우 요청을 처리한다.

---

Authorization 승인 유형

Client가 Access Token을 얻기 위한 매커니즘이다.

매커니즘	설명
인가 코드 승인(Authorization Code Grant)	Authorization Code는 Client와 Resource Owner간의 중개자인 Authorization Server를 통해 Access Token을 얻는 방식이다. Client가 Resource Owner에게 직접 Authorization요청하는 대신 Client는 User-Agent를 통해 Resource Owner를 Authorization Server로 보낸다.
암시적 승인 (Implicit Grant)	Client가 중개자 없이 Resource Owner에게 바로 Access Token을 요청하는 방식이다. 간편하지만 Access Token이 외부로 노출될 수 있다.
자원 소유자 암호 자격 승인 (Resource Owner Password Credentials Grant)	Resource Owner의 자격증명(username 과 password)을 통해 Access Token을 얻는 방식이다. Resource Owner와 Client 사이 높은 신뢰도를 가질 때만 사용해야 한다. (Client가 OS의 일부거나, 높은 권한을 가진 Application일 때)
클라이언트 자격 승인 (Client Credentials Grant)	Client 자격은 Resource Server로 부터 받게 될 데이터들이 Client의 통제 하에 사용되거나, Client 자체가 Resource Owner일 때 사용할 수 있다.

---

Token

다음은 Refresh Token을 이용하는 흐름이다.

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

(A) Client가 Authorization Server에게 인가 승인 요청을 한다.

(B) Client는 Authorization Server로부터 Access Token과 Refresh Token 2개를 받는다.

(C, D) Authorization을 통해 받은 Access Token을 사용하여 Reosurce Server에 Resource를 요청하여 데이터를 받는다.

(E, F) Resource Server에게 요청을 했을 때 Access Token이 만료가 된다.

(G, H) Access Token이 만료가 되면, Authorization Server에게 Refresh Token을 통해 Access Token을 다시 발급받는다.