OAuth 2.0 기본

Gon Kim·2022년 11월 13일

이왕 공부한 김에 아까워서 하는 정리[0년차]

목록 보기

9/14

네이버, 카카오 등에서 제공하는 OAuth 2.0 관련 api는 이렇게 저렇게 하면 무리 없이 사용할 수 있어서, 공식문서 조금 둘러보면서 정리해봤다. 그렇게.. 쓸모있는 지식이었을까?라는 생각은 들지만 정리했다 ㅋㅋㅋ.. 알게 된건 내가 알던 방식 (Authorization Code Grant)가 OAuth 2.0의 유일한 방법이 아니었다는 것, 그리고 당연하지만 Access token은 세션을 위한 쿠키로 쓰면 절대 절대 안된다는 것을 한번 더 상기하는 정도?!

OAuth

OAuth라고 하지만, OAuth2.0을 다룰 것이다.

사용법은 각종 OAuth server api 문서에 잘 정리되어있으니 그걸 따르면 된다.

1) OAuth

wikipedia: 다른 웹사이트 상에 있는 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 수단으로 사용되는, 접근 위임을 위한 개방형 표준
RFC: 애플리케이션이 특정 수준으로 제한된 HTTP service를 이용할 수 있게 하는 표준으로, 승인 절차를 거쳐 유저의 정보에 대신 접근 가능하게 한다.

2) 절차

용어 정리

Service Provider / Auth|Resource server

OAuth를 사용하기 위한 Open API를 제공하는 서비스
Facebook, github 등..

Consumer / Client

OAuth 인증을 사용해 OAuth server의 기능을 사용하려는 애플리케이션/웹 서비스

User / Resource Owner

OAuth server에 계정을 가지고 있는, Client를 이용하려는 사용자
특정 웹사이트에 회원가입/로그인할 때 네이버 계정을 사용하는 경우가 있다. 여기서 나는 user, 특정 웹사이트는 client, 네이버는 OAuth server

Request Token

Client가 OAuth server에게 접근 권한을 인증받기 위해 사용하는 값. 인증 완료 후 Access Token으로 교환

Access Token

인증 후, Client 가 OAuth의 자원에 접근하기 위한 키를 포함한 값
OAuth 2.0 기준, 만료 기간을 설정할 수 있다. 이 전에는 만료기간이 따로 없었다.

Refresh Token

Access Token이 만료 되었을 때, 유저가 별도로 개입하지 않아도 다시 접근할 수 있도록 하기 위해 고안된 토큰
Client는 OAuth server에게 Refresh Token을 제시하고, 유효하다면 새 Access Token을 발급 받을 수 있다.

Scope

Client가 접근할 수 있는 정보의 범위. user가 client에게 권한을 위임하는 방식이라면 그 과정에서 user는 scope을 확인할 수 있다. 서비스마다 제공되는 종류가 상이하다.

절차 - Protocol Flow

출처: https://www.rfc-editor.org/rfc/rfc6749 Figure 1

사실 승인 방식이 몇 가지 된다. 위는 모든 방식을 추상화한, 일반적인 protocol flow를 보여준다.

A, B

client는 resource owner에게 authorization grant에 대한 요청을 한다. 나중에 ‘나는 특정 권한을 부여받을 수 있도록 허가 받았다!’를 인증받기 위한 과정인 것으로 보면 된다. resource owner에게서 바로 권한을 얻을 수도 있고, 또는 authorization server을 거쳐서 권한을 얻는 방식도 있다.
이 부분이 ‘몇 가지’ 다른 방식으로 나뉜다.

공식문서에서 설명하는 Authorization Grant. 유저에게 유저 정보를 열람할 수 있는 허가를 받았다는 증명서 정도로 생각하면 된다. 이걸 이용해 나중에 access token을 받는다.
An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types.

C, D

client는 authorizatioin server에게 access token을 요청한다. 방금 얻은 authorization grant와 함께 자신을 authenticate해서 얻을 수 있다.

E, F

Access token을 얻었으니, resource server에 이를 보여주며 resource owner에 관한 특정 정보를 받아올 수 있다.

결론적으로, 다음과 같이 축약된다.

유저의 도움을 받아 authorization grant를 얻고
이를 이용해 access token을 얻고
access token을 이용해 유저 정보에 접근

절차 - Authorization Code Grant

위에서 A, B 과정에 몇 가지 방법이 있다고 했다. 그 중 하나인 Authorization code grant만 설명하려고 한다. 이 방법은 Refresh token의 사용이 가능한 방식이다. refresh token에 대한 자세한 설명은 뒤에서 다룬다. 또한 이 방법 외에 다른 방법에 대해 알 필요가 있으면 그 때 그 때 해당 문서를 참고하거나 구글링하자

출처 https://www.rfc-editor.org/rfc/rfc6749 Figure 3

https://www.rfc-editor.org/rfc/rfc6749에서 설명하는 Authorization Code Grant. Redirection-based flow를 사용하며, 그렇다보니 당연히 user-agent(보통 web browser)와 의사소통이 가능해야한다.
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

내가 서비스 S를 운영중이며, naver의 OAuth 기능을 사용중이라고 하자. naver는 아무 서비스에게나 막 권한을 주면 안된다. 당연히 나는 사전에 naver에서 OAuth2.0(이하 OAuth로 축약)기능을 사용할 수 있도록, 일종의 회원가입/등록을 해놔야한다. 나도 결국 naver 입장에서는 client이다.

과정을 살펴보자

A
- S는 유저의 web browser를 authorization endpoint로 보낸다. 쉽게 말해 유저가 로그인 버튼 클릭했을 때 로그인 페이지로 보내준다는 것. redirect_uri, response_type 등을 포함한 uri로 이동하게 될 것이다.
B, C
- 유저가 로그인을 성공적으로 마치면, authorization code를 얻게되고, 유저의 브라우저는 이를 S에게 보낸다.
D, E
- S는 이를 가지고서 naver에게 access token을 요청하고, 받는다.

출처 https://hudi.blog/oauth-2.0/