OAuth2.0

프로젝트에서 구글, 카카오 연동이 필요해 OAuth에 대해 공부했다. 유저 아이디만 필요했기에 OAuth가 아닌 OpenId Connect가 필요한게 맞는 것 같다. OAuth에 대해 공부한 내용을 아래 정리한다.

OAuth란 무엇인가

OAuth는 ‘Open standard for acess delegation’의 축약이다. 사용자가 가입된 서비스의 정보에 다른 서비스의 접근을 허용할 때, 직접 아이디와 패스워드를 타 서비스에 넘길 필요 없이 안전하게 권한을 부여하는 방식을 정의한 프토토콜이다.

OAuth 용어 정리

client: 유저의 정보에 접근하고 싶은 서버이다.

resource owner: client가 접근하고 싶은 정보의 주인, 일반적으로 유저이다.

authorization server: 인증을 진행하는 서버

resource server: client가 접근하고 싶은 정보를 가지고 있는 서버, 토큰이 있어야 접근 가능하다.

Flow

Authorization Code Grant

 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)


A: client가 resource owner의 정보에 접근하기위해 브라우저를 authroization endpoint로 이동시킨다. 인증 후 돌아올 redirection uri와 client identifier(public key), request scope를 함께 전달한다. 

B: 유저가 authorization server에서 client의 요청을 확인하고 동의한다.

C: authorization code를 발급받고 client에 전달한다.

D~E: authorization code를 토큰으로 교환한다.

인증서버와 user agent의 통신은 front channel에서 이뤄지기에 A~C과정은 CSRF에 취약하다. 이 과정에서 토큰을 발급한다면 redirection uri를 변경해 가로챌 수 있을 것이다.

back channel에서 authorization code를 토큰으로 교환하는 과정은 인증이 가능하다. client가 secret key로 서명할 수 있기에 authorization server는 public key로 제대로된 client와 소통하고 있는지 확인할 수 있다.

스마트폰 앱과 같이 client secret이 기기에 포함되어 노출될 위험이 있는 경우에 access code 탈취는 위험하다. 이를 방지하기 위해 (A)과정에서 code_verifier를 생성해 토큰 발급시 확인하는 PKCE 프로토콜이 함께 사용된다.

Reference Token vs Self Encoded Token

Referece token

토큰은 인증을 위한 문자열일뿐 정보를 포함하지 않는다. 토큰과 정보를 매치할 저장소가 필요하다. 정보를 직접 관리할 수 있어 토큰 삭제, 유저 정보변경 등 데이터 정합성을 유지할 수 있는 장점이 있다. 인증에 저장소와 통신이 필요하기에 네트워크 지연이 생기고, 확장성이 떨어지는 단점이 있다.

Self encoded token

JWT이 대표적인 예이다. 토큰 자체에 정보를 포함한다. 인증서버의 public key를 알면 토큰의 유효성을 검증할 수 있어 네트워크 트래픽이 필요 없고, 확장성이 높다. 저장된 정보는 발급된 시점에서만 유효한 정보기에 데이터 정합성이 맞지 않을 수 있는 단점이 있다.