OAuth - Authorization Code Grant Type

educative 번역, 요약한 자료입니다.

What is grant type?

OAuth 2.0에서 grant type이라는 용어는 애플리케이션이 액세스 토큰을 얻는 방법을 나타낸다.

각 grant type은 웹 앱이든, 네이티브 앱이든, 웹 브라우저를 출시할 능력이 없는 장치든, 서버 대 서버 애플리케이션이든 특정 용도에 최적화된다.

 

 

Authorization Code grant type

인증 코드 부여 유형은 가장 일반적으로 사용되는 OAuth 2.0 grant type이다.

유저가 승인한 후 인증 서버에서 액세스 토큰을 얻기 위해 웹 앱과 네이티브 앱 모두에서 사용된다.

인증 코드 흐름은 백엔드가 있는 웹 사이트 및 모바일 앱에 가장 적합하다.

  이 유형은 액세스 토큰에 대한 authorization 코드를 교환하는 추가 단계를 갖는다. 액세스 토큰에 대한 authorization 코드 교환은 백 채널에서 이루어진다. 이 기능으로 인해 추가 보안 레이어를 제공하게 된다.

 

 

Authorization Code grant type Working

1단계 : Authorization request

첫 번째 단계에서 클라이언트 앱(PicsArt)은 리소스 소유자(사용자)를 권한 부여 서버의 권한 부여 끝점으로 리디렉션한다.

 이 앱은 권한 부여 서버가 클라이언트 앱과 그 의도를 식별하는 데 도움이 되는 몇 가지 쿼리 매개변수를 보낸다.

 

request 요청에 전송되는 query parameter들

1. response type

예상되는 response type을 정의한다.

 

2. client_id

이 매개 변수는 리소스에 대한 액세스가 필요한 클라이언트의 ID를 정의한다. 우리의 예에서, 그것은 PicsArt 앱의 클라이언트 ID가 될 것이다.

 

참고! 이 client_id가 어디서 왔는지 궁금할 수 있다. 모든 클라이언트 앱은 먼저 인증 서버(ex. github, facebook)에 등록해야 한다.

클라이언트가 인증 서버에 등록되면, 그것은 인증 서버에 자신을 식별하는 데 사용되는 고유한 client_id 및 client_secret이 제공된다.

 

3. redirect_uri

이것은 권한 부여 서버가 리소스 소유자와의 상호 작용을 완료한 후 리디렉션하는 URI입니다. 

 

4. scope

이 파라미터는 액세스를 요청하는 리소스를 정의한다. 이것은 필수 매개변수가 아니며, 인증 서버가 제공되지 않은 경우, 인증 서버는 이 클라이언트에 대해 이미 정의된 기본 리소스에 대한 액세스를 제공한다. (ex. 이미지만 액세스 할 것인지 여부)

 

5. state

응용 프로그램은 임의의 문자열을 생성하여 요청에 포함시킨다. 
그런 다음 사용자가 앱을 승인한 후 동일한 값이 반환되는지 확인해야 한다. CSRF 공격을 막기 위해 사용한다.

 

그래서 request는 이렇게 작성된다.

https://authorization.server.dummy.com/authorize
?response_type=code
&client_id=12345
&redirect_uri=https://client.dummy.com/callback
&scope=images_read
&state=abcde

 

 

2단계 : Authorization response

사용자가 Authorization 서버에 대한 동의를 제공하는 경우 Authorization 서버는 브라우저를 요청에 제공된 redirect_uri로 리디렉션한다. 

 

response에 보내지는 파라미터들

1. code

Authorization 서버에서 생성된 Authorization 코드 입니다.

이 코드는 비교적 수명이 짧으며 client_id, resource_owner, 스코프 및 redirect_uri에 바인딩되어 있다.

 

2. state

요청과 함께 전달된 문자열이다.

 

그래서 response url은 이렇게 작성된다.

https://authorization.server.dummy.com/callback
?code=hhdf6hsbhjG66hgtgfGGHJGCHJ
&state=abcde

 

3단계 : Token request

클라이언트가 승인 코드를 받은 후에는 토큰 끝점에 사후 요청을 보내 액세스 토큰과 코드를 교환할 수 있다.

 

request 요청과 함께 다음 parameter가 전송된다.

1. grant_type

이 경우 값은 accreditation_code가 될 것이다.

이것은 클라이언트가 권한 부여 코드 부여 유형을 사용 중임을 토큰 endpoint 에 알려준다.

 

2. code

authorization response 에서 받은 코드

 

3. client_id

client의 client_id 이다

 

4. client_secret

이 필드는 요청이 클라이언트를 가장한 공격자가 아닌 등록된 클라이언트에 의해 전송되는지 확인하기 위한 것이다.

 

예시는 다음과 같다.

POST /token/endpoint HTTP/1.1
 
  Host: authserver.dummy.com
 
grant_type=authorization_code
&code=hhdf6hsbhjG66hgtgfGGHJGCHJ
&client_id=12345
&client_secret=gh5Gdkj743HFG45udbfGfs

 

 

4단계 : Token response

token의 endpoint는 요청의 모든 파라미터를 확인한다.

코드가 만료되지 않은 상태이며, client_id와 client secret이 일치하면, 액세스 토큰이 반환된다.

 

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "access_token":"YT3774ghsghdj6t4GJT5hd",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"YT768475hjsdbhdgby6434hdh",
  "scope":"images_read"
}

 

 

“왜 액세스 토큰을 가지고 오는데 두 단계나 거쳐야 할까요?

왜 먼저 authorization code 를 받아서 액세스 토큰과 교환해야 하는 거지?..”

 

 

이것을 이해하기 위해서는 2가지 컨셉을 먼저 알아야 한다.

 

1. 프론트 : 서버 채널에 대한 브라우저/모바일 앱의 보안 감소

2. 백 : 서버 간 통신 채널 보안 강화

 

프론트엔드에서 client secret을 공유하고 액세스 토큰을 가지고 오는 것은 위험하다.

 

그래서 우리는 먼저 프론트엔드를 이용해서 authorization code를 가져오고, 백엔드를 이용해서 액세스 토큰을 요청한다.

 

출처 : educative