(WIP) OAuth2 rfc6749 번역

0. 들어가며

안녕하세요. 요새 OAuth 개발 쪽 업무를 맡아 공부할 일이 있어서 OAuth rfc6749 문서를 번역해봤습니다. 최대한 이해하기 쉽게 번역하고자 노력했으나, 오역이 있다면 언제든지 댓글로 피드백 부탁드리겠습니다.

또한, OAuth에서 주로 사용되는 용어들은 한글로 번역했을 때 오히려 헷갈리는 경향이 있어 고정된 용어들은 모두 소문자 영어로 표기하였습니다. 이에 대해서는 1.1 Roles 에서 정리하였으니, 보시고 가면 문서 읽기에 수월하실 것 같습니다.

1. Introduction

1.1 Roles

resource owner : 제한된 리소스에 접근할 수 있는 권한을 가진 존재. resource owner가 사람이라면 사용자를 의미한다. (Application 자체가 Resource owner가 되는 경우도 있습니다. ##1.3.4를 참고해주세요)
resource server : 제한된 리소스를 호스팅하는 서버, access tokens을 이용해 제한된 리소스에 대해 요청하고 응답 받을 수 있다.
client : resource owner의 인증을 가지고 제한된 리소스에 대해 요청을 보내는 어플리케이션. client라는 용어는 특정한 구현을 의미하지 않는다. (e.g 이 어플리케이션은 서버, 데스크톱, 어떤 기기든지 될 수 있다.)
authorization server : resource owner가 인증 시도를 할 수 있고, 인증에 성공했다면 clinet에게 access tokens을 발급하는 서버.
resource owner : 제한된 리소스에 접근할 수 있는 권한을 가진 존재. resource owner가 사람이라면 사용자를 의미한다.

1.5 Refresh Token

Refresh Tokens 은 Access Tokens을 얻기 위한 자격이다. Refresh tokens은 Authorization Server 에 의해 발급되어지고 현재 Access Token 이 만료되거나 무효화 되었을 때 새로운 access token을 발급되기 위해 사용된다. 또는 동일하거나 더 작은 규모의 Scope 을 가지고 있는 Access tokens을 받기 위해 사용된다.

1.8 Interoperability (상호 운용성)

OAuth 2.0 은 다양한 인증 프레임워크를 여러 보안 속성과 함가지고 제공한다. 그러나, 풍부하고 선택쩍인 요소들과 확장가능한 프레임워크는, 그것 스스로, 이 설명서는 다양한 상호 정보 교환이 가능하지 않은 구현체를 만들 가능성이 높다.

추가적으로, 이런 설명서는 여러 필요한 컴포넌트를 선택적이거나 완전 정의되지 않은 상태로 정의하고 있다(e.g 클라이언트 등록, Authorization Server 능력들, Endpoint 탐색) 이런 요소들 없이, Clients는 명확하게 구성된 Authorization Server와 Resourse Server과 상호 운용하기 위해 직접 명확하게 구성되어야 한다.

이 프레임워크는 미래의 작업들이 규범적인 방식과 모든 웹 규모의 상호운용성을 달성할 수 있을 정도로 확장 가능하도록 기대하며 디자인 되었다.

1.9 Notational Conventions (표기 관습)

2. Client Registration

프로토콜을 시작하기 전에, Client는 Authorization Server에 등록되어야 한다. Client가 Authorization Server에 등록하는 방식은 이 문서에 작성되어 있지 않다 그러나 전형적으로 end-user 와 HTML 가입 폼에 의해 상호작용하도록 설계된다.

Client registration 은 Cleint와 Authorization Server와 직접 상호 작용을 하지 않아도 된다. Authorization Server에서 지원한다면, registration은 권한 획득과 Client 속성(Regirection URI, client type)을 얻기 위해 다른 방식을 사용할 수 있다. 예를 들면, Registration 은 직접 발급되거나 third-party 에 의해 발급된 인증서, 혹은 인증된 채널에 의해 Client를 확인하는 Authorization server에 의해 수행될 수 있다.

client 를 등록할 때, client 개발자들은 하기와 같이 하는게 좋다.

client types을 명확이 하라. ## 2.1 처럼 (나중에 이거 문서 내에 링크 달아보자)
client의 redirection URI를 제공하라. ## 3.1.2 처럼
authorization server가 필요한 모든 정보를 포함하라 (e.g., application name, website, description, logo image, the acceptance of legal terms).

2.1 Client Types

OAuth 는 Authorization Server와 안전하게 통신할 수 있는 능력에 따라 두가지 클라이언트 종류를 정의한다. (i.e: 보안 정보를 그들의 client 인증정보를 안전하게 저장할 수 있는 능력)

confidential

인증정보를 신뢰할수 있게 저장할 수 있는 Clients (e.g client credentials 에 접근이 제한된 보안 서버가 구현된 client) 또는 어떤 방법을 쓰더라도 안전한 인증을 사용할 수 있는 Client

public

인증정보를 신뢰할 수 있게 저장하지 못하는 Clients (e.g Resource Owner의 기기에서 시행되는 Clients, 예를 들면 설치된 Native 어플리케이션 또는 웹 브라우저 기반 어플리케이션) 또는 어떤 방식으로든 안전한 인증을 사용하지 못하는 Client

Client Type을 지정하는 것은 Authorization Server가 안전한 인증의 정의와 Client Credential의 수용 가능한 노출 정도를 정의함에 따라 결정된다. Authorization Server는 client type에 대해 정확히 추정해야만 한다. Client는 각각 다른 Client type과 보안적 상황을 가지는 컴포넌트들에 의해 구현될 수도 있다. (e.g 인증된 서버 기반 컴포넌트와 public한 브라우저 기반 컴포넌트) 만약 Authorization Server가 이런 클라이언트들에 대해 지원하지 않고 등록하는 것에 대한 가이드도 없다면, Client는 각 컴포넌트를 개별적인 Client로 등록해야만 한다.

이 문서는 다음과 같은 Client Profiles 에 대해 디자인 되었다.

Web application : 웹 서버와 함께있는 신뢰가능한 Client 이다. Resource Owners는 유저가 사용하는 기기에 렌더링된 HTML 유저 인터페이스를 통해 Clinet에 접근한다. 그 Client 인증정보와 Client에게 발급된 Access Token은 웹 서버에 저장되고 Resource Owner에게 노출되어 지지 않는다.
user-agent-based application : Client code 가 웹 서버를 통해 다운받아지고 유저가 사용하는 기기의 user-agent 안에서 시행되는(e.g 웹 브라우져) public Client 이다. 통신 데이터와 인증정보는 Resource owner에게 쉽게 접근이 가능하다. 이러한 애플리케이션들은 user-agent와 있기 때문에 인증을 요청할 때 user-agent 능력들을 사용한다. (예를 들면, Mobile App의 기본 브라우저에서 Facebook 로그인을 하면 기본 브라우저의 Facebook 로그인 세션 정보를 이용해 인증한다)
native application : 유저가 사용하는 기기에 다운받아진 public client 이다. 통신 데이터와 인증정보는 Resource ownere에게 쉽게 접근이 가능하다. 어떤 Client든 이 어플리케이션에 포함된 인증 인증정보는 추출되어 질 수 있다. 이와 반대로, Access Token 혹은 Refresh Token 처럼 동적으로 발급되어진 인증정보들은 수용가능한 보호를 받을 수 있다. 적어도, 그런 인증정보는 적대적인 서버로부터 접근이 불가능하다. 여러 플랫폼에서, 이 인증정보들과 같은 기기에 있는 어플리케이션으로부터 보호된다.

2.2 Client Identifier

authorization server는 등록된 client에게 client identifier 를 발급해준다. client의 등록 정보를 담고 있는 고유한 문자열이다. client identifier 는 비밀이 아니다. 그것은 resource owner에게 노출되어지므로 client authentication에 단독적으로 사용되어선 안된다. 또한, client identifier는 authorization server에서 유일하게 다뤄져야 한다.

client identifier 의 문자열 사이즈는 이 문서에서 정의되지 않는다. client는 그 사이즈에 대해 가정하지 않아야 한다. authorization server는 이 사이즈에 대해 문서화 시키고 client 측에 공표해야 한다.

2.3 Client Authentication

만약 client type이 confidential 이라면, client와 authorization server는 client 인증 방식을 보안 정책에 맞게 세워야 한다. authorization server는 client 인증의 여러 형태를 허용해야 할수도 있다.

confidential clients는 일반적으로 authorization server와 인증하기 위한 client 인증정보들이 발급된다. (e.g 비밀번호, public/private 키페어)

authorization server는 public clients과의 인증 방식도 만들어야 할 수도 있다. 그러나 authorization server는 client를 확인하기 위해 public client와의 인증만 의존하면 안된다.

client는 각 요청마다 1개 이상의 인증 방식을 사용하면 안된다.

2.3.1 Client Password

client password 를 소유하는 clients들은 HTTP Basic 인증 방식을 이용해 authorization server와 인증한다. cleint indetifier는 application/x-www-form-urlencoded에 쓰는 알고리즘을 이용해 인코딩 되어지고, 암호화된 값은 username으로 사용된다. client password 는 password 에서 사용되었던 것과 같은 알고리즘으로 인코딩된다. authorization server는 client password가 발급되어진 cleints들을 인증하기 위해서 HTTP Basic 인증 방식을 지원해야만 한다.

예를 들면, HTTP Basic 인증 방식으로 아래와 같이 client을 인증할 수 있다.

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

이 방법 대신에, authoizartion server는 request-body 에 다음과 같이 parameter로 client 인증정보들을 넘길수도 있다.

client_id : REQUIRED. The client identifier issued to the client during the registration process described by Section 2.2.
client_secret : REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string.

그러나 request-body 에 두 파라미터를 넘기는 것은 추천되지 않으며 HTTP Basic 인증 방식을 사용하지 못하는 클라이언트들만 사용해야 한다. (혹은 password based HTTP 인증 방식을 사용하거나) 이 파라미터들은 request-body를 통해 보내질 수 있음 request URI 에 담기면 안된다.

예를 들면, body 파라미터들을 사용하는 access token을 갱신하는 요청(### Section 6 참고)

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

authorization server는 ###1.6 에 언급되었듯이, 비밀번호 인증을 이용한 요청을 보낼 때 TLS를 반드시 지원해야 한다.

이 client 인증 방식이 비밀번호를 포함하기 때문에, authorization server은 모든 endpoint를 brute force attacks 로부터 보호해야 한다.

2.3.2 Other Authentication Methods

authorization server는 보안 요구사항에 맞는 모든 적합한 HTTP 인증 방식을 지원할 수도 있다. 다른 인증 방식을 이용할 때, authorization server는 인증 방식으로부터 client identifer를 추출해서 연결해줘야 한다.

2.4 Unregistered Clients

이 문서는 등록되지 않은 clients 를 사용하는 것을 제외하라고 하지 않는다. 그러나, 이러한 client를 사용하는 것은 이 문서의 범위를 넘어섰고, 추가적인 보안 분석과 상호운용성 영향을 다시 검토해봐야 할 것이다.

3. Protocol Endpoints

인증 방식은 2가지 authorization server endpoints를 진행한다.(HTTP resources)

Authorization endpoint : clinent가 사용자 기기 리다이렉션을 통해 resource ownere이 자격 증명하도록 시킬 때 이용한다.
Token endpoint : client가 authorization grant 를 access token과 교환할 때 사용된다. 이 때 client 인증도 보내줘야 한다.

또한 client endpoint도 다음과 같다.

Redirection endpoint : authorization server가 인증 정보를 포함해 resource owner의 기기에 response를 돌려줄 때 사용된다.

모든 인증 승인 타입이 모든 endpoints를 사용하지는 않는다. 확장 승인 타입은 필요하다면 다른 endpoints들도 정의할 수 있다.

3.1 Authorization endpoint

인증 endpoint는 resource owner와 상호작용할 때 사용되어 자격 증명을 획득할 수 있다. authorization server는 반드시 resource owner의 신원을 입증해야 한다. authorization server가 resource owner를 입증하는 방식(e.g 유저네임과 비밀번호, 세션 쿠키값)은 이 문서의 범위 밖이다.

client 가 authorization endpoint를 얻는 방법은 이 문서의 범위 밖이다. 일반적으로 그 endpoint 는 서비스 문서에서 제공되곤 한다.

endpoint URI 는 application/x-www-form-urlencoded으로 포맷된 query component 를 포함해야 한다. 추가적인 쿼리 파라미터들이 필요할 때 query component에 포함시킬 수 있다. endpoint URI는 fragment component를 포함하고 있어서는 안된다.

authorization endpoint으로 한 요청들은 유저 인증을 하고 알아보기 쉬운 인증 정보들을 전송한다. authorization server는 1.6에 언급되었듯이 authorization endpoint로 요청할 때 TLS 로 요청할 수 있어야 한다.

authorization server는 authorization endpoint를 위해 HTTP GET 방식도 지원해야 하며 POST 방식도 지원해야 한다.

값 없이 보내진 파라미터들은 요청에서 제외된 것 처럼 다뤄져야 한다. authorization server는 인식되지 않은 요청 파라미터들을 무시해야 한다. 요청과 응답 파라미터들은 한 번 이상 포함되서는 안된다.

3.1.1 Response Type

authorization endpoint는 authorization code 인증 방식과 implict 인증 방식 플로우에서 사용된다. client authorization server 에게 원하는 인증 방식을 다음과 같은 파라미터를 이용해서 알려준다.

response_type : REQUIRED. The value MUST be one of “code” for requesting an authorization code as described by Section 4.1.1, “token” for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4.

확장 응답 타입은 순서가 중요하지 않은 여러 값들을 가질 수 있다. 이런 합성 응답 타입들은의 의미는 각각의 명세서에 따라 정의될 수 있다.

만약 인증 요청이 response_type 파라미터가 없거나 이상한 값이라면 authorization server는 반드시 4.1.2.1를 참고해서 error를 보내야 한다.

3.1.2 Redirection Endpoint

resource owner 와 상호작용을 마친 이후에, authorization server는 resource owner의 유저 기기를 client 측으로 인도해야 한다. authorization server가 유저 기기를 client를 이전에 client 등록 과정을 거쳤거나 인증 요청을 보내면서 authorization server에다 설정된 redirection endpoint로 돌려준다.

redirection endpoint URI는 반드시 absolute URI 여야만한다. (## 4.3에 정의되어 있음) endpoint URI 는 application/x-www-form-urlencoded으로 포맷된 query component 를 포함해야 한다. 추가적인 쿼리 파라미터들이 필요할 때 query component에 포함시킬 수 있다. endpoint URI는 fragment component를 포함하고 있어서는 안된다.

3.1.2.1 Endpoint Request Confidentiality(비밀, 보안)

redirection endpoint는 만약 response type이 “code” 혹은 “token” 이거나 redirection request가 민감한 인증정보를 포함한다면 반드시 TLS를 사용해야만 한다.이 문서는 개발자들이 TLS 세팅에 고통받을 것을 고려해 TLS 사용을 강제하지 않는다. 만약 TLS 가 불가능하다면, authorization server 는 반드시 resource owner에게 endpoint가 안전하지 않다고 경고해야 한다. (e.g 권한 요청 동안 메세지를 띄운다)

TLS(Transport Layer Security)의 결여는 client와 보호된 자원의 안전에 심각한 영향을 끼칠 수 있다. TLS의 사용은 특히 인증 과정이 client에 의해 사용자 인증 폼으로 실행될 때 더욱 중요하다. (e.g third-party 로그인 서비스)

3.1.2.2 Registration Requirements

authorization server 는 반드시 다음과 같은 client들이 redirection endpoint를 등록할 수 있게 해야 한다.

public clients
implict 승인 방식을 사용하는 confidential clients

authorization server는 반드시 모든 clients가 authorization endpoint를 이용하기 전에 그들의 redirection endpoint를 등록시키게 해야 한다.

authorization server는 반드시 client가 완전한 redirection URI 를 제공하도록 해야 한다. (client는 state라는 요청 파라미터를 각 요청마다 커스텀해서 보낼 수도 있다. 요건 보안 이슈 CSRF 와 관계되어 있으나 추후 설명하겠다) 만약 완전한 redirection RUIRI를 등록하는 것을 요구하는 게 불가능하다면, authorization server는 URI scheme, authority, path를 등록 시키게 해야만 한다. (client가 인증 요청할 때 동적으로 query compoent를 변화시킬 수 있다.)

authorization server는 client가 여러 redirection endpoint를 등록하게 할 수도 있다.

redirection URI를 등록하지 않으면 공격자들이 authorization endpoint를 open redirector로 변경해서 공격할 수 있다. (Section 10.15)

3.1.2.3 Dynamic Configuration

만약 다양한 redirection URI들이 등록되었다면, redirection URI의 유일한 부분들만 등록되었거나, 아무런 redirection URI가 등록되지 않았다면, client는 인증 쵸어시 redirection URI를 “redirect_uri” 라는 요청 파라미터에 포함해서 보내야 한다.

redirection URI 가 인증 요청에 포함된다면, authorization server는 반드시 등록된 redirection URI 중 하나인지(또는 그 중 하나의 요소인지) 비교해야 한다. 만약 client 등록된 것에 전체 redirection URI가 있다면, authorization server는 반드시 두 URI를 간단한 문자열 비교를 이용해 비교해야 한다. (그냥 뭐 일정 패턴으로 넣을수도 있고, 전체로 넣을수도 있는데 그걸 비교해봐라! 그런 것 같다)

3.1.2.4 Invalid Endpoint

만약 인증 요청이 무효한, 옳지 않은 redirection URI 때문에 인증에 실패하면, authorization server는 반드시 resource owner에게 에러를 알려줘야 하고, invalid 한 redirection URI로 리턴되면 안 된다.

3.1.2.5 Endpoint Content

client’s endpoint 로의 redirection request는 전형적으로 유저 기기에 HTML 문서를 응답한다. 만약 HTML 응답이 직접 redirection request 의 결과로 전해진다면, 해당 HTML의 모든 script는 redirection URI와 그 안에 포함된 인증정보에 접근할 수 있도록 실행된다.

즉, client는 반드시 redirection endpoint 응답으로 third-party scripts를 포함하면 안된다. 대신에, URI로부터 인증정보를 추출하고 유저 기기로 다시 리다이렉트 시켜야만 한다. 만약 third-party 스크립트가 포함되었따면, client는 반드시 인증정보를 추출하고 제거하는 스크립트가 가장 먼저 시행되도록 해야 한다.

3.2 Token Endpoint

token endpoint는 client가 authorization grant 혹은 refresh token을 이용해 access token을 획득할 때 사용된다. token endpoint는 implict 인증 방식(얘네는 그냥 access token이 바로 발급됨)을 제외한 모든 인증 방식에서 사용된다.

client가 token endpoint를 얻는 방법은 이 문서의 범위 밖이다. 일반적으로 그 endpoint 는 서비스 문서에서 제공되곤 한다.

token endpoint으로 한 요청들은 유저 인증을 하고 알아보기 쉬운 인증 정보들을 전송한다. authorization server는 1.6에 언급되었듯이 token endpoint로 요청할 때 TLS 로 요청할 수 있어야 한다.

client 는 반드시 access token 요청을 만들 때 POST method 를 사용해야 한다.

3.2.1 Client Authentication

client 인증 정보를 발행한 confidential client 또는 다른 client들은 token endpoint에 요청을 할 때 반드시 authorization server와 인증해야 한다. client 인증은 다음과 같이 사용된다.

refresh token과 authorization code 들을 그들이 발급된 client로 가도록 강제한다. client 인증은 비인증 채널을 통해 authorization code가 redirection url 로 전송될 때 혹은 redirection URI 가 모두 등록되지 않았을 때 중요하다.
refresh token을 탈취 당해서 공격자로부터 악용될 가능성을 없애고 싶을 때, client 를 비활성화 시키거나 인증 정보를 변경함으로써 합의된 client 를 제거한다. client 인증 정보의 세트를 변경하는 것이 refresh token을 모두 폐지하는 것보다 훨씬 빠르다.
인증 관리를 구현하는 최고의 방법은 주기적으로 인증 정보를 변경하도록 하는 것이다. refresh toekns의 전체 세트를 변경하는 것은 어렵지만, client credential 한 세트를 변경하는 것은 상당히 쉽다.

client는 token endpoint로 요청을 날릴 때 “clinet_id” 라는 요청 파라미터를 인증을 위해 사용할 수 있다. “authorization_code” 인증 방식의 token endpoint로 요청을 할 때, 인증 되지 않은 client는 무심코 다른 client_id의 code를 수용하지 않기 위해서는 반드시 “client_id”를 보내야만 한다. 이것은 client가 인증 코드를 대체하는 것을 막아준다. (이것이 보호된 리소스에 대해 추가적인 보안을 해주진 않는다.)

3.3 Access Token Scope

authorization 과 token endpoints는 client가 접근 요청에 대해 “scope” 라는 요청 파라미터로 scope를 설정할 수 있도록 한다. 결국, authorization server는 “scope” 응답 파라미터를 통해 client에게 발급된 access token의 scope를 알려준다.

scope 파라미터의 값은 , 로 구분되며, 대소문자 구분되도록 표현된다. 해당 문자열은 authorization server에 의해 정의된다. 만약 그 값이 다양한 문자열로 구성되어 있다면, 그 순서는 중요하지 않고 각 문자열에 따라 요청한 범위에 추가적인 접근 권한을 추가해준다.

authorization server 는 서버 정책 혹은 resouce owner의 지시에 따라 완전히 혹은 부분적으로 client에게 요청했던 scope를 무시할 수도 있다. 만약 발행된 access token의 범위가 client가 요청했던것과 다르다면, authorization server는 반드시 “scope” 응답 파라미터를 포함시켜 client 에게 실제 승인된 scope에 대해 알려줘야 한다.

만약 client가 인증을 요청할 때 scope parameter를 빼먹었다면, authorization server는 미리 정해진 기본 값을 가지고 요청을 진행하거나 무효한 scope라고 하며 요청을 실패시켜야 한다. authorization serve는 scope와 기본 값(만약 있다면)을 문서화시켜야 한다.

4. Obtaining Authorization

access token을 요청하기 위해 client는 resource owner로부터 권한을 얻는다. client는 권한을 인증 방식(Authorization Grant)을 이용해 획득할 수 있다. 그리고 client는 권한을 이용해 access token을 얻을 수 있다.

OAuth는 4가지 타입의 인증 방식을 정의한다. authorization code, implicit, resource owner password credentials, and client credentials. 또한 추가적인 인증 방식을 정의하기 위한 확장되는 메커니즘을 제공한다.

4.1 Authorization Code Grant

인증 코드 허가 방식은 access token과 refresh token 모두를 얻기 위해 사용되며 confidential client 에 최적화되어있다. 이것은 redirection 기반 플로우기 때문에, client는 반드시 resource owner 의 기기(주로 웹 브라우저)와 상호작용할 수 있어야 하며, authorization server로부터 들어오는 요청들 (리다이렉션을 통해) 을 받을 수 있어야 한다.

All Text

Authorization Code Flow

위의 그림에서 묘사된 플로우는 다음과 같은 단계를 가진다.

(A) : client가 resource owner의 기기를 authorization endpoint로 인도하면서 플로우가 시작된다. client가 client identifier, 요청한 scope, local state, 그리고 승인된다면 authorization server가 user-agent를 돌려 보낼 redirection URI을 포함해서 보낸다.
(B) : authorization server가 resource owner를 인증한다 (유저 기기를 통해) 그리고 resource owner가 client의 접근 요청을 승인할지 거부할지를 결정한다.
(C) : resource owner가 접근을 승인했다면, authorization server는 유저 기기를 이전에 제공했던 redirection URI로 리다이렉트 시킨다(client 등록 시에 넣었거나 (A)request에 넣은 URI) redirection URI에는 인증 코드와 (A)에서 넣어놨던 local state 값을 포함되어져 있다.
(D) : client 는 authorization server에게 (C)에서 획득한 인증 코드를 포함해 access token을 token endpoint에게 요청한다.
(E) : authorization server 는 client 를 인증하고, authorization code 를 검증하고 (C)에서 받은 redirection URI가 동일한지 확인한다. 만약 유효하다면, authorization server는 access token 과 선택적으로 refresh token을 반환한다.

4.1.1 Authorization Request

client 는 다음과 같은 쿼리 요소들을 “application/x-www-form-urlencoded” 형태로 포함시킴으로써 요청 URI를 만든다.

response_type : 필수. 그 값은 “code” 여야 한다.
client_id : 필수. ##2.2 에 언급했듯이 client identifier 이다
redirect_uri : 선택적. ##3.1.2 에 서술되어있다.
scope : 선택적. ##3.3에 서술되었듯 접근 요청의 범위이다.
state : 권장함. client가 request 와 callback 사이의 state를 유지하기 위해 사용되는 값. authorization server 는 유저 기기에서 client 로 리다이렉트될 때 이 값을 포함하고 있다. 이 파라미터는 cross-site request forgery(CSRF)(10.12 에 서술됨)을 막기 위해 사용되어야 한다.

client 는 HTTP 리다이렉션 응답 혹은 유저 기기에서 사용가능한 방식을 통해 정해진 URI로 resource owner를 보낸다.

예를 들면, client 는 다음과 같은 HTTP 요청을 TLS를 이용해 하게 된다.

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

authorization server가 그 요청에 모든 필요한 파라미터가 존재하는지, 유효한지 검증한다. 만약 요청이 유효하다면, authorization server는 resource owner 를 인증하고 인증 결정을 획득한다.(resource owener 에게 물어보거나 다른 방식으로 승인시킨다)

인증되면, authorization server는 유저 기기를 제시된 client를 HTTP 혹은 다른 방식을 통해 리다이렉션 URI로 보내준다.

4.1.2 Authorization Response

만약 resource owner 가 권한 요청을 승인했다면, authorization server는 인증 코드를 발급하고 그것을 redirection URI의 query component에 “application/x-www-form-urlencoded” 형태로 추가해서 전달해준다.

code : 필수. authorization server로 부터 생성된 인증 코드. 인증 코드는 그것이 노출될 위험을 감소시키기 위해 발급되고 나서 빠르게 만료되어야만 한다. 최대 인증 코드의 생명주기는 10분이 권장된다. client는 인증 코드를 한 번 이상 사용할 수 없다. 만약 인증 코드가 한 번 이상 사용되면 authorization server는 그 요청을 거부하고 그 authorization code를 기반으로 만들어진 모든 토큰들을 무효화시켜야 한다.(가능하다면) 인증 코드는 client identifier와 redirection URI에 달려있다.
state : 만약 client 인증 요청에서 존재했다면 필수. client 로부터 받은 값과 동일해야 한다.

예를 들면, authorization server는 유저 기기를 다음과 같이 응답해줌으로써 리다이렉트 시켜야 한다.

HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

client 는 인식되지않은 응답 파라미터를 반드시 무시해야만 한다. 인증 코드 문자열 사이즈가 이 문서에서는 정의하지 않는다. 즉, client는 code 값 사이즈에 대해 추정해서는 안된다. authorization server는 발급되는 모든 값에 대한 크기를 문서화해둬야만 한다.

4.1.2.1 Error Response

만약 응답이 redirection URI가 없거나, 무효하거나 일치하지 않아서 실패했거나, client identifier 가 업석나 무효해서 실패했다면, authorization server는 반드시 resource owener 에게 에러를 알려줘야만 하고, 자동으로 기기를 올바르지 않은 redirection URI로 리다이렉트 시키면 안된다.

만약 resource owener 가 접근 요청을 거부했거나 redirection URI 가 없어서 요청에 실패했다면, authorization server 는 client 에게 query component에 “application/x-www-form-urlencoded” 형태로 추가해서 전달해준다.

error : 필수. 다음과 같은 하나의 ASCII 에러 코드이다. “error” 파라미터에 대한 값은 반드시 %x20-21 / %x23-5B / %x5D-7E 이외의 문자를 가지면 안된다.
- invalid_request : 요청에 필요한 파라미터가 없거나, 무효한 파라미터 값이 있거나, 하나 이상의 파라미터가 있거나 기형의 파라미터가 있다.
- unauthorized_client : 이 client는 이 방식을 이용해 인증 코드를 요청할 권한이 없다.
- access_denied : resource owner 혹은 authorization server가 이 요청을 거부했다.
- unsupported_response_type : authorization server는 이 방식을 이용해 인증 코드를 요청하는 걸 지원하지 않는다.
- invalid_scope : 이 범위는 무효하고, 모르고, 기형이다.
- server_error : authorization server 는 해당 요청을 수행하지 못하는 예상하지 못한 상황에 마주쳤다.(이 에러 코드는 500 Internal Server ERROR가 client 한테 HTTP 리다이렉트를 통해 리턴될 수 없으므로 필요하다.)
- temporarily_unavailable : authorization server 는 일시적인 overloading 과 서버 유지 때문에 현재 요청을 처리할 수 없다. (이 에러 코드는 503 Service Unavaliable 가 client 한테 HTTP 리다이렉트를 통해 리턴될 수 없으므로 필요하다.)
error_description : 선택적. 추가적인 정보를 제공하는 인간이 읽을 수 있는 ASCII 글자이다. client 개발자들이 발생한 에러를 이해하는 걸 돕기 위해 사용된다. “error_description” 파라미터에 대한 값은 반드시 %x20-21 / %x23-5B / %x5D-7E 이외의 문자를 가지면 안된다.
error_uri : 선택적. 해당 에러에 대한 정보를 사람이 읽기 쉽게 만든 웹페이지 링크. client 개발자들이 발생한 에러를 이해하는 걸 돕기 위해 사용된다. “error_uri” 파라미터에 대한 값들은 URI-reference 문법을 따라야 하며 반드시 %x20-21 / %x23-5B / %x5D-7E 이외의 문자를 가지면 안된다.
state : client 인증 요청에 있었다면 반드시 존재해야 한다. client 가 보낸 값과 동일해야만 한다.

예를 들면, authorization server는 유저 기기를 다음과 같이 리다이렉트 시켜줘야 한다.

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3 Access Token Request

client 는

8. Extensibility

8.1 Defining Access Token Types

access token types은 두가지 방식으로 정의될 수 있다. acceess token types 등록소에 등록되어 있거나 (Section 11.1 을 참고하자.) 고유의 절대 경로를 그 이름으로 사용하면 된다.

URI 이름을 이용하는 타입들은 반드시 특정 회사 구현체로 제한되어야 한다. 흔히 적용되는 것이 아니며, 그것들이 사용되는 resource server의 구현 디테일과 맞아야 한다.

모든 다른 타입들은 반드시 등록되어야 한다. 타입 이름들은 type-name ABNF에 따라야 한다. 만약 타입 정의가 새로운 HTTP 인증 방식을 포함한다면, 그 타입 이름은 HTTP 인증 방식 이름과 동일 해야만한다. (RFC2617 문서에 정의되어 있듯이) 토큰 타입 “example”은 이런 예시들을 위해 사용되어야 한다.

type-name = 1*name-char

name-char = “-“ / “.” / “_” / DIGIT / ALPHA