[OAuth2] 권한 부여 방식의 종류 ( Authorization Grant )

사전 학습 : https://gintrie.tistory.com/37

[OAuth2.0] OAuth 2.0 용어 정리

https://tools.ietf.org/html/rfc6749

RFC 6749 - The OAuth 2.0 Authorization Framework

OAuth2 권한 부여 방식의 종류 ( Authorization Grant )

- Authorization Grant는 액세스 토큰을 얻기 위해 Client가 사용하는 Resource owner의 권한 ( 보호된 리소스에 접근하기 위한 )을 보여주는 자격 증명이다.

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.

https://tools.ietf.org/html/rfc6749

이러한 명세는 4가지의 권한 부여 방식으로 정의되어 있다.

 

Authorization Code - 권한 부여 코드 승인 타입

구글, 페이스북, 카카오톡 간편 로그인을 사용해봤다면, 익숙한 승인 타입일 것이다.

 

Authorization Code grant type은 기밀 및 공용 클라이언트가 액세스 코드와 인증 코드를 교환하는데 사용된다.

 

User가 redirect URL을 통해 client로 돌아오면, 어플리케이션은 URL에서 인증 코드를 가져오고 Access token을 요청하는데 사용된다.

 

모든 client는 보안을 위하여 이러한 흐름에서 PKCE 확장자를 사용하길 권장된다.

 

추가 설명

Authorization code는 client와 resource owner의 중개자로 authorization server를 사용하여 얻는다.

Client는 Resource owner로 부터 직접 권한 부여를 요청하는 대신에, Resource Owner를 Authorization 서버로 보내고 ( [RFC2616]에 정의된대로 사용자 에이전트를 통해 보냄 ) 다시 Authorization code와 함께 Resource owner를 클라이언트로 보낸다.

 

resource owenr를 authorization code와 함께 client로 보내기 전에, authorization server는 resource owner에 인증 요청을 하고 권한을 부여 받습니다. 이 이유는 resource owner는 authorization server에 대한 인증만 했으므로, resource owner의 자격 증명은 client와 공유하지 않는다.

 

authorization code는 몇가지 중요한 보안상의 이점을 준다.

client를 인증하는 기능과 같은 방법으로, 엑세스 토큰을 resource owner의 사용자 에어전트를 통해 전달하지 않고, resource owner를 포함한 다른 사람에게 노출시키지 않고도 client로 직접 엑세스 토큰을 전송할 수 있다.

 

 

 

Implicit - 암시적 타입

암시적 타입은 authorization code grant와 유사하지만 두가지 차이점이 있다.

 

첫번째로 암시적 타입은 user-agent 기반 클라이언트 ( 예를 들면 단일 페이지 웹 앱) 에 사용된다.

이러한 user-agent 기반 클라이언트는 모든 어플리케이션 코드 및 스토리지에 쉽게 접근할 수 있기 때문에 클라이언트를 비밀로 유지할 수 없다.

 

두번째로 엑세스 토큰을 교환하기 위한 authorization code를 authorization server에서 반환해주는 것이 아닌 access 코드를 직접 반환해 준다.

 

Implicit grant type은 암호없는 client에 대해서 이전에는 권장되었지만, PKCE와 함께 Authorization Code grant를 사용하여 대체되었다.

 

The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token). When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available.

 

Resource Owner Password Credentials - Resource owner 암호 자격 증명 타입

웹과 네이티브 디바이스 어플리케이션에 신뢰할 수 있는 퍼스트 파티 클라이언트에게 훌륭한 UX를 제공한다.

 

Resource owner 암호 자격 ( 보통 username 과 패스워드 )가 access token을 얻기 위한 authorization grant로서 사용 될 수 있다. 이런 자격은 resource owner와 client 사이에서 높은 신뢰성이 있어야합니다. ( 예를 들면 client가 디바이스 운영체제의 한 부분이거나 높은 권한을 가진 어플리케이션 ) 그리고 다른 인증 자격 증명 타입은 사용할 수 없게 됩니다 ( 예를 들면 authorization code )

 

이 권한 부여 유형에는 resource owner 자격에 대한 직접적인 클라이언트 접근이 필요하지만. resource owner 신임 정보는 단일 요청에 사용되며 엑세스 토큰으로 교환된다.

 

이 권한 부여 유형을 사용하면 자격 증명을 장기 액세스 토큰 또는 refresh 토큰과 교환하여 클라이언트가 나중에 사용할 수 있도록 리소스 소유자 자격 증명을 저장할 필요가 없다.

 

 

Client Credentials - Client 자격 증명 타입

OAuth2.0에서 가장 간단한 증명 타입이다.

이것은 특정 유저의 데이터 엑세스 권한이 필요하지 않은 시스템 간의 인증에 적합하다.

 

 

Client Credentials grant type은 client가 사용자 컨텍스트 외부에서 엑세스 토큰을 얻는 데 사용된다.

Client가 user의 resource에 접근하는 것보다 자신에 대한 resource에 접근할 때 주로 사용된다.