OAuth

작년쯤 토이 프로젝트로 OAuth를 활용해서 구글 로그인을 사용해본 적이 있다.

그때는 OAuth에 대한 배경지식 없이 그냥 클론 코딩하듯이 사용했었다.

 

이번에 OAuth라는 것을 다시 한번 접하게 되어서 다음에 사용할 때는 뭐가 뭔지 알고 사용할 수 있도록,

이 부분을 정리해두려고 한다.

 

OAuth

출처: https://datatracker.ietf.org/doc/html/rfc6749

공식 문서에 정의되어 있는 OAuth의 정의를 먼저 읽어보면, 정보 접근 서비스가 정보 제공 서비스가 가지고 있는 리소스에 제한된 액세스를 얻기 위한 응용 프로그램이며, 자원 소유자와 정보 제공 서비스 간의 승인 상호작용을 조정 또는 정보 접근 서비스가 자체 리소스 액세스 권한을 얻도록 허용해주는 프로그램이다.라고 되어있다.

 

인증을 위한 표준 프로토콜의 한 종류, 이미 보안되어 있는 기존의 리소스에 접근하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜의 한 방법이라고도 정의 할 수 있겠다.

피파온라인 로그인 화면

OAuth는 위의 사진과 같이 다양한 웹 서비스에서 사용되고 있다.

기존의 로그인 기능을 서비스에서 직접 구현하고 관리하면 개인정보를 관리해야하는 부담도 생기고, 그만큼의 자원이 투자되어야 할 것이다. 하지만 OAuth를 활용해서 로그인, 개인정보 관리 부분을 기존의 서비스에게 위임하면 동일한 기능을 사용하면서 개인정보에 대한 부담을 줄일 수 있다. (하지만 사용자는 반드시 기존의 서비스에 정보가 있어야 한다는 단점이 있을 수 있다.)

 

OAuth의 요소

설명에 따라서 3가지 또는 4가지로 나눌 수 있을 것 같다.

1. Client: 현재 서비스를 제공하는 주체, OAuth를 통해 사용자 정보에 접근하려는 서버.

2. Resource Owner : 리소스(개인정보)를 가지고 있는 요소. 개인정보를 활용해서 서드파티 서비스에 가입되어있으며, Client가 제공하는 서비스를 이용하려는 사용자.

3. Authorization Server: OAuth를 통해 권한을 부여하는 서버, 서드파티 서비스로 로그인함으로서 권한을 부여받을 수 있다.

4. Resource Server: 사용자의 정보를 가지고 있는 서드파티 서비스의 서버. 위 사진에 따르면 Facebook, Google, Naver, Apple이 될 수 있다. 

 

OAuth의 권한 부여 과정 ( Authorization Code Grant Type )

 

+ 추가) Refresh Token Grant Type

위에서 설명한 일정 유효기간이 지나 만료된 엑세스 토큰을 다시 받아오기 위해 사용하는 방법

 

앞서 사용하던 인증된 Access Tokend이 만료되었을 때 같이 발급되었던 Refresh Token을 사용해 새로운 액세스 토큰을 Authorization Server에 요구하게 됩니다. 서비스마다 요건이 다르겠지만 새로운 Access 토큰을 발급받아서 다시 재인증 과정을 거치지 않아도 새로운 토큰을 발급받아 사용 가능하다.

## Reference

RFC 6749 - The OAuth 2.0 Authorization Framework