[OAuth 2.0] 7. Accessing Protected Resources

클라이언트는 액세스 토큰을 리소스 서버에 제시함으로써 보호된 리소스에 접근한다.

 

리소스 서버는 액세스 토큰을 반드시 검증해야 하며(MUST), 해당 토큰이 만료되지 않았는지, 그리고 그 범위(scope)가 요청된 리소스를 포괄하는지를 확인해야 한다. 리소스 서버가 액세스 토큰을 검증하는 데 사용하는 방법(및 오류 응답)은 본 명세의 범위를 벗어나지만, 일반적으로는 리소스 서버와 인가 서버 간의 상호작용 또는 협력을 수반한다.

 

클라이언트가 리소스 서버와 인증하기 위해 액세스 토큰을 사용하는 방식은 인가 서버가 발급한 액세스 토큰의 유형에 따라 달라진다. 일반적으로는 [RFC2617]에 정의된 HTTP "Authorization" 요청 헤더 필드를 사용하며, [RFC6750]과 같이 사용된 액세스 토큰 유형의 명세에서 정의된 인증 스킴을 따른다.

클라이언트가 액세스 토큰을 가지고 리소스 서버(API 서버)에 자신을 증명하는 방법은 인가 서버가 어떤 ‘토큰 타입’을 발급했느냐에 따라 달라진다. 보통은 HTTP 요청의 Authorization 헤더에 토큰을 담아 보내(클라이언트가)며, 그 구체적인 형식은 토큰 타입의 명세(RFC6750 등)에 정의되어 있다.

여기서 중요한 것은 토큰 유형에 따라 달라진다라는 말이 OAuth에서 access_token은 그냥 문자열이다. 그런데 중요한 건 이 문자열을 어떻게 쓰느냐임. 그래서 OAuth는 token_type이라는 개념을 둔다. 
{ "access_token": "abc.def.ghi", "token_type": "Bearer" }
access_token -> 실제 토큰 값, token-type -> 이 토큰을 HTTP 요청에 어떻게 넣어야 하는지에 대한 규칙

Bearer 토큰이란?
- 이 토큰을 들고 있는(bearer) 사람은 곧 권한을 가진다. 즉, 추가 서명 x 추가 암호화 x 그냥 토큰을 보여주면 끝

 

7.1 액세스 토큰 유형

액세스 토큰 유형은 (유형별 속성과 함께) 보호된 리소스 요청을 성공적으로 수행하기 위해 액세스 토큰을 사용하는 데 필요한 정보를 클라이언트에게 제공한다. 클라이언트는 토큰 유형을 이해하지 못하는 경우 해당 액세스 토큰을 사용해서는 안 된다(MUST NOT).

위 문장은 token_type이 왜 존재하는 가를 설명하고 있음

액세스 토큰 자체는 문자열이고 이 문자열을 어떻게 써야하는지를 알려주는 설명서가 바로 토큰 유형(token_type)이다. 

"필요한 정보를 클라이언트한테 제공한다" 라는 말이 토큰 응답에 포함된 token_type 값과 그 값의 의미를 정의한 명세를 통해 클라이언트가 액세스 토큰을 어떻게 사용해야 하는지 알 수 있게 된다. 

형태: token_type 필드
의미: RFC에 정의됨
결과: 클라이언트가 올바른 요청을 만들 수 있음

 

예를 들어, [RFC6750]에 정의된 "bearer" 토큰 유형은 요청에 액세스 토큰 문자열을 단순히 포함하는 방식으로 사용된다:

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

 

반면, [OAuth-HTTP-MAC]에 정의된 "mac" 토큰 유형은 액세스 토큰과 함께 메시지 인증 코드(MAC) 키를 발급하여, HTTP 요청의 특정 구성 요소에 서명하는 데 사용된다:

mac 유형?
- MAC 토큰은 “토큰을 그냥 보여주는 방식(Bearer)”이 아니라, 매 요청마다 비밀 키로 요청을 서명해서 보내는 토큰 유형이다.
- MAC = Message Authentication Code 즉, access_token만 보내는 게 아니라 access_token + 비밀 키 요청 내용을 서명(sign) 해서 보냄 -> 요청이 위조되지 않았고, 중간에서 변조되지 않았음을 증명

Bearer 토큰과의 차이
- Bearer : 요청마다 서명 X, 구현 난이도 매우 쉬움, 토큰 탈취시 바로 악용 가능
- MAC : 요청을 서명해야 OK, 구현 난이도 매우 어려움, 토큰 탈취시 서명 키 없으면 불가

 

GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
                   nonce="274312:dj83hs9s",
                   mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

 

위의 예시들은 설명을 위한 목적일 뿐이다. 개발자는 사용에 앞서 [RFC6750] 및 [OAuth-HTTP-MAC] 명세를 참고하는 것이 권장된다.

 

각 액세스 토큰 유형 정의는 "access_token" 응답 매개변수와 함께 클라이언트에게 전달되는 추가 속성(있는 경우)을 명시한다. 또한 보호된 리소스 요청을 수행할 때 액세스 토큰을 포함하기 위해 사용되는 HTTP 인증 방식을 정의한다.

 

7.2 오류 응답

리소스 접근 요청이 실패한 경우

• 리소스 서버는 클라이언트에게 오류를 알려야 한다(SHOULD).
• 이러한 오류 응답의 구체적인 내용은 본 명세의 범위를 벗어나지만, 본 문서는 OAuth 토큰 인증 스킴들 간에 공유될 오류 값들을 위해 11.4절에서 공통 레지스트리를 설정한다.

 

OAuth 토큰 인증을 주된 목적으로 설계된 새로운 인증 스킴은, 이 명세에 의해 설정된 오류 레지스트리에 등록된 오류 값들 중에서 허용되는 오류 값을 사용하여, 클라이언트에게 오류 상태 코드를 제공하는 메커니즘을 정의하는 것이 바람직하다(SHOULD).

 

 

이러한 스킴들은 유효한 오류 코드의 집합을 등록된 값들의 부분집합으로 제한할 수 있다(MAY). 오류 코드가 명명된 매개변수를 통해 반환되는 경우, 해당 매개변수 이름은 "error"여야 한다(SHOULD).

 

OAuth 토큰 인증에 사용될 수 있으나 그 목적을 주로 위해 설계되지 않은 다른 인증 스킴들 또한, 동일한 방식으로 자신의 오류 값들을 이 레지스트리에 바인딩할 수 있다(MAY).

 

새로운 인증 스킴들은 또한, 본 명세에서 사용되는 방식과 병행하여 오류 정보를 반환하기 위해 "error_description" 및 "error_uri" 매개변수의 사용을 명시하도록 선택할 수 있다(MAY).

지금 여기서 말하고 있는 상황은 토큰 발급 단계가 아니라 리소스 접근 단계이다 

즉, 이미 클라이언트는 액세스 토큰을 들고 있고

GET /api/resource
Authorization: Bearer xxx​

이런 요청을 리소스 서버(API 서버)에 보냈는데

- 토큰이 잘못됐거나, 만료됐거나, scope가 부족하거나 일 때 접근 실패한 상황을 다루는 것이다.

“OAuth 토큰 인증 스킴들 간에 공유될 오류 값들을 위해 11.4절에서 공통 레지스트리를 설정한다” 이 말은 각자 제멋대로 "token_expired", "bad_token", "no_auth" 이렇게 쓰지 말고 공통으로 약속된 오류 코드 목록을 만들자 라는 것임

그게 11.4절 오류 레지스트리임.

새로운 인증 스킴은 Bearer, MAC 또는 미래에 새로 정의될 OAuth 기반 인증 방식 즉, Authorization 헤더에 토큰을 넣는 새로운 방식