액세스 토큰이 만료되면 어떻게 해야할까 ?

Refresh Token Workflow

서비스 제공자가 Refresh Token Workflow 를 지원한다면,
엑세스 토큰 요청이 대한 응답에 access_token 뿐만 아니라 refresh_token 값도 포함되어있다.
응답에 refresh_token 이 포함되어 있지 않으면 Refresh Token Workflow 를 지원하지 않는 것이다.

리프레시 요청

리프레시 토큰을 이용해서 엑세스 토큰을 요청하려면,
서비스 제공자의 토큰 엔드 포인트로 POST 요청해야한다.

1
2
3
4
5
6

POST /token HTTP/1.1
HOST: server.example.com
Authorization: BASIC [ENCODED_CLIENT_CREDENTIALS]
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=[REFRESH_TOKEN]

1. grant_type
   리프레시 토큰을 이용해서 새로운 액세스 토큰을 요청한다는 것을 나태내기 위해
   refresh_token 이어야한다.

2. scope
   원래의 엑세스 토큰보다 더 큰 접근 범위를 지정해서 요청할 수 없다.
   즉, 갱신된 엑세스 토큰은 이전과 동일하거나 작은 접근 권한 범위를 가져야한다.

엑세스 토큰 응답

엑세스 토큰 요청이 성공하면 다음과 같은 파라미터가 전달된다.

1. access_token
   얻고자 했던 엑세스 토큰이다.

2. token_type
   전달되는 토큰의 유형이다.
   대부분 bearer 토큰이다.

3. expired_in
   토큰의 유효기간이다.

4. refresh_token
   엑세스 토큰이 만료되면 엑세스 토큰을 갱신하기 위해 사용되는 토큰이다.

5. scope
   인가된 접근 범위이다.

암시적 그랜트 플로우나 인가 코드 그랜트 플로우를 이용해서,
서비스 제공자에게 엑세스 토큰을 요청할 수 있게 되었다.
이제, 엑세스 토큰을 이용해서 서비스 제공자가 제공하는 API 를 호출할 차례이다.

엑세스 토큰 이용해서 API 호출

API 를 호출할 때 엑세스 토큰을 전달하는 방법으로는 세 가지가 있다.

1. 인가 요청 Header Field 에 담아서 전달
2. 인코딩된 Form 의 Parameter 로 전달
3. URI Query Parameter 로 전달

인가 요청 Header Field 에 담아서 전달

OAuth 2.0 스팩에서 권장하는 방식이다.
HTTP 요청의 Authorization Header 에 엑세스 토큰을 담아서 서비스 제공자에게 전달하는 것이다.
엑세스 토큰을 요청하기 위해 사용된, basic authorization 방법과 유사하다.
차이점은, Basic 이 아니라 Bearer 가 사용된다는 것이다.

1
2
3

GET /resource HTTP/1.1
HOST: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

인코딩된 Form 의 Parameter 로 전달

Authorization Header Field 를 사용하지 않고 HTTP Header 의 다른 Field 를 사용하는 것이다.
GET 아닌 POST 요청을 한다는 점이 중요하다.

1
2
3
4
5

POST /resource HTTP/1.1
HOST: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

Sample

인가 코드 그랜프 플로우를 샘플 앱인 WMIIG 샘플 앱으로 확인해보자.

1. 사용자 : WMIIG 로 접속해서, 인포그래픽을 보려고 한다.
2. WMIIG : 당신의 프로파일과 당신이 작성한 글에 접속해야 하므로, 여기서 인가해달라고 요청한다. (페이스북으로 연결)
3. 페이스북 : WMIIG 이 사용자의 프로파일과 작성한 글에 접근하는 것을 허용할지 사용자에게 물어본다.
4. 페이스북 : 사용자가 허락했으면, WMIIG 에게 사용자의 프로파일과 글에 접근하는 데 사용할 수 있는 엑세스 토큰과 교환 가능한 인가 코드를 전달한다.
5. WMIIG : 페이스북으로부터 받은 인가 코드를 이용해서 사용자의 페이스북 프로파일과 글에 접근할 수 있는 엑세스 토큰을 요청한다.
6. 페이스북 : 전달된 인가 코드를 확인하여, WMIIG 에게 엑세스 토큰을 전달한다.
7. WMIIG : 페이스북으로부터 받은 엑세스 토큰을 이용해서 페이스북에게 사용자의 프로파일과 글을 요청한다.
8. 페이스북 : 전달된 엑세스 토큰을 확인한 후, 사용자의 프로파일과 글을 전달한다.

인가 코드 그랜트 플로우

1. 사용자 동의 화면에서 사용자가 동의를 하면
2. 리다이렉션 엔드포인트로 인가 코드가 전달되고
3. 인가 코드를 엑세스 토큰과 교환한다.

인가 요청

사용자를 서비스 제공자의 인가 엔드 포인트로 연결한다.
OAuth 2.0 스팩은 다음과 같다.
response_type 이 code 이 경우만 제외하면, 암시적 그랜트 플로우와 동일하다.

1
2
3
4
5
6
7

GET /authorize?
  response_type=code&
  client_id=[CLIENT_ID]&
  redirect_uri=[REDIRECT_URI]&
  scope=[SCOPE]&
  state=[STATE] HTTP/1.1
HOST: server.example.com

1. response_type
   인가 코드 그랜트 플로우를 사용하고 있음을 나타내기 위해, code 로 세팅한다.

2. client_id
   클라이언트 등록 과정에서 제공된 클라이언트 고유 아이디이다.

3. redirect_uri
   서비스 제공자는 요청이 성공하면 인가 코드가 이 uri 로 전달한다.

4. scope
   클라이언트가 요청하는 접근 권한의 범위이다.
   각 범위는 공백 문자로 구분된다.

5. state
   클라이언트의 요청과 그에 따른 콜백 간의 상태를 유지하기 위해 사용된다.
   클라이언트가 서비스 제공자에게 전달하면 서비스 제공자는 이 값을 다시 응답에 포함해서 전달한다.

Sample

암시적 그랜프 플로우를 샘플 앱인 WMIIG 샘플 앱으로 확인해보자.

1. 사용자 : WMIIG 로 접속해서, 인포그래픽을 보려고 한다.
2. WMIIG : 당신의 프로파일과 당신이 작성한 글에 접속해야 하므로, 여기서 인가해달라고 요청한다. (페이스북으로 연결)
3. 페이스북 : WMIIG 이 사용자의 프로파일과 작성한 글에 접근하는 것을 허용할지 사용자에게 물어본다.
4. 페이스북 : 사용자가 허락했으면, WMIIG 에게 사용자의 프로파일과 글에 접근하는 데 사용할 수 있는 엑세스 토큰을 전달한다.
5. WMIIG : 페이스북으로부터 받은 엑세스 토큰을 이용해서 페이스북에게 사용자의 프로파일과 글을 요청한다.
6. 페이스북 : 전달된 토큰을 확인하여, WMIIG 에게 사용자의 프로파일과 글을 전달한다.

암시적 그랜트 플로우

WMIIG 은 사용자를 서비스 제공자의 인가 엔드 포인트로 연결함과 동시에,
리다이렉션 엔드 포인트와 scope 같은 정보를 서비스 제공자에게 전달한다.
사용자가 동의하면, 응답에 엑세스 토큰이 포함되어 전달된다.

인가 요청

사용자를 서비스 제공자의 인가 엔드 포인트로 연결한다.
OAuth 2.0 스팩은 다음과 같다.

1
2
3
4
5
6
7

GET /authorize?
  response_type=token&
  client_id=[CLIENT_ID]&
  redirect_uri=[REDIRECT_URI]&
  scope=[SCOPE]&
  state=[STATE] HTTP/1.1
HOST: server.example.com

1. response_type
   암시적 그랜트 플로우를 사용하고 있음을 나타내기 위해, token 으로 세팅한다.

2. client_id
   클라이언트 등록 과정에서 제공된 클라이언트 고유 아이디이다.

3. redirect_uri
   서비스 제공자는 요청이 성공하면 엑세스 토큰을 이 uri 로 전달한다.

4. scope
   클라이언트가 요청하는 접근 권한의 범위이다.
   각 범위는 공백 문자로 구분된다.

5. state
   클라이언트의 요청과 그에 따른 콜백 간의 상태를 유지하기 위해 사용된다.
   클라이언트가 서비스 제공자에게 전달하면 서비스 제공자는 이 값을 다시 응답에 포함해서 전달한다.

엑세스 토큰 응답

OAuth 2.0 클라이언트가 되기 위한 과정을 네 개의 단계로 정리한다.

클라이언트 애플리케이션 등록

서비스 제공자는 자신에게 요청하는 클라이언트가 누구인지 알아야한다.
그래서, 클라이언트 애플리케이션 등록이 필요하다.
애플리케이션 등록 후에 사용하게 될 정보 셋은 다음과 같다.

1. client id
   클라이언트 애플리케이션의 고유한 ID
2. client secret
   서비스 제공자에게 요청을 보낼 때, 애플리케이션의 신원을 알려주는 비밀 키
3. redirection endpoint
   서비스 제공자가 응답을 전달하기 위해 사용하는 엔드 포인트
4. authorization endpoint
   클라이언트 애플리케이션이 인가 플로우를 시작할 때 사용하는 엔드 포인트
5. token endpoint
   클라이언트 애플리케이션이 토큰 플로우를 시작할 때 사용하는 엔드 포인트

엑세스 토큰 얻기

애플리케이션을 등록했으면, 이제 엑세스 토큰을 얻어야한다.
애플리케이션에 따라 워크 플로우가 결정되는데,

1. 애플리케이션이 신뢰 애플리케이션이면, 인가 코드 그랜트 플로우를
2. 애플리케이션이 비신뢰 애플리케이션이면, 그랜트 플로우를 사용할 것이다.

그런데, 액세스 토큰이 무엇일까 ?

엑세스 토큰

하나의 리소스나 다수의 리소스에 대해, 일정 기간 동안 접근할 수 있는 권한을 캡슐화한 것이다.

시나리오

다음 시나리오로 시작하자.
사용자가 GoodApp 이라는 App 을 사용한다고 하자.
GoodApp 은 사용자의 페이스북에 등록된 친구들을 추천해줄 수 있다.

1. 사용자가 GoodApp 에게 친구 추천을 요청
2. GoodApp 은 먼저 자신을 인가해달라고 대답
3. GoodApp 은 페이스북에 대한 접근 권한을 받기 위해, 사용자가 페이스북에 로그인하도록 함
4. 페이스북은 GoodApp 이 사용자의 친구 목록에 접근하도록 허용할 것인지 질문
5. 사용자는 네 라고 대답
6. 페이스북은 GoodApp 에게 사용자의 친구 목록을 전달
7. GoodApp 은 이 친구 목록을 이용해서 사용자에게 친구 추천

Client

GoodApp 에게 사용자의 친구 목록에 접근할 수 있는 권한이 부여된 이후에는, GoodApp 과 페이스분 간 정보 교환을 위한 상호 작용이 이뤄진다.
이 상호 작용은, 클라이언트 어플리케이션의 능력에 따라 달라진다.

Untrusted Client

기밀 정보를 안전한게 저장거나 전송할 수 없는 애플리케이션이다.
예를 들면, HTML/Javascript 애플리케이션으로서 정보를 안전하게 저장하는 서버가 없는 경우이다.

Trusted Client

기밀 정보를 안전한게 저장하고 전송할 수 있는 애플리케이션이다.
예를 들면, 백엔드 서버거 존재하는 클라이언트-서버-데이터베이스 구조의 애플리케이션이다.

Grant