[OAuth 2.0] 소셜로그인 인증 방식 OAuth 2.0 이해하기

OAuth 2.0 

OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜이다.

 

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제 3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)받을 수 있는 표준 프로토콜이다.

 

: 이 프로토콜에서는 Third-party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다. 구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공하고 있다.

 

OAuth 2.0 주체

Resource Owner

리소스 소유자. 우리의 서비스를 이용하면서, 구글, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자이다. 리소스라 하면 '구글 캘린더 정보', '페이스북 친구 목록', 네이버 블로그 포스트 작성'등이 해당될 것이다.

 

인증이 완료되면 권한 획득 자격(Authorization Grant)를 클라이언트에게 부여한다. 개념적으로는 리소스 소유자가 자격을 부여하는 것이지만, 일반적으로 권한 서버가 리소스 소유자와 클라이언트 사이에서 중개 역할을 수행하게 된다.

 

Authorization & Resource Server

Authorization Server는 Resource Owner를 인증하고, Client에 토큰을 발급해주는 서버이다. 인증/인가를 수행하는 서버로 클라이언크의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행한다. Resource Server는 구글, 페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 말한다. 

Authorization Server와 Resource Server는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할 지는 개발자가 선택하기 나름이라고 한다. 

 

Client

Resource Server의 자원을 이용하고자 하는 서비스. 보통 우리가 개발하려는 서비스가 될 것이다.

 

어플리케이션 등록

OAuth 2.0 서비스를 이용하기 전에 선행되어야 하는 작업이 있다. Client를 Resource Server에 등록해야하는 작업이다. 이 때, Redirect URI를 등록해야한다. Redirect URI는 사용자가 OAuth 2.0 서비스에서 인증을 마치고 사용자를 리디렉션시킬 위치이다.

 

Redirect URI

OAuth 2.0 서비스는 인증이 성공한 사용자를 사전에 등록된 Redirect URI로만 리디렉션 시킨다. 승인되지 않은 URI로 리디렉션 될 경우 Authorization Code를 중간에 탈취당할 위험성이 있기 때문이다.

 

Redirect URI는 기본적으로 보안을 위해 https만 허용되고, 루프백(localhost)는 예외적으로 http가 허용된다.

 

Client ID, Client Secret

등록 과정을 마치면, Client ID와 Client Secret을 얻을 수 있다. 발급된 Client ID와 Client Secret은 액세스 토큰을 획득하는 데 사용된다. 이 때, Client ID는 공개되어도 상관없지만, Client Secret은 절대 유출되어서는 안된다. (보안사고 위험)

 

OAuth 2.0의 동작 메커니즘

1. 로그인 요청

 Resource Owner가 우리 서비스의 '구글로 로그인하기' 등의 버튼을 통해 로그인을 요청한다. Client는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 보낸다. 

 

Client는 이 때 Authorization Server가 제공하는 Authorization URL에  response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리스트링으로 포함하여 보낸다. 

 

2. 로그인 페이지 제공, ID/PW 제공

클라이언트가 빌드한 Authorization URL로 이동된 Resource Owner는 제공된 로그인 페이지에서 ID와 PW등을 입력하여 인증할 것이다.

 

3. Authorization Code 발급, Redirect URI로 리디렉트

인증이 성공되었다면, Authorization Server는 제공된 Redirect URI로 사용자를 리디렉션시킬 것이다. 이때, Redirect URI에 Authorization Code를 포함하여 사용자를 리디렉션 시킨다. 구글의 경우 코드를 쿼리 스트링에 포함한다.

 

이 때, Authorization Code란, Client가 Access Token을 획득하기 위해 사용하는 임시 코드이다. 이 코드는 수명이 매우 짧다.(일반적으로 1-10분)

 

4. Authorization Code와 Access Token 교환

Client는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답받는다. Client는 발급받은 Resource Owner의 Access Token을 저장하고, 이후 Resource Server에서 Resorce Owner의 리소스에 접근하기 위해 Access Token을 사용한다.

 

이 때 Access Token을 가로채지 못하도록 https를 통해서만 사용할 수 있다.

 

Authorization Code와 Access Token 교환은 token 엔드포인트에서 이루어진다. 

 

5. 로그인 성공

위 과정을 성공적으로 마치면 Client는 Resource Owner에게 로그인이 성공하였음을 알린다.

 

6. 그 후 Access Token으로 리소스 접근

이후 Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client에 요청한다. Client는 위 과정에서 발급받고 저장해둔 Resource Owner의 Access Token을 사용하여 제한된 리소스에 접근하고, Resource Owner에게 자사 서비스를 제공한다.

 

Reference 

아래의 블로그에서 과정에 대해 더 자세히 설명하고 있으니 꼭 읽어보길 바란다

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

OAuth 2.0 개념과 동작원리