[OAuth 2.0] 8. Extensibility(확장성)

이 문단은 token_type(액세스 토큰 유형)을 새로 만들고 싶을 때, 그 이름과 정의를 어떻게 정해야 하는지에 대한 규칙을 설명한다. 

즉, 인가 코드 방식/ 암묵적 방식/ 클라이언트 자격 증명 방식 X, 토큰을 실제로 쓰는 방법 설명 X -> OAuth를 확장하려는 사람을 위한 규칙

8.1 액세스 토큰 유형 정의

이 문단은 

{
  "access_token": "...",
  "token_type": "Bearer"
}​

 

여기서 token_type 값 -> Bearer, mac 혹은 미래에 새로 정의될 값들

이 문단은 이 token_type을 어떻게 정의해야 하느냐를 말하고 있다.

액세스 토큰 유형은 다음 두 가지 방법 중 하나로 정의될 수 있다:

방법 1. 액세스 토큰 유형 레지스트리에 등록
- Bearer처럼 공식 표준
- 누구나 공통으로 이해해야 하는 타입

방법 2. 고유한 절대 URI를 이름으로 사용

urn:example:my-company:token-type​

- 특정 회사/ 특정 서버 전용
- 표준화할 생각 없는 경우

11.1절에 명시된 절차에 따라 액세스 토큰 유형 레지스트리에 등록하거나, 또는 고유한 절대 URI를 이름으로 사용한다.

 

URI 이름을 사용하는 유형은, 일반적으로 널리 적용되지 않고 해당 리소스 서버의 구현 세부 사항에 특화된 벤더 전용 구현으로 제한되는 것이 바람직하다(SHOULD).

너희 회사만 쓰는 토큰 타입이면 그냥 URI 써서 내부적으로 해라는 말 즉, Google 전용, kakao 전용, 사내 전용 같은 경우

 

그 외의 모든 유형은 반드시 등록되어야 한다(MUST). 유형 이름은 type-name ABNF에 부합해야 한다. 유형 정의에 새로운 HTTP 인증 스킴이 포함되는 경우, 해당 유형 이름은 [RFC2617]에 정의된 HTTP 인증 스킴 이름과 동일한 것이 바람직하다(SHOULD). "example" 토큰 유형은 예제에서 사용하기 위해 예약되어 있다.

type-name  = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA

 

범용적으로 쓰일 토큰 타입이면 반드시 공직 레지스트리에 등로해라 왜? 다른 클라이언트, 다른 라이브러리, 다른 서버가 이 타입을 이해해야 하기 때문 유형 이름은 type-name ABNF를 따라야한다라는 말은 이건 token_type 값의 형식 규칙

즉 허용되는 예가
- Bearer
- mac 
- example_token 

허용 안 되는 예
- bearer!
- my token
- 토큰

HTTP 인증 스킴이 포함되면 이름을 맞추는 게 바람직이라는 말은
- token_type은 결국

Authorization: <token_type> <token>​

여기 들어가는데 token_type 이름, Authorization 스킴이름을 같에 맞추는 게 좋다는 뜻

예

Authorization: Bearer xxx​

token_type = Bearer
인증 스킴 이름 = Bearer

 

8.2 새로운 엔드포인트 매개변수 정의

인가 엔드포인트 또는 토큰 엔드포인트와 함께 사용하기 위한 새로운 요청 또는 응답 매개변수는, 11.2절에 명시된 절차에 따라 OAuth 매개변수 레지스트리(OAuth Parameters registry) 에 정의되고 등록된다.

 

매개변수 이름은 반드시 param-name ABNF에 부합해야 하며(MUST), 매개변수 값의 구문 또한 반드시 명확하게 정의되어야 한다(MUST)(예: ABNF를 사용하거나, 기존 매개변수의 구문에 대한 참조를 사용하는 방식).

param-name = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

 

일반적으로 널리 적용되지 않고, 사용되는 인가 서버의 구현 세부 사항에 특화된 등록되지 않은 벤더 전용 매개변수 확장은, 다른 등록된 값들과 충돌할 가능성이 낮은 벤더 전용 접두어를 사용하는 것이 바람직하다(SHOULD)(예: 'companyname_'로 시작).

 

8.3 새로운 인가 그랜트 유형 정의

새로운 인가 그랜트 유형은 "grant_type" 매개변수와 함께 사용하기 위해 고유한 절대 URI를 할당함으로써 정의될 수 있다. 확장된 그랜트 유형이 토큰 엔드포인트에 대한 추가 매개변수를 요구하는 경우, 해당 매개변수들은 11.2절에 설명된 바와 같이 OAuth 매개변수 레지스트리에 반드시 등록되어야 한다(MUST).

 

8.4 새로운 인가 엔드포인트 응답 유형 정의

인가 엔드포인트와 함께 사용하기 위한 새로운 응답 유형은 11.3절에 명시된 절차에 따라 인가 엔드포인트 응답 유형 레지스트리(Authorization Endpoint Response Types registry) 에 정의되고 등록된다. 응답 유형 이름은 반드시 response-type ABNF에 부합해야 한다(MUST).

response-type  = response-name *( SP response-name )
response-name  = 1*response-char
response-char  = "_" / DIGIT / ALPHA

 

응답 유형에 하나 이상의 공백 문자(%x20)가 포함된 경우, 이는 값의 순서가 중요하지 않은 공백으로 구분된 값 목록으로 비교된다. 동일한 값 집합에 대해서는 하나의 값 순서만 등록될 수 있으며, 이는 동일한 값 집합의 다른 모든 배열을 포괄한다.

 

예를 들어, "token code" 응답 유형은 본 명세에서 정의되지 않는다. 그러나 확장은 "token code" 응답 유형을 정의하고 등록할 수 있다. 일단 등록되면 동일한 조합을 "code token"으로 등록할 수는 없지만, 두 값 모두 동일한 응답 유형을 나타내는 데 사용할 수 있다.

 이 부분은 인가 엔드 포인트에서 쓰는 response_type을 확장할 때 규칙을 설명하는 거

OAuth에서 response_type은 인가 엔드포인트로 쓰임 
- response_type=code → 인가 코드 방식
- response_type=token → 암묵적 방식

누군가 인가 엔드포인트에서 인가 코드 + 토큰을 한 번에 주면 안되나? 이런 생각할 수 있음
- response_type=code token
이게 바로 새로운 응답 유형

RFC가 규칙을 정해주는 거임
1. 반드시 공식 레지스트리에 등록
2. response_type 이름 형식 규칙
- response_type 값은 하나 이상의 단어 공백(SP)으로 구분 가능 각 단어는 알파벳 / 숫자 / _ 만 가능
허용
- code
- token
- token code
- id_token

불가
- code-token
- code+token
- 코드

공백으로 나열된 값들은 순서가 중요하지 않다 라는 예제를 보여주려고 "token code"를 보여준 것임 이게 OAuth 기본 스펙에는 없음, 하지만 확장으로는 만들 수 있다. 그런데 왜 code token은 안 되냐 같은 값 집합에 대해서는 하나의 순서만 등록이 가능하다라는 것 그래서 레지스트리에는 하나만 등록 하지만 사용은 둘 다 허용

 

8.5 추가 오류 코드 정의

프로토콜 확장(즉, 액세스 토큰 유형, 확장 매개변수 또는 확장 그랜트 유형)이 인가 코드 그랜트 오류 응답(4.1.2.1절), 암묵적 그랜트 오류 응답(4.2.2.1절), 토큰 오류 응답(5.2절) 또는 리소스 접근 오류 응답(7.2절)과 함께 사용하기 위한 추가 오류 코드를 요구하는 경우, 이러한 오류 코드는 정의될 수 있다(MAY).

 

확장 오류 코드는, 함께 사용되는 확장이 등록된 액세스 토큰 유형이거나, 등록된 엔드포인트 매개변수이거나, 또는 확장 그랜트 유형인 경우, 11.4절에 명시된 절차에 따라 반드시 등록되어야 한다(MUST). 등록되지 않은 확장과 함께 사용되는 오류 코드는 등록될 수 있다(MAY).

 

오류 코드는 반드시 error ABNF에 부합해야 하며, 가능한 경우 식별 가능한 이름 접두어를 포함하는 것이 바람직하다(SHOULD). 예를 들어, 확장 매개변수 "example"에 설정된 값이 유효하지 않음을 식별하는 오류는 "example_invalid"로 명명하는 것이 바람직하다.