OAuth 2.0 기본 개념과 방식에 대한 이해

OAuth(Open Authorization)의 개념

OAuth 2.0은 인증을 위한 업계 표준 프로토콜입니다. OAuth 2.0은 웹 애플리케이션, 데스크톱 애플리케이션, 휴대폰 및 거실 장치에 대한 특정 인증 흐름을 제공하는 동시에 클라이언트 개발자 단순성에 중점을 둡니다. 

 

OAuth는

User(인터넷 사용자들)이 비밀번호를 제공하지 않고, 다른 웹사이트(아마존, 구글, 페이스북, 마이크로소프트, 트위터) 상의 자신들의 정보 및 자원을 사용함에 있어, 현재 이용하고 있는 웹사이트나 애플리케이션에게  접근 권한을 부여(granted Access)할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

 

이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.

 

OAuth 의 주체

사용자 (user)

Resource Owner  서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인

 

소비자 (consumer)

Resource Client   Open API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션

 

서비스 제공자 (service provider)

Authorization Server - Open API를 이용을 위해 필요한 Access Token을 발급하는 서버.

Resource Server - OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스)

 

* Authorization Server와 Resource Server가 동일한 서버일 수도 있고, 별개의 서버일 수도 있다. 하나의 Authorization Server가 여러 개의 Resource Server에 액세스 토큰을 발급할 수도 있다.

OAuth 의 작동방식

Resource Owner(user)에게 Resource Server에 있는 자원에 대한 접근 및 사용을 허락을 받았다는 증거인, 권한 코드 (Authorization Code)를 가지고 Authorization Server로 부터 AccessToken을 요청하는 방식

 

1. Authorization Code Grant (권한 코드 부여 방식)

register(등록)

- Resource Client가 Authorization Server에 자원을 사용하기 위해 클라이언트로 등록하는 과정.

 

* Redirection (인증후 연결된 Client Url)

* API Scopes (사용할 Resource Server)

 

등록후 , clientID(id)  clientSecret(pw)를 Authorization Server로 부터 부여받는다.

Resource Owner(사용자)가 Authorization Server로 부터 Authorization Code를 부여받고,  Code를 Client에게 전송해 준다.

Client는 Code를 자신의 Backend 서버에 잘 저장한다.

 

Client는 Authorization Code, ClientId, ClientSecret 등의 정보를 넣어 AuthServer에게 Resource Server API 이용을 위한 AccessToken & RefreshToken을 발급받는다.

 

Client는 Resource Owner(사용자) 정보와 Access Token을 이용하여 사용자의 데이터에 접근할 수있다.

 

* Access Token이 만료될시 Refresh Token를 이용해서 Auth Server에게 새로운 Access Token을 발급 받는다.

2. Implicit Grant (암묵적 부여)

Authorization Code 발급 과정 없이 절차 없이 Resource Owner가 인증 및 허가를 하면 바로 Access Token이 발급되는 방식

Access Token이 바로 Redirect URI에 붙어서 전송된다(보안에 취약하다)

 

Client 쪽에 프래그먼트로 바로 토큰이 노출되기 때문에, 상대적으로 보안에 취약합니다.

 Access Token의 유효시간이 짧고, Refresh Token를 Backend에 저장하지 않기에 사용할 수 없다. 

3. Resource Owner Password Credentials Grant

Resource Owner(사용자)의 ID 및 Password를  Client에게 전달하고 Client는 사용자의 ID/Password를 통해서 Authorization Server로 부터 AccessToken/RefreshToken을 받아서 Resource Server API 이용합니다.

* 단, 이 방식은 Resource Owner(사용자)의 ID 및 Password를  Client에게 전달하기 때문에, 일반적인 상황에서는 절대로 사용해서는 안됩니다. Client, Authorization Server, Resource Server 모두 하나의 시스템으로 묶여 있을때 사용할 수 있는 방식이다.

 

즉, 구글 Gmail에서 Google Drive에 접근하여 사용자의 사진을 가져와서 메일에 첨부를 하고 싶다고 가정해보자!

구글 Gmail(Client),  Google(Authorization Server), Google Drive(Resource Server)이다. 

4. Client Credentials Grant

Resource Owner(사용자)와 Client가 동일한 경우 사용 가능한 인증 방식 이다.

Client가 Client Id와 Client Secret을 통하여 Authorization Server로 부터 바로 access token을 발급받아서 사용한다.

즉, Client가 자신의 Resource에 접근 및 사용을 위한 방식이다.

 

5. Refresh Token Grant Type

Authorization Code Grant 또는 Resource Owner Password Credentials Grant의 인증 방식에서는 Authorization Server로 부터 Refresh Token을 발급받아 저장하여 사용할 수 있다. 특별히 사용자가 인증을 취소하자 않고, RefreshToken이 만료되지 않았다면,  Refresh Token을 통하여 AccessToken을 재발급 받아 Resource Server의 API를 이용할 수 있다.