Oauth2.0

OAuth란

OAuth는 Open Authorization의 줄임말로, 액세스 위임을 위한 개방형 표준 인가 프로토콜이다. 해당 인증 바에식은 서비스 제공 업체(네이버, 깃허브 등)의 정보를 비밀번호 없이 정보에 대한 액세스 권한을 부여할 수 있는 안전한 방식으로, 현재 많이 사용하는 로그인 방식이다.

위의 사진처럼 요즘 흔하게 볼 수 있는 로그인 방식이다. 어떠한 애플리케이션을 이용하고자 할 때, 구글, 카카오와 같은 제 3의 서비스에서 사용자가 가지고 있는 계정의 정보를 사용자가 허용하는 범위에 한해서 가져올 수 있다.

Authorization과 Authentication

Authentication(인증)과 Authorization(인가)의 개념에 대해서 잘 모르고 있는 경우가 많다. 크게 보면 둘 다 같은 단어 같지만, 두 개념을 세부적으로 알게 되면 큰 차이가 있기 때문에 이 점부터 짚고 넘어가야 할 필요성이 있다.

Authentication(인증) : 해당 사용자가 자신이 주장하는 그 사람인지 확인을 하는 것 Authorization(인가) : 해당 사용자가 리소스에 접근할 수 있는 권한을 부여하는 것

예를 들어 편의점에 술을 사러 간다고 생각해보자. 편의점에는 술을 사기 위해서는 성인이 되어야 한다. 그렇기에 편의점 알바는 손님에게 ‘민증 검사’를 요구한다. 민증을 통해 해당 손님이 자신이 주장하는 ‘성인’이 맞는지 민증을 통해 ‘인증’하고 알바생은 이를 확인한다. 이 과정이 인증이다. 민증을 통해 성인임이 확인 되면, 해당 손님에게는 술을 살 수 있는 권한 이 주어진다. 이것이 인가이다.

따라서 다시금 OAuth의 풀 네임을 직역해보았을 때, 개방된 인가라고 생각할 수 있다. 특정 제 3의 서비스들은 인증이 완료되면, 해당 서비스에게 유저에 대한 정보를 넘겨주는 OAuth의 의미를 생각해볼 수 있다.

OAuth의 핵심 주체

OAuth에서의 주체는 크게 세가지, 작게 나누면 네 가지 정도로 나뉜다.

Resource Owner(or User)
- 리소스를 소유한 사용자로, 애플리케이션의 리소스 공유 요청을 허가
- 서비스를 이용하려는 사용자
Client(or Consumer)
- 사용자의 허가를 받아 사용자의 리소스에 접근할 수 있도록 요청하는 응용 애플리케이션
- 제공하려는 서비스
Server(or Provider)
- 사용자의 허가를 검증하고, 클라이언트에 응용 애플리케이션에 보유한 사용자의 리소스를 공유하는 서버
- 일반적으로 허가를 담당하는 검증 서버(Authorization Server)와 실제 사용자 리소스를 보유한 리소스 서버(Resource Server, or API Server)로 분리되어 있음
- 제3의 서비스(네이버, 카카오, 구글 등)

작동 방식

 +--------+                               +---------------+
 |        |--(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 ---|               |
 +--------+                               +---------------+

프로토콜 자체의 플로우는 이와 같이 구성된다. 클라이언트는 인증 요청을 보내고, 유저가 인증을 완료하면 클라이언트측에 인증이 제대로 완료되었음을 알린다. 인증이 제대로 완료되면 클라이언트는 인증 서버에 인증이 확인되었음을 알리고, 엑세스 토큰을 얻는다. 엑세스 토큰을 얻게 되면 클라이언트는 리소스, 즉 유저의 정보를 가지고 있는 서버에 엑세스 토큰을 보내 유저가 명시한 제한된 리소스를 가져올 수 있다.

리소스 소유자(이하 유저)가 클라이언트 서비스를 이용하고자 이용 요청을 보냄
클라이언트는 검증(Authorization) 서버에 액세스 토큰을 요청
검증 서버는 유저에게 인가(Authentication) 동의를 요청
- 여기에서 유저는 어느 정도의 범위를 해당 서비스(client)에게 제공할 지 직접 선택할 수 있다.
유저는 인가(Authentication) 동의를 응답
검증 서버는 리소스에 접근할 수 있는 액세스 토큰을 생성해 클라이언트로 전송
클라이언트는 액세스 토큰을 저장
클라이언트는 액세스 토큰을 가지고 리소스 서버에 요청
리소스 서버는 액세스 토큰의 유효성을 파악하고 나서, 요청한 리소스를 클라이언트에 응답
클라이언트는 유저에 서비스 이용을 응답

과 같이 이루어지는 것이다.

엑세스 토큰을 가져오는 방식

엑세스토큰의 경우 네 가지 방식을 통해 이루어진다. 현재 Implicit 방식과 Password Grant(Resource Owner Credentials) 방식의 경우 Deprecated 상태이며, 가장 많이 쓰이는 방식은 Authorization Code 방식이다. 비밀번호를 직접 넘겨주지 않으면서도 엑세스 토큰을 바로 클라이언트로 보내는 방식이 아닌 Code를 받아 다시 인증 서버로 보낸 후에 엑세스 토큰을 받아오는 방식이 한 단계를 더 거치면서 보안상으로 더욱 이점을 가지기 때문이다.

엑세스 토큰에 담겨있는 정보

인증 서버로부터 받아오는 엑세스 토큰은 위와 같은 정보들을 담고 있다.

Authorization Code 방식 더 알아보기

그렇다면 현재 많이 사용되고 있는 Authorization Code방식에 대해 자세히 알아보자.

     +----------+
     | 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)
 
   Note: The lines illustrating steps (A), (B), and (C) are broken into
   two parts as they pass through the user-agent.
 
                     Figure 3: Authorization Code Flow

Authorization Code의 방식은 클라이언트가 인증 서버에 자신의 서비스를 등록한 뒤, 해당 서비스의 코드와 redirect URI를 보내면서 시작된다. 여기서 redirect URI는 인증 서버에서 자체적인 로그인 페이지를 띄우기 때문에 유저가 로그인이 된 후 인증이 완료되었을 때 다시 redirect URI로 보내게 된다. 여기서 인증이 완료되었을 경우 redirect URI에서는 code를 URI에 붙여서 보내주는데, 이 code를 클라이언트가 인증 서버에 다시금 보내면서 엑세스 토큰을 받을 수 있다. 여기서 계속 엑세스 토큰을 클라이언트에서 들고 있는 것보다 리프레시 토큰을 통해 엑세스 토큰에는 만료 시간을 두고 만료되면 리프레시 토큰을 통해 엑세스토큰을 재발급 받는 방식이 보다 안전하기 떄문에 인증 서버에서도 이러한 방식을 사용한다. 따라서 리프레시 토큰 또한 함께 받을 수 있다.

+--------+                                           +---------------+
  |        |--(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        +---------------+
 
               Figure 2: Refreshing an Expired Access Token

엑세스 토큰이 발급되면, 클라이언트는 이 엑세스토큰을 가지고 사용자의 정보를 담고 있는 리소스 서버에 엑세스 토큰과 함께 정보를 요청하는 API를 보낸다. 리소스 서버는 이에 응답하여 처음 유저가 인증할 때 서비스에 체크한 정보 제공의 범위까지의 정보를 담아 클라이언트에 보내준다.

이렇게 엑세스 토큰을 보내다가 중간에 엑세스 토큰이 만료되면, 리프레시 토큰을 보내 새로운 엑세스 토큰을 발급받아 기존의 엑세스 토큰을 교환하는 방식으로 진행된다.

PKCE

PKCE(Proof Key for Code Exchange)는 Authorization Code Flow를 사용할 때 코드 교환 과정의 보안을 강화하기 위해 OAuth 2.1에서 필수적으로 사용하도록 지정되어 있는 기술이다. 기존 Authorization Code Flow보다 더 높은 보안성을 요구한다.

PKCE는 다음과 같은 필드들을 추가적으로 가진다.

code_verifier: 앱으로부터 생성되는 임의의 랜덤 문자열이다.
code_challenge: code_verifier와 짝을 이루는 문자열
- code_verifier를 그대로 사용하는 경우도 있지만 S256 해싱 알고리즘으로 암호화하는 것이 권장된다. OAuth 서버는 이 문자열을 복호화하여, code_verifier와 같은지 확인함으로써 클라이언트를 검증한다.
code_challenge_method: code_verifier의 변환에 어떤 함수가 사용되는지(S256 또는 plain) 지정하는 필드이다. 기본값은 plain으로, 이 경우 code_verifier와 code_challenge는 같은 것으로 간주된다.

이 필드들을 통해 OAuth 서버는 인증 요청과 토큰 요청이 동일한 클라이언트로부터 온 것인지 확인할 수 있다.

PCKE의 동작 방식은 위 사진과 같이 유저가 로그인 링크를 클릭하면 앱 자체에서 인증 코드 요청을 보내기 전에 code_verifier와 code_challenge를 생성하는 과정이 기존의 code 방식에서 추가되었다.

인증 코드 요청을 할 때 이 code_challenge와 함께 요청이 날아간다. 사용자가 로그인을 하고 사용자가 원하는 정보의 공개 제한 범위를 선택하고 로그인을 하게 되면 code를 담아 리다이렉트된다.

이후에 code를 가지고 다시금 앱이 토큰을 얻기 위해 요청을 보내는 과정에서 아까 인증 서버로 보냈던 code_challenge와 비교할 대상 문자열인 code_verifier를 함께 보낸다. 비교 문자열이 서로 검증해서 맞아 떨어지게 되면 엑세스 토큰과 선택적으로 리프레시 토큰을 다시금 보내준다. 이후에는 유저가 받은 엑세스 토큰을 가지고 요청 및 응답을 하는 방식이다.

OAuth의 장점

OAuth가 다양한 소셜 로그인의 수단으로 사용된 이유는 사용자의 모든 계정 정보를 알지 않아도 회원의 정보에 접근할 수 있다는 사실이 보안에 도움이 되기 때문이다.

추가적으로 로그인을 하는 과정에서 서비스에 제공할 수 있는 개인정보의 범위를 사용자가 직접 제한할 수 있기 때문에, 애플리케이션의 입장에서는 허용된 범위의 리소스에만 접근할 수 있다는 사실 또한 보안에 강하면서도 인증과 권한 부여를 동시에 할 수 있다는 장점 또한 가진다. 괜스레 모든 정보를 다른 애플리케이션에서도 가지고 있다가 악용될 가능성을 높이는 것보단 필요한 정보만 가져다 쓰는 것이 모두에게 이득이 될 수 있기 때문에 현재 사실상의 업계 표준으로 자리잡고 있다.

🐢꾸준함의 미학

탐색기