IETF(국제 표준화 기구)의 RFC 6749(The OAuth 2.0 Authorization Framework) 공부하기 위함
OAuth 2.0 인증 프레임 워크를 사용하면 리소스 소유자와 HTTP 서비스 간의 승인 상호 작용을 조정하거나 타사 애플리케이션이 자신을 대신하여 액세스 권한을 얻습니다. 이 사양은 RFC 5849에 설명 된 OAuth 1.0 프로토콜을 대체하고 폐기합니다.
이것은 인터넷 표준 추적 문서입니다. 이 문서는 IETF (Internet Engineering Task Force)의 제품입니다. IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 받았으며 IESG (Internet Engineering Steering Group)의 게시 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 5741의 섹션 2에서 확인할 수 있습니다.이 문서의 현재 상태, 정오표 및 이에 대한 피드백 제공 방법에 대한 정보는 http://www.rfc-editor.org/info/rfc6749 에서 얻을 수 있습니다.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
- RFC6749
- The OAuth 2.0 Authorization Framework
- Table of Contents
- 1. Introduction
- 2. 클라이언트 등록
- 3. Protocol Endpoints
- 4. 권한 부여 받기
- 5. 액세스 토큰 발급
- 6. 액세스 토큰 새로 고침
- 7. 보호 된 리소스에 액세스
- 8. 확장성
- 9. 네이티브 애플리케이션
- 10. 보안 고려 사항
- 10.1. 클라이언트 인증
- 10.2. 클라이언트 가장
- 10.3. 액세스 토큰
- 10.4. 새로 고침 토큰
- 10.5. 권한 부여 코드
- 10.6. 권한 부여 코드 리디렉션 URI 조작
- 10.7. 리소스 소유자 암호 자격 증명
- 10.8. 기밀성 요청
- 10.9. 엔드 포인트 신뢰성 보장
- 10.10. 자격 증명 추측 공격
- 10.11. 피싱 공격
- 10.12. 교차 사이트 요청 위조
- 10.13. Clickjacking
- 10.14. 코드 삽입 및 입력 유효성 검사
- 10.15. 리디렉터 열기
- 10.16. 암시적 흐름에서 리소스 소유자로 가장하기위한 액세스 토큰의 오용
- 11. IANA Considerations
- 12. References
- Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
- A.1. "client_id" Syntax
- A.2. "client_secret" Syntax
- A.3. "response_type" Syntax
- A.4. "scope" Syntax
- A.5. "state" Syntax
- A.6. "redirect_uri" Syntax
- A.7. "error" Syntax
- A.8. "error_description" Syntax
- A.9. "error_uri" Syntax
- A.10. "grant_type" Syntax
- A.11. "code" Syntax
- A.12. "access_token" Syntax
- A.13. "token_type" Syntax
- A.14. "expires_in" Syntax
- A.15. "username" Syntax
- A.16. "password" Syntax
- A.17. "refresh_token" Syntax
- A.18. Endpoint Parameter Syntax
- Appendix B. Use of application/x-www-form-urlencoded Media Type
전통적인 클라이언트-서버 인증 모델에서 클라이언트는 리소스 소유자의 자격 증명을 사용하여 서버에서 인증함으로써 서버에서 액세스가 제한된 리소스 (보호 된 리소스)를 요청합니다. 제한된 리소스에 대한 타사 애플리케이션 액세스를 제공하기 위해 리소스 소유자는 해당 자격 증명을 타사와 공유합니다. 이로 인해 몇 가지 문제와 제한 사항이 발생합니다:
o 타사 응용 프로그램은 리소스 소유자의 자격 증명을 나중에 사용할 수 있도록 일반적으로 일반 텍스트의 암호를 저장하는 것이 필요하다.
o 암호에 내재 된 보안 취약점에도 불구하고 서버는 암호 인증을 지원해야합니다.
o 타사 응용 프로그램은 리소스 소유자의 보호 된 리소스에 지나치게 광범위하게 액세스 할 수 있으므로 리소스 소유자는 기간을 제한하거나 제한된 리소스 하위 집합에 대한 액세스 권한을 갖지 못합니다.
o 리소스 소유자는 모든 제 3 자에 대한 액세스를 취소하지 않고 개별 제 3 자에 대한 액세스를 취소 할 수 없으며 제 3 자의 비밀번호를 변경하여이를 취소해야합니다.
o 타사 응용 프로그램이 손상되면 최종 사용자의 암호와 해당 암호로 보호되는 모든 데이터가 손상됩니다.
OAuth는 권한 부여 계층을 도입하고 리소스 소유자의 역할과 클라이언트의 역할을 분리하여 이러한 문제를 해결합니다. OAuth에서 클라이언트는 리소스 소유자가 제어하고 리소스 서버에서 리소스에 대한 액세스를 요청하고 리소스 소유자와 다른 자격 증명 집합을 발급받습니다.
리소스 소유자의 자격 증명을 사용하여 보호 된 리소스에 액세스하는 대신 클라이언트는 특정 범위, 수명 및 기타 액세스 속성을 나타내는 문자열 인 액세스 토큰을 얻습니다. 액세스 토큰은 리소스 소유자의 승인을 받아 권한 부여 서버에서 타사 클라이언트에 발급됩니다. 클라이언트는 액세스 토큰을 사용하여 리소스 서버에서 호스팅하는 보호 된 리소스에 액세스합니다.
예를 들어, 최종 사용자 (자원 소유자)는 사용자 이름과 암호를 인쇄 서비스와 공유하지 않고 사진 공유 서비스 (자원 서버)에 저장된 보호 된 사진에 대한 인쇄 서비스 (클라이언트) 액세스 권한을 부여 할 수 있습니다. 대신 그녀는 인쇄 서비스 위임 특정 자격 증명 (액세스 토큰)을 발급하는 사진 공유 서비스 (인증 서버)에서 신뢰하는 서버로 직접 인증합니다.
이 사양은 HTTP ([RFC2616])와 함께 사용하도록 설계되었습니다. HTTP 이외의 프로토콜을 통한 OAuth 사용은 범위를 벗어납니다.
정보 문서로 게시 된 OAuth 1.0 프로토콜 ([RFC5849])은 소규모 임시 커뮤니티 노력의 결과였습니다. 이 표준 트랙 사양은 OAuth 1.0 배포 경험뿐만 아니라 광범위한 IETF 커뮤니티에서 수집 한 추가 사용 사례 및 확장 성 요구 사항을 기반으로합니다. OAuth 2.0 프로토콜은 OAuth 1.0과 역 호환되지 않습니다. 두 버전이 네트워크에 공존 할 수 있으며 구현시 둘 다 지원하도록 선택할 수 있습니다.그러나 새로운 구현은 이 문서에 지정된대로 OAuth 2.0을 지원하며 OAuth 1.0은 기존 배포를 지원하는 데만 사용됩니다. OAuth 2.0 프로토콜은 OAuth 1.0 프로토콜과 구현 세부 사항을 거의 공유하지 않습니다. OAuth 1.0에 익숙한 구현자는 구조와 세부 사항에 대한 추측없이 이 문서에 접근해야합니다.
OAuth는 네 가지 역할을 정의합니다.:
리소스(자원) 소유자
보호 된 리소스에 대한 액세스 권한을 부여 할 수있는 엔티티입니다. 리소스 소유자가 개인 인 경우이를 최종 사용자라고합니다.
리소스(자원) 서버
액세스 토큰을 사용하여 보호 된 리소스 요청을 수락하고 응답 할 수있는 보호 된 리소스를 호스팅하는 서버입니다..
클라이언트
리소스 소유자를 대신하여 권한을 부여하여 보호 된 리소스를 요청하는 애플리케이션입니다. "클라이언트"라는 용어는 특정 구현 특성 (예 : 응용 프로그램이 서버, 데스크톱 또는 기타 장치에서 실행되는지 여부)을 의미하지 않습니다.
권한 부여 서버
리소스 소유자를 성공적으로 인증하고 권한을 얻은 후 서버가 클라이언트에 액세스 토큰을 발급합니다.
권한 부여 서버와 리소스 서버 간의 상호 작용은 이 사양의 범위를 벗어납니다. 권한 서버는 자원 서버와 동일한 서버이거나 별도의 엔티티 일 수 있습니다. 단일 인증 서버는 여러 리소스 서버에서 허용하는 액세스 토큰을 발급 할 수 있습니다.
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
그림 1에 설명 된 OAuth 2.0 흐름은 네 가지 역할 간의 상호 작용을 설명하며 다음 단계를 포함합니다.:
(A) 클라이언트는 리소스 소유자에게 권한 부여를 요청합니다. 권한 부여 요청은 리소스 소유자 (표시된대로)에게 직접 만들어 지거나 중개자로서 권한 부여 서버를 통해 간접적으로 할 수 있습니다.
(B) 클라이언트는이 사양에 정의 된 네 가지 권한 부여 유형 중 하나를 사용하거나 확장 권한 부여 유형을 사용하여 표현 된 리소스 소유자의 권한을 나타내는 자격 증명인 권한 부여를받습니다. 권한 부여 유형은 클라이언트가 권한을 요청하는 데 사용하는 방법과 권한 부여 서버에서 지원하는 유형에 따라 다릅니다.
(C) 클라이언트는 권한 부여 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청합니다.
(D) 권한 부여 서버는 클라이언트를 인증하고 권한 부여를 확인하고 유효한 경우 액세스 토큰을 발급합니다.
(E) 클라이언트는 리소스 서버에서 보호 된 리소스를 요청하고 액세스 토큰을 제공하여 인증합니다.
(F) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 요청을 처리합니다.
클라이언트가 리소스 소유자 (단계 (A) 및 (B)에 설명 됨)로부터 권한 부여를 얻기 위해 선호되는 방법은 권한 부여 서버를 중개자로 사용하는 것입니다. 이는 Section 4.1의 그림 3에 설명되어 있습니다.
권한 부여는 클라이언트가 액세스 토큰을 얻기 위해 사용하는 리소스 소유자의 권한 (보호 된 리소스에 액세스하기위한)을 나타내는 자격 증명입니다. 이 사양은 권한 부여 코드, 암시, 리소스 소유자 암호 자격 증명 및 클라이언트 자격 증명의 네 가지 권한 부여 유형과 추가 유형을 정의하기위한 확장 성 메커니즘을 정의합니다.
권한 부여 코드는 클라이언트와 리소스 소유자 사이의 중개자로 권한 서버를 사용하여 얻습니다. 리소스 소유자에게 직접 권한을 요청하는 대신 클라이언트는 리소스 소유자를 권한 부여 서버 ([RFC2616]에 정의 된대로 사용자 에이전트를 통해)로 보내고, 다시 권한 부여 코드를 사용하여 리소스 소유자를 클라이언트로 다시 보냅니다.
권한 코드를 사용하여 리소스 소유자를 클라이언트로 다시 보내기 전에 권한 서버는 리소스 소유자를 인증하고 권한을 얻습니다. 리소스 소유자는 권한 부여 서버에서만 인증하기 때문에 리소스 소유자의 자격 증명은 클라이언트와 공유되지 않습니다.
권한 부여 코드는 클라이언트를 인증하는 기능과 같은 몇 가지 중요한 보안 이점을 제공 할뿐만 아니라 액세스 토큰을 리소스 소유자의 사용자 에이전트를 통해 전달하지 않고 클라이언트로 직접 전송하여 리소스 소유자를 포함하여 다른 이에게 노출시킬 수 있습니다.
암시적 권한 부여는 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현 된 클라이언트에 최적화 된 단순화 된 인증 코드 흐름입니다. 암시 적 흐름에서 클라이언트에게 권한 부여 코드를 발급하는 대신 클라이언트에 직접 액세스 토큰이 발급됩니다 (리소스 소유자 권한 부여의 결과로). 권한 부여 코드와 같은 중간 자격 증명이 발급되지 않고 나중에 액세스 토큰을 얻는 데 사용되기 때문에 부여 유형은 암시 적입니다.
암시적 허용 흐름 중에 액세스 토큰을 발행 할 때 권한 부여 서버는 클라이언트를 인증하지 않습니다. 경우에 따라 클라이언트에 액세스 토큰을 전달하는 데 사용되는 리디렉션 URI를 통해 클라이언트 정체를 확인할 수 있습니다. 액세스 토큰은 리소스 소유자 또는 리소스 소유자의 사용자 에이전트에 대한 액세스 권한이있는 다른 애플리케이션에 노출 될 수 있습니다.
암시적 권한 부여는 액세스 토큰을 얻는 데 필요한 왕복 횟수를 줄이므로 일부 클라이언트 (예 : 브라우저 내 애플리케이션으로 구현 된 클라이언트)의 응답 성과 효율성을 향상시킵니다. 그러나 이러한 편의는 특히 권한 부여 코드 부여 유형을 사용할 수있는 경우 Section 10.3 및 Section 10.16에 설명 된 것과 같은 암시적 부여 사용의 보안에 대해 생각해보아야 합니다.
리소스 소유자 암호 자격 증명 (즉, 사용자 이름 및 암호)은 액세스 토큰을 얻기위한 권한 부여로 직접 사용할 수 있습니다. 자격 증명은 리소스 소유자와 클라이언트간에 높은 수준의 신뢰가있을 때 (예 : 클라이언트가 장치 운영 체제 또는 높은 권한을 가진 응용 프로그램의 일부 임) 및 기타 권한 부여 유형을 사용할 수없는 경우에만 사용해야합니다 ( 권한 부여 코드 등).
이 권한 부여 유형에는 리소스 소유자 자격 증명에 대한 직접적인 클라이언트 액세스가 필요하지만 리소스 소유자 자격 증명은 단일 요청에 사용되며 액세스 토큰으로 교환됩니다. 이 권한 부여 유형은 자격 증명을 수명이 긴 액세스 토큰 또는 새로 고침 토큰으로 교환하여 클라이언트가 나중에 사용할 수 있도록 리소스 소유자 자격 증명을 저장할 필요를 제거 할 수 있습니다.
클라이언트 자격 증명 (또는 다른 형태의 클라이언트 인증)은 권한 부여 범위가 클라이언트의 제어하에있는 보호 된 리소스 또는 이전에 권한 부여 서버와 함께 준비된 보호된 리소스로 제한되는 경우 권한 부여로 사용될 수 있습니다. 클라이언트 자격 증명은 일반적으로 클라이언트가 자체적으로 작업하거나 (클라이언트가 리소스 소유자이기도 함) 이전에 권한 부여 서버에 준비된 권한을 기반으로 보호 된 리소스에 대한 액세스를 요청할 때 권한 부여로 사용됩니다.
액세스 토큰은 보호 된 리소스에 액세스하는 데 사용되는 자격 증명입니다. 액세스 토큰은 클라이언트에 발급 된 권한을 나타내는 문자열입니다. 문자열은 일반적으로 클라이언트에게 불명료한 값 입니다. 토큰은 리소스 소유자가 부여하고 리소스 서버 및 권한 부여 서버에 의해 시행되는 특정 범위 및 액세스 기간을 나타냅니다.
토큰은 인증 정보를 검색하는 데 사용되는 식별자를 나타내거나 검증 가능한 방식으로 인증 정보를 자체 포함 할 수 있습니다 (즉, 일부 데이터와 서명으로 구성된 토큰 문자열). 클라이언트가 토큰을 사용하려면이 사양의 범위를 벗어나는 추가 인증 자격 증명이 필요할 수 있습니다.
액세스 토큰은 추상화 계층을 제공하여 서로 다른 인증 구성 (예 : 사용자 이름 및 암호)을 리소스 서버가 이해하는 단일 토큰으로 대체합니다. 이 추상화를 통해 액세스 토큰을 얻는 데 사용되는 권한 부여보다 더 제한적인 액세스 토큰을 발급 할 수있을뿐만 아니라 광범위한 인증 방법을 이해해야하는 리소스 서버의 필요성을 제거 할 수 있습니다..
액세스 토큰은 리소스 서버 보안 요구 사항에 따라 다양한 형식, 구조 및 활용 방법 (예 : 암호화 속성)을 가질 수 있습니다. 보호 된 리소스에 액세스하는 데 사용되는 액세스 토큰 속성 및 방법은이 사양의 범위를 벗어나며 [RFC6750]과 같은 동반 사양에 의해 정의됩니다.
새로 고침 토큰은 액세스 토큰을 얻는 데 사용되는 자격 증명입니다. 새로 고침 토큰은 권한 부여 서버에 의해 클라이언트에 발급되며 현재 액세스 토큰이 유효하지 않거나 만료 될 때 새 액세스 토큰을 얻거나 범위가 동일하거나 더 좁은 추가 액세스 토큰을 얻는 데 사용됩니다 (액세스 토큰의 수명이 짧을 수 있으며 리소스 소유자가 승인 한 것보다 적은 권한). 새로 고침 토큰 발급은 권한 부여 서버의 재량에 따라 선택 사항입니다. 인증 서버가 새로 고침 토큰을 발행하면 액세스 토큰을 발행 할 때 포함됩니다 (예 : 그림 1의 단계 (D)).
새로 고침 토큰은 리소스 소유자가 클라이언트에 부여한 권한을 나타내는 문자열입니다. 문자열은 일반적으로 클라이언트에게 불명료한 값입니다. 토큰은 인증 정보를 검색하는 데 사용되는 식별자를 나타냅니다. 액세스 토큰과 달리 새로 고침 토큰은 권한 부여 서버에서만 사용하기위한 것이며 리소스 서버로 전송되지 않습니다.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token
그림 2에 표시된 흐름에는 다음 단계가 포함됩니다.:
(A) 클라이언트는 권한 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청합니다.
(B) 권한 부여 서버는 클라이언트를 인증하고 권한 부여의 유효성을 검사하고 유효한 경우 액세스 토큰과 새로 고침 토큰을 발급합니다.
(C) 클라이언트는 액세스 토큰을 제공하여 보호된 리소스를 리소스 서버에 요청합니다.
(D) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 요청을 처리합니다.
(E) 액세스 토큰이 만료 될 때까지 (C) 및 (D) 단계를 반복합니다. 클라이언트가 액세스 토큰이 만료되었음을 알고 있으면 단계 (G)로 건너 뜁니다. 그렇지 않으면 다른 보호 된 리소스 요청을합니다.
(F) 액세스 토큰이 유효하지 않기 때문에 리소스 서버가 유효하지 않은 토큰 오류를 반환합니다.
(G) 클라이언트는 권한 부여 서버로 인증하고 새로 고침 토큰을 제공하여 새 액세스 토큰을 요청합니다. 클라이언트 인증 요구 사항은 클라이언트 유형 및 권한 서버 정책을 기반으로합니다.
(H) 권한 부여 서버는 클라이언트를 인증하고 새로 고침 토큰의 유효성을 검사하고 유효한 경우 새 액세스 토큰 (및 선택적으로 새 새로 고침 토큰)을 발급합니다.
단계 (C), (D), (E) 및 (F)는 Section 7에 설명 된대로이 사양의 범위를 벗어납니다.
이 사양에서 TLS (전송 계층 보안)를 사용할 때마다 TLS의 적절한 버전 (또는 버전)은 광범위한 배포 및 알려진 보안 취약성에 따라 시간이 지남에 따라 달라집니다. 이 글을 쓰는 시점에서 TLS 버전 1.2 [RFC5246]가 가장 최신 버전이지만 배포 기반이 매우 제한적이며 구현에 쉽게 사용할 수 없습니다. TLS 버전 1.0 [RFC2246]은 가장 널리 배포 된 버전이며 가장 광범위한 상호 운용성을 제공합니다.
구현시 보안 요구 사항을 충족하는 추가 전송 계층 보안 메커니즘을 지원할 수도 있습니다.(MAY)
이 사양은 클라이언트 또는 권한 부여 서버가 리소스 소유자의 사용자 에이전트를 다른 대상으로 보내는 HTTP 리디렉션을 광범위하게 사용합니다. 이 사양의 예제는 HTTP 302 상태 코드의 사용을 보여 주지만,이 리디렉션을 수행하기 위해 사용자 에이전트를 통해 사용할 수있는 다른 모든 방법이 허용되며 구현 세부 사항으로 간주됩니다.
OAuth 2.0은 잘 정의 된 보안 속성과 함께 풍부한 권한 부여 프레임 워크를 제공합니다. 그러나 많은 선택적 구성 요소가있는 풍부하고 확장 성이 뛰어난 프레임 워크로서 이 사양은 상호 운용이 불가능한 광범위한 구현을 생성 할 가능성이 높습니다.
또한이 사양은 일부 필수 구성 요소를 부분적으로 또는 완전히 정의하지 않은 상태로 둡니다 (예 : 클라이언트 등록, 권한 부여 서버 기능, 엔드 포인트 검색). 이러한 구성 요소가없는 경우 클라이언트는 상호 운용하기 위해 특정 권한 서버 및 자원 서버에 대해 수동으로 그리고 구체적으로 구성되어야합니다.
이 프레임 워크는 향후 작업이 완전한 웹 규모 상호 운용성을 달성하는 데 필요한 규범 적 프로필 및 확장을 정의 할 것이라는 명확한 기대를 바탕으로 설계되었습니다.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the rule URI-reference is included from "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986].
Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify".
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
프로토콜을 시작하기 전에 클라이언트는 인증 서버에 등록합니다. 클라이언트가 인증 서버에 등록하는 수단은 이 사양의 범위를 벗어나지 만 일반적으로 최종 사용자와 HTML 등록 양식과의 상호 작용을 포함합니다.
클라이언트 등록에는 클라이언트와 권한 부여 서버 간의 직접적인 상호 작용이 필요하지 않습니다. 권한 부여 서버에서 지원하는 경우 등록은 클라이언트와 신뢰를 설정하고 필요한 클라이언트 속성 (예 : 리디렉션 URI, 클라이언트 유형)을 얻기위한 다른 수단에 의존 할 수 있습니다. 예를 들어, 등록은 자체 발행 또는 제 3 자 발행을 사용하거나 신뢰할 수있는 채널을 사용하여 클라이언트 발견을 수행하는 권한 부여 서버에 의해 수행 될 수 있습니다. 클라이언트를 등록 할 때 클라이언트 개발자는 다음을 해야한다.(SHALL):
o Section 2.1에 설명 된대로 클라이언트 유형을 지정합니다.
o Section 3.1.2에 설명 된대로 클라이언트 리디렉션 URI를 제공합니다.
o 권한 부여 서버에 필요한 기타 정보 (예 : 애플리케이션 이름, 웹 사이트, 설명, 로고 이미지, 법적 조건 수락)를 포함합니다.
OAuth는 권한 부여 서버로 안전하게 인증하는 능력 (즉, 클라이언트 자격 증명의 기밀성을 유지하는 능력)에 따라 두 가지 클라이언트 유형을 정의합니다.:
confidential(기밀)
자격 증명의 기밀성을 유지할 수있는 클라이언트 (예 : 클라이언트 자격 증명에 대한 액세스가 제한된 보안 서버에 구현 된 클라이언트) 또는 다른 수단을 사용하여 클라이언트 인증을 보호 할 수 있습니다.
public(공용)
자격 증명의 기밀성을 유지할 수없는 클라이언트 (예 : 설치된 기본 응용 프로그램 또는 웹 브라우저 기반 응용 프로그램과 같이 리소스 소유자가 사용하는 장치에서 실행되는 클라이언트), 다른 수단을 통한 보안 클라이언트 인증이 불가능합니다.
클라이언트 유형 지정은 권한 부여 서버의 보안 인증 정의와 클라이언트 자격 증명의 허용 가능한 노출 수준을 기반으로합니다. 권한 부여 서버는 클라이언트 유형에 대해 가정하지 않아야합니다.(SHOULD NOT)
클라이언트는 서로 다른 클라이언트 유형 및 보안 컨텍스트 (예 : 기밀 서버 기반 구성 요소와 공용 브라우저 기반 구성 요소를 모두 포함하는 분산 클라이언트)를 가진 분산 된 구성 요소 집합으로 구현 될 수 있습니다. 인증 서버가 이러한 클라이언트에 대한 지원을 제공하지 않거나 등록에 대한 지침을 제공하지 않는 경우 클라이언트는 각 구성 요소를 별도의 클라이언트로 등록해야합니다.(SHOULD)
이 사양은 다음 클라이언트 프로필을 중심으로 설계되었습니다.:
웹 애플리케이션
웹 애플리케이션은 웹 서버에서 실행되는 기밀 클라이언트입니다. 리소스 소유자는 리소스 소유자가 사용하는 장치의 사용자 에이전트에서 렌더링 된 HTML 사용자 인터페이스를 통해 클라이언트에 액세스합니다. 클라이언트 자격 증명 및 클라이언트에 발급 된 모든 액세스 토큰은 웹 서버에 저장되며 리소스 소유자에게 노출되거나 액세스 할 수 없습니다.
사용자 에이전트 기반 애플리케이션
사용자 에이전트 기반 애플리케이션은 클라이언트 코드가 웹 서버에서 다운로드되고 리소스 소유자가 사용하는 장치의 사용자 에이전트 (예 : 웹 브라우저) 내에서 실행되는 공용 클라이언트입니다. 프로토콜 데이터 및 자격 증명은 리소스 소유자가 쉽게 액세스 할 수 있으며 종종 볼 수 있습니다. 이러한 애플리케이션은 사용자 에이전트 내에 상주하므로 권한 부여를 요청할 때 사용자 에이전트 기능을 원활하게 사용할 수 있습니다.
기본 응용 프로그램
기본 애플리케이션은 리소스 소유자가 사용하는 장치에 설치 및 실행되는 공용 클라이언트입니다. 리소스 소유자는 프로토콜 데이터 및 자격 증명에 액세스 할 수 있습니다. 응용 프로그램에 포함 된 모든 클라이언트 인증 자격 증명을 추출 할 수 있다고 가정합니다. 반면에 액세스 토큰 또는 새로 고침 토큰과 같이 동적으로 발급 된 자격 증명은 허용 가능한 수준의 보호를받을 수 있습니다. 최소한 이러한 자격 증명은 애플리케이션이 상호 작용할 수있는 적대적인 서버로부터 보호됩니다. 일부 플랫폼에서는 이러한 자격 증명이 동일한 장치에있는 다른 응용 프로그램으로부터 보호 될 수 있습니다.
권한 부여 서버는 등록 된 클라이언트에게 클라이언트 식별자 (클라이언트가 제공 한 등록 정보를 나타내는 고유 한 문자열)를 발급합니다. 클라이언트 식별자는 비밀이 아닙니다. 리소스 소유자에게 노출되며 클라이언트 인증을 위해 단독으로 사용해서는 안됩니다(MUST NOT). 클라이언트 식별자는 권한 부여 서버에 고유합니다.
클라이언트 식별자 문자열 크기는이 사양에 정의되지 않은 상태로 남아 있습니다. 클라이언트는 식별자 크기에 대한 가정을 피해야합니다. 권한 부여 서버는 발행하는 식별자의 크기를 문서화해야합니다(SHOULD).
클라이언트 유형이 기밀 인 경우 클라이언트와 권한 서버는 권한 부여 서버의 보안 요구 사항에 적합한 클라이언트 인증 방법을 설정합니다. 권한 부여 서버는 보안 요구 사항을 충족하는 모든 형태의 클라이언트 인증을 수락 할 수 있습니다(MAY).
기밀 클라이언트는 일반적으로 권한 부여 서버 (예 : 암호, 공개 / 개인 키 쌍)로 인증하는 데 사용되는 클라이언트 자격 증명 집합을 발급 (또는 설정)합니다.
권한 부여 서버는 공용 클라이언트와 클라이언트 인증 방법을 설정할 수 있습니다(MAY). 그러나 권한 부여 서버는 클라이언트 식별 목적으로 공용 클라이언트 인증에 의존해서는 안됩니다(MUST NOT).
클라이언트는 각 요청에서 둘 이상의 인증 방법을 사용해서는 안됩니다(MUST NOT).
클라이언트 암호를 소유 한 클라이언트는 [RFC2617]에 정의 된 HTTP 기본 인증 체계를 사용하여 권한 부여 서버로 인증 할 수 있습니다. 클라이언트 식별자는 Appendix B에 따라 "application / x-www-form-urlencoded"인코딩 알고리즘을 사용하여 인코딩되며 인코딩 된 값이 사용자 이름으로 사용됩니다. 클라이언트 암호는 동일한 알고리즘을 사용하여 인코딩되고 암호로 사용됩니다. 권한 부여 서버는 클라이언트 암호를 발급 한 클라이언트를 인증하기 위해 HTTP 기본 인증 체계를 지원해야합니다.
예를 들어 (표시 목적으로 만 추가 줄 바꿈 포함):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
또는 권한 부여 서버는 다음 매개 변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함하는 것을 지원할 수 있습니다.:
client_id
REQUIRED. Section 2.2에 설명 된 등록 프로세스 중에 클라이언트에게 발급 된 클라이언트 식별자.
client_secret
REQUIRED. 클라이언트 시크릿. 클라이언트 시크릿이 빈 문자열 인 경우 클라이언트는 매개 변수를 생략 할 수 있습니다.
두 매개 변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함하는 것은 권장되지 않으며 HTTP 기본 인증 체계 (또는 기타 암호 기반 HTTP 인증 체계)를 직접 사용할 수없는 클라이언트로 제한되어야합니다. 매개 변수는 요청 본문에서만 전송 될 수 있으며 요청 URI에 포함되지 않아야합니다.
예를 들어 본문 매개 변수를 사용하여 액세스 토큰 (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
권한 부여 서버는 암호 인증을 사용하여 요청을 보낼 때 Section 1.6에 설명 된대로 TLS를 사용해야합니다.
이 클라이언트 인증 방법에는 암호가 포함되므로 권한 부여 서버는 무차별 대입 공격으로부터 암호를 사용하는 모든 엔드 포인트를 보호해야합니다.
권한 부여 서버는 보안 요구 사항과 일치하는 적절한 HTTP 인증 체계를 지원할 수 있습니다. 다른 인증 방법을 사용할 때 권한 부여 서버는 클라이언트 식별자 (등록 레코드)와 인증 체계 간의 매핑을 정의해야합니다.
이 사양은 등록되지 않은 클라이언트의 사용을 제외하지 않습니다. 그러나 이러한 클라이언트의 사용은이 사양의 범위를 벗어나며 추가 보안 분석 및 상호 운용성 영향 검토가 필요합니다.
권한 부여 프로세스는 두 개의 권한 부여 서버 endpoints (HTTP 리소스)을 사용합니다.:
o 권한 부여 endpoint - 사용자 에이전트 리디렉션을 통해 리소스 소유자로부터 권한을 얻기 위해 클라이언트가 사용합니다.
o 토큰 endpoint - 클라이언트가 일반적으로 클라이언트 인증을 사용하여 액세스 토큰에 대한 권한 부여를 교환하는 데 사용됩니다.
o 리디렉션 endpoint - 권한 부여 서버가 리소스 소유자 사용자 에이전트를 통해 권한 자격 증명이 포함 된 응답을 클라이언트에 반환하는 데 사용됩니다.
모든 권한 부여 유형이 두 Endpoint을 모두 사용하는 것은 아닙니다. 확장 부여 유형은 필요에 따라 추가 엔드 포인트를 정의 할 수 있습니다.
권한 부여 endpoint은 리소스 소유자와 상호 작용하고 권한 부여를 얻는 데 사용됩니다. 권한 부여 서버는 먼저 자원 소유자의 신원을 확인해야합니다. 권한 부여 서버가 리소스 소유자를 인증하는 방식 (예 : 사용자 이름 및 비밀번호 로그인, 세션 쿠키)은이 사양의 범위를 벗어납니다.
클라이언트가 권한 부여 endpoint의 위치를 얻는 수단은이 사양의 범위를 벗어나지 만 위치는 일반적으로 서비스 설명서에 제공됩니다.
endpoint URI는 추가 쿼리 매개 변수를 추가 할 때 유지되어야하는 (부록 B에 따라) 쿼리 구성 요소 ([RFC3986] Section 3.4) 형식의 "application / x-www-form-urlencoded"를 포함 할 수 있습니다. endpoint URI는 fragment 요소를 포함하지 않아야합니다.
권한 부여 endpoint에 대한 요청은 사용자 인증과 일반 텍스트 자격 증명 (HTTP 응답에서) 전송을 가져 오므로 권한 부여 서버는 권한 부여 endpoint에 요청을 보낼 때 Section 1.6에 설명 된대로 TLS를 사용해야합니다.
권한 부여 서버는 인증 endpoint에 대해 HTTP "GET"메소드 [RFC2616]의 사용을 지원해야하며 "POST"메소드의 사용도 지원할 수 있습니다.
값없이 전송 된 매개 변수는 요청에서 생략 된 것처럼 처리되어야합니다. 권한 부여 서버는 인식되지 않는 요청 매개 변수를 무시해야합니다. 요청 및 응답 매개 변수는 두 번 이상 포함되지 않아야합니다.
권한 부여 endpoint은 권한 부여 코드 부여 유형 및 암시 적 부여 유형 흐름에서 사용됩니다. 클라이언트는 다음 매개 변수를 사용하여 원하는 권한 부여 유형을 권한 부여 서버에 알립니다.:
response_type
REQUIRED. 값은 Section 4.1.1에 설명 된대로 권한 부여 코드를 요청하기위한 "code", Section 4.2.1에 설명 된 액세스 토큰 (암시적 허용)을 요청하기위한 "token"또는 Section 8.4에 설명 된 등록 된 확장 값 중 하나 여야합니다.
확장 응답 유형은 값의 순서가 중요하지 않은 공백으로 구분 된 (%x20) 값 목록을 포함 할 수 있습니다 (예 : 응답 유형 "a b"는 "b a"와 동일 함). 이러한 복합 응답 유형의 의미는 해당 사양에 의해 정의됩니다.
인증 요청에 "response_type"매개 변수가 없거나 응답 유형이 이해되지 않는 경우 권한 부여 서버는 Section 4.1.2.1에 설명 된대로 오류 응답을 반환해야합니다.
자원 소유자와의 상호 작용을 완료 한 후 권한 부여 서버는 자원 소유자의 사용자 에이전트를 다시 클라이언트로 보냅니다. 권한 부여 서버는 클라이언트 등록 프로세스 중 또는 권한 부여 요청을 할 때 이전에 권한 부여 서버에 설정된 클라이언트의 리디렉션 endpoint으로 사용자 에이전트를 리디렉션합니다.
리디렉션 endpoint URI는 [RFC3986] Section 4.3에 정의 된대로 절대 URI 여야합니다. endpoint URI는 추가 쿼리 매개 변수를 추가 할 때 유지되어야하는 (Appendix B에 따라) 쿼리 구성 요소 ([RFC3986] Section 3.4) 형식의 "application/x-www-form-urlencoded"를 포함 할 수 있습니다. Endpoint URI는 fragment 요소를 포함하지 않아야합니다.
리디렉션 endpoint는 요청 된 응답 유형이 "code"또는 "token"이거나 리디렉션 요청이 개방형 네트워크를 통해 민감한 자격 증명을 전송하게 될 때 Section 1.6에 설명 된대로 TLS를 사용해야합니다 (SHOULD). 이 문서를 작성할 당시 클라이언트에게 TLS를 배포하도록 요구하는 것은 많은 클라이언트 개발자에게 중요한 장애물이기 때문에이 사양은 TLS 사용을 의무화하지 않습니다. TLS를 사용할 수없는 경우 권한 부여 서버는 리디렉션 전에 안전하지 않은 endpoint에 대해 리소스 소유자에게 경고해야합니다 (예 : 권한 부여 요청 중에 메시지 표시).
전송 계층 보안이 부족하면 클라이언트 및 액세스 권한이있는 보호 된 리소스의 보안에 심각한 영향을 미칠 수 있습니다. 전송 계층 보안의 사용은 권한 부여 프로세스가 클라이언트에 의해 위임 된 최종 사용자 인증의 한 형태로 사용될 때 특히 중요합니다 (예 : 타사 로그인 서비스).
권한 부여 서버는 리디렉션 endpoint을 등록하기 위해 다음 클라이언트를 요구해야합니다.:
o 공용 클라이언트.
o 암시적 부여 유형을 사용하는 기밀 클라이언트.
권한 부여 서버는 모든 클라이언트가 권한 부여 endpoint을 사용하기 전에 리디렉션 endpoint을 등록하도록 요구해야합니다(SHOULD).
권한 부여 서버는 클라이언트가 완전한 리디렉션 URI를 제공하도록 요구해야합니다 (클라이언트는 요청 별 사용자 정의를 달성하기 위해 "state"요청 매개 변수를 사용할 수 있습니다). 완전한 리디렉션 URI의 등록을 요구할 수없는 경우 권한 부여 서버는 URI scheme, 권한 및 경로의 등록을 요구해야합니다 (권한을 요청할 때 클라이언트가 리디렉션 URI의 쿼리 구성 요소 만 동적으로 변경할 수 있도록 허용).
권한 부여 서버는 클라이언트가 여러 리디렉션 Endpoint을 등록하도록 허용 할 수 있습니다.
리디렉션 URI 등록 요구 사항이 없으면 공격자가 Section 10.15에 설명 된대로 권한 부여 endpoint을 개방형 리디렉터로 사용할 수 있습니다.
여러 리디렉션 URI가 등록 된 경우, 리디렉션 URI의 일부만 등록되었거나 리디렉션 URI가 등록되지 않은 경우 클라이언트는 "redirect_uri"요청 매개 변수를 사용하는 인증 요청과 함께 리디렉션 URI를 포함해야합니다.
리디렉션 URI가 권한 요청에 포함 된 경우 권한 부여 서버는 리디렉션 URI가 등록 된 경우 [RFC3986] Section 6에 정의 된 등록 된 리디렉션 URI (또는 URI 구성 요소) 중 하나 이상과 수신 된 값을 비교하고 일치시켜야합니다. . 클라이언트 등록에 전체 리디렉션 URI가 포함 된 경우 인증 서버는 [RFC3986] Section 6.2.1.에 정의 된 간단한 문자열 비교를 사용하여 두 URI를 비교해야합니다.
권한 부여 요청이 누락되거나 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 유효성 검사에 실패하면 권한 부여 서버는 리소스 소유자에게 오류를 알려야하며 사용자 에이전트를 잘못된 리디렉션 URI로 자동 리디렉션해서는 안됩니다.
클라이언트의 Endpoint에 대한 리디렉션 요청은 일반적으로 사용자 에이전트가 처리하는 HTML 문서 응답을 생성합니다. HTML 응답이 리디렉션 요청의 결과로 직접 제공되는 경우 HTML 문서에 포함 된 모든 스크립트는 리디렉션 URI 및 포함 된 자격 증명에 대한 전체 액세스 권한으로 실행됩니다.
클라이언트는 리디렉션 엔드 포인트 응답에 타사 스크립트 (예 : 타사 분석, 소셜 플러그인, 광고 네트워크)를 포함하면 안됩니다. 대신 URI에서 자격 증명을 추출하고 자격 증명을 노출하지 않고 (URI 또는 다른 곳에서) 사용자 에이전트를 다시 다른 Endpoint으로 리디렉션해야합니다 (SHOULD). 타사 스크립트가 포함 된 경우 클라이언트는 자신의 스크립트 (URI에서 자격 증명을 추출 및 제거하는 데 사용됨)가 먼저 실행되는지 확인해야합니다.
토큰 endpoint은 클라이언트가 권한 부여 또는 새로 고침 토큰을 제공하여 액세스 토큰을 얻는 데 사용됩니다. 토큰 endpoint은 암시 적 권한 부여 유형을 제외한 모든 권한 부여와 함께 사용됩니다 (액세스 토큰이 직접 발급되기 때문에).
클라이언트가 토큰 endpoint의 위치를 얻는 방법은이 사양의 범위를 벗어나지 만 일반적으로 위치는 서비스 설명서에 제공됩니다.
Endpoint URI는 추가 쿼리 매개 변수를 추가 할 때 유지되어야하는 (Appendix B에 따라) 쿼리 구성 요소 ([RFC3986] Section 3.4) 형식의 "application/x-www-form-urlencoded"를 포함 할 수 있습니다. Endpoint URI는 fragment 구성 요소를 포함하지 않아야합니다.
토큰 Endpoint에 대한 요청은 일반 텍스트 자격 증명 (HTTP 요청 및 응답)을 전송하므로 권한 부여 서버는 요청을 토큰 Endpoint에 보낼 때 Section 1.6에 설명 된대로 TLS를 사용해야합니다.
클라이언트는 액세스 토큰 요청을 할 때 반드시 HTTP "POST"메소드를 사용해야합니다.
값없이 전송 된 매개 변수는 요청에서 생략 된 것처럼 처리되어야합니다. 권한 부여 서버는 인식되지 않는 요청 매개 변수를 무시해야합니다. 요청 및 응답 매개 변수는 두 번 이상 포함되지 않아야합니다.
기밀 클라이언트 또는 기타 클라이언트가 발급 한 클라이언트 자격 증명은 토큰 엔드 포인트에 요청할 때 Section 2.3 절에 설명 된대로 인증 서버로 인증해야합니다. 클라이언트 인증은 다음에 사용됩니다.:
o 발급 된 클라이언트에 대한 새로 고침 토큰 및 권한 부여 코드의 바인딩을 적용합니다. 클라이언트 인증은 인증 코드가 안전하지 않은 채널을 통해 리디렉션 Endpoint로 전송되거나 리디렉션 URI가 완전히 등록되지 않은 경우에 중요합니다.
o 클라이언트를 비활성화하거나 자격 증명을 변경하여 손상된 클라이언트에서 복구하여 공격자가 훔친 새로 고침 토큰을 남용하지 못하도록합니다. 단일 클라이언트 자격 증명 집합을 변경하는 것이 전체 새로 고침 토큰 집합을 취소하는 것보다 훨씬 빠릅니다.
o 정기적 인 자격 증명 교체가 필요한 인증 관리 모범 사례를 구현합니다. 전체 새로 고침 토큰 집합을 교체하는 것은 어려울 수 있지만 단일 클라이언트 자격 증명 집합을 교체하는 것은 훨씬 쉽습니다.
클라이언트는 "client_id"요청 매개 변수를 사용하여 토큰 Endpoint에 요청을 보낼 때 자신을 식별 할 수 있습니다. 토큰 엔드 포인트에 대한 "authorization_code" "grant_type"요청에서 인증되지 않은 클라이언트는 "client_id"가 다른 "client_id"를 가진 클라이언트 용으로 의도 된 코드를 실수로 수락하는 것을 방지하기 위해 반드시 "client_id"를 전송해야합니다. 이것은 인증 코드의 대체로부터 클라이언트를 보호합니다. (보호 된 자원에 대한 추가 보안을 제공하지 않습니다.)
권한 부여 및 토큰 Endpoint를 통해 클라이언트는 "scope"요청 매개 변수를 사용하여 액세스 요청의 범위를 지정할 수 있습니다. 권한 부여 서버는 "scope"응답 매개 변수를 사용하여 발급 된 액세스 토큰의 범위를 클라이언트에 알립니다.
범위 매개 변수의 값은 공백으로 구분되고 대소 문자를 구분하는 문자열 목록으로 표현됩니다. 문자열은 권한 부여 서버에 의해 정의됩니다. 값에 공백으로 구분 된 여러 문자열이 포함 된 경우 순서는 중요하지 않으며 각 문자열은 요청 된 범위에 추가 액세스 범위를 추가합니다.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
권한 서버는 권한 서버 정책 또는 리소스 소유자의 지시에 따라 클라이언트가 요청한 범위를 전체 또는 부분적으로 무시할 수 있습니다. 발급 된 액세스 토큰 범위가 클라이언트가 요청한 범위와 다른 경우 권한 부여 서버는 "scope"응답 매개 변수를 포함하여 클라이언트에게 부여 된 실제 범위를 알려야합니다.
클라이언트가 권한을 요청할 때 범위 매개 변수를 생략하면 권한 서버는 미리 정의 된 기본값을 사용하여 요청을 처리하거나 유효하지 않은 범위를 나타내는 요청을 실패해야합니다. 권한 부여 서버는 범위 요구 사항과 기본값 (정의 된 경우)을 문서화해야합니다 (SHOULD).
액세스 토큰을 요청하기 위해 클라이언트는 리소스 소유자로부터 권한을 얻습니다. 권한 부여는 클라이언트가 액세스 토큰을 요청하는 데 사용하는 권한 부여의 형태로 표현됩니다. OAuth는 인증 코드, 암시 적, 리소스 소유자 암호 자격 증명 및 클라이언트 자격 증명의 네 가지 부여 유형을 정의합니다. 또한 추가 부여 유형을 정의하기위한 확장 메커니즘을 제공합니다.
권한 부여 코드 유형은 액세스 토큰과 새로 고침 토큰을 모두 얻는 데 사용되며 기밀 클라이언트에 최적화되어 있습니다. 이것은 리디렉션 기반 흐름이므로 클라이언트는 리소스 소유자의 사용자 에이전트 (일반적으로 웹 브라우저)와 상호 작용할 수 있어야하며 권한 부여 서버에서 들어오는 요청 (리디렉션을 통해)을받을 수 있어야합니다.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
그림 3에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 클라이언트는 리소스 소유자의 사용자 에이전트를 권한 부여 Endpoint으로 보내 흐름을 시작합니다. 클라이언트에는 클라이언트 식별자, 요청 된 범위, 로컬 상태 및 액세스 권한이 부여 (또는 거부)되면 권한 부여 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI가 포함됩니다.
(B) 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고 리소스 소유자가 클라이언트의 액세스 요청을 허용 또는 거부할지 여부를 설정합니다.
(C) 리소스 소유자가 액세스 권한을 부여한다고 가정하면 권한 부여 서버는 이전에 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 다시 클라이언트로 리디렉션합니다 (요청시 또는 클라이언트 등록 중에). 리디렉션 URI에는 인증 코드와 이전에 클라이언트가 제공하는 모든 로컬 상태가 포함됩니다.
(D) 클라이언트는 이전 단계에서받은 인증 코드를 포함하여 인증 서버의 토큰 Endpoint에서 액세스 토큰을 요청합니다. 요청을 할 때 클라이언트는 권한 부여 서버로 인증합니다. 클라이언트에는 확인을 위한 인증 코드를 얻는 데 사용되는 리디렉션 URI가 포함됩니다.
(E) 인증 서버는 클라이언트를 인증하고 인증 코드의 유효성을 검사하며 수신 된 리디렉션 URI가 단계 (C)에서 클라이언트를 리디렉션하는 데 사용 된 URI와 일치하는지 확인합니다. 유효한 경우 권한 부여 서버는 액세스 토큰 및 선택적으로 새로 고침 토큰으로 응답합니다.
클라이언트는 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 권한 부여 Endpoint URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 요청 URI를 구성합니다.
response_type
REQUIRED. 값은 "code"로 설정되어야합니다.
client_id
REQUIRED. Section 2.2에 설명 된 클라이언트 식별자.
redirect_uri
OPTIONAL. Section 3.1.2에 설명 된대로.
scope
OPTIONAL. Section 3.3에 설명 된 액세스 요청의 범위.
state
RECOMMENDED. 요청과 콜백 사이의 상태를 유지하기 위해 클라이언트가 사용하는 불투명 한 값입니다. 권한 부여 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션 할 때이 값을 포함합니다. 매개 변수는 Section 10.2에 설명 된대로 교차 사이트 요청 위조를 방지하기 위해 사용되어야합니다 (SHOULD).
클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 방법을 사용하여 리소스 소유자를 구성된 URI로 보냅니다.
예를 들어 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 수행하도록 사용자 에이전트에 지시합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
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
권한 부여 서버는 모든 필수 매개 변수가 있고 유효한지 확인하기 위해 요청의 유효성을 검증합니다. 요청이 유효한 경우 권한 부여 서버는 리소스 소유자를 인증하고 권한 결정을 얻습니다 (리소스 소유자에게 요청하거나 다른 방법을 통해 권한 부여를 설정).
결정이 설정되면 권한 부여 서버는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수있는 다른 수단을 사용하여 제공된 클라이언트 리디렉션 URI로 사용자 에이전트를 보냅니다.
리소스 소유자가 액세스 요청을 허용하면 권한 부여 서버는 "application/x-www-form-urlencoded"형식을 사용하여 리디렉션 URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 권한 부여 코드를 발급하고 클라이언트에 전달합니다. 부록 B에 따라 :
code
REQUIRED. 권한 서버에서 생성 된 권한 코드입니다. 인증 코드는 누출 위험을 줄이기 위해 발급 된 직후 만료되어야합니다. 최대 인증 코드 수명은 10분입니다. 클라이언트는 인증 코드를 사용해서는 안됩니다.
인증 코드가 두 번 이상 사용되는 경우 인증 서버는 요청을 거부해야하며 해당 인증 코드를 기반으로 이전에 발행 된 모든 토큰을 취소해야합니다 (가능한 경우). 인증 코드는 클라이언트 식별자 및 리디렉션 URI에 바인딩됩니다.
state
REQUIRED. 클라이언트 권한 요청에 "state"매개 변수가있는 경우 필수입니다. 클라이언트로부터받은 정확한 값입니다.
예를 들어 권한 부여 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
클라이언트는 인식되지 않는 응답 매개 변수를 무시해야합니다. 인증 코드 문자열 크기는 이 사양에 정의되지 않은 상태로 남아 있습니다. 클라이언트는 코드 값 크기에 대한 추측을 하지 않아야 합니다. 권한 부여 서버는 발행하는 값의 크기를 문서화해야합니다.
요청이 누락, 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 실패하거나 클라이언트 식별자가 누락되거나 유효하지 않은 경우 권한 부여 서버는 리소스 소유자에게 오류를 알려야하며 사용자 에이전트를 잘못된 리디렉션 URI로 자동 리디렉션해서는 안됩니다.
리소스 소유자가 액세스 요청을 거부하거나 누락되거나 잘못된 리디렉션 URI 이 외의 이유로 요청이 실패하는 경우 권한 부여 서버는 Appendix B의 "application/x-www-form-urlencoded"형식을 사용하여 리디렉션 URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 클라이언트에 알립니다.:
error
REQUIRED. A single ASCII [USASCII] error code from the following:
invalid_request
요청에 필수 매개 변수가 누락되었거나, 잘못된 매개 변수 값이 포함되어 있거나,
매개 변수가 두 번 이상 포함되어 있거나, 형식이 잘못되었습니다.
unauthorized_client
클라이언트는이 방법을 사용하여 인증 코드를 요청할 권한이 없습니다.
access_denied
자원 소유자 또는 권한 부여 서버가 요청을 거부했습니다.
unsupported_response_type
권한 서버는이 방법을 사용한 권한 코드 획득을 지원하지 않습니다.
invalid_scope
요청한 범위가 잘못되었거나 알 수 없거나 형식이 잘못되었습니다.
server_error
권한 부여 서버가 요청을 이행하지 못하게 하는 예기치 않은 조건을 발견했습니다.
(이 오류 코드는 500 내부 서버 오류 HTTP 상태 코드를 HTTP 리디렉션을 통해
클라이언트로 반환 할 수 없기 때문에 필요합니다.)
temporarily_unavailable
권한 부여 서버는 현재 서버의 일시적인 과부하 또는 유지 보수로 인해
요청을 처리 할 수 없습니다. (이 오류 코드는 503 Service Unavailable
HTTP 상태 코드를 HTTP 리디렉션을 통해 클라이언트에 반환 할 수 없기 때문에
필요합니다.)
"오류"매개 변수의 값은
%x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다.
error_description
OPTIONAL. 클라이언트 개발자가 발생한 오류를 이해하는 데 사용되는 추가 정보를 제공하는 사람이 읽을 수있는 ASCII [USASCII] 텍스트입니다. "error_description"매개 변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다 (MUST NOT).
error_uri
OPTIONAL. 오류에 대한 정보가있는 사람이 읽을 수있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error_uri"매개 변수의 값은 URI 참조 구문을 준수해야하며 따라서 %x21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다.
state
REQUIRED. 클라이언트 인증 요청에 "state"매개 변수가있는 경우. 클라이언트로부터받은 정확한 값입니다.
예를 들어 권한 부여 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz
클라이언트는 HTTP 요청 엔티티 본문에서 UTF-8의 문자 인코딩과 함께 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 다음 매개 변수를 전송하여 토큰 엔드 포인트에 요청합니다.
grant_type
REQUIRED. 값은 "authorization_code"로 설정되어야합니다.
code
REQUIRED. 권하 부여 서버에서 받은 권한 부여 코드입니다.
redirect_uri
REQUIRED, "redirect_uri"매개 변수가 Section 4.1.1에 설명 된대로 권한 부여 요청에 포함되었으며 해당 값이 동일해야합니다.
client_id
REQUIRED. 클라이언트가 Section 3.2.1에 설명 된대로 권한 부여 서버로 인증하지 않는 경우 필수입니다.
클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우 (또는 다른 인증 요구 사항이 할당 된 경우) 클라이언트는 Section 3.2.1에 설명 된대로 인증 서버로 인증해야합니다.
예를 들어 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 수행합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
권한 부여 서버는 다음을 수행해야합니다.
o 기밀 클라이언트 또는 클라이언트 자격 증명 (또는 기타 인증 요구 사항)이 발급 된 클라이언트에 대해 클라이언트 인증을 요구합니다.
o 클라이언트 인증이 포함 된 경우 클라이언트 인증
o 인증 코드가 인증 된 기밀 클라이언트에 발행되었는지 확인하거나 클라이언트가 공용 인 경우 코드가 요청에서 "client_id"에 발행되었는지 확인하십시오.
o 인증 코드가 유효한지 확인하고
o Section 4.1.1에 설명 된대로 "redirect_uri"매개 변수가 초기 권한 요청에 포함 된 경우 "redirect_uri"매개 변수가 있는지 확인하고 포함 된 경우 해당 값이 동일한 지 확인하십시오.
액세스 토큰 요청이 유효하고 권한 부여 된 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰과 선택적으로 새로 고침 토큰을 발급합니다. 요청 클라이언트 인증이 실패하거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
성공적인 응답의 예 :
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
암시 적 권한 부여 유형은 액세스 토큰을 얻는 데 사용되며 (새로 고침 토큰 발급을 지원하지 않음) 특정 리디렉션 URI를 작동하는 것으로 알려진 공용 클라이언트에 최적화됩니다. 이러한 클라이언트는 일반적으로 JavaScript와 같은 스크립팅 언어를 사용하는 브라우저에서 구현됩니다.
이것은 리디렉션 기반 흐름이므로 클라이언트는 리소스 소유자의 사용자 에이전트 (일반적으로 웹 브라우저)와 상호 작용할 수 있어야하며 권한 부여 서버에서 들어오는 요청 (리디렉션을 통해)을 받을 수 있어야합니다.
클라이언트가 별도의 인증 요청과 액세스 토큰을 요청하는 인증 코드 부여 유형과 달리 클라이언트는 인증 요청의 결과로 액세스 토큰을받습니다.
암시 적 부여 유형에는 클라이언트 인증이 포함되지 않으며 리소스 소유자의 존재와 리디렉션 URI의 등록에 의존합니다. 액세스 토큰은 리디렉션 URI로 인코딩되기 때문에 리소스 소유자 및 동일한 장치에있는 다른 응용 프로그램에 노출 될 수 있습니다.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
Figure 4: Implicit Grant Flow
그림 4에 표시된 흐름에는 다음 단계가 포함됩니다.:
(A) 클라이언트는 리소스 소유자의 사용자 에이전트를 권한 부여 Endpoint으로 보내 흐름을 시작합니다. 클라이언트에는 클라이언트 식별자, 요청 된 범위, 로컬 상태 및 액세스 권한이 부여 (또는 거부)되면 권한 부여 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI가 포함됩니다.
(B) 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고 리소스 소유자가 클라이언트의 액세스 요청을 허용 또는 거부할지 여부를 설정합니다.
(C) 리소스 소유자가 액세스 권한을 부여한다고 가정하면 권한 부여 서버는 이전에 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 리디렉션 URI는 URI에 액세스 토큰을 포함합니다.
(D) 사용자 에이전트는 웹 호스팅 클라이언트 리소스 ([RFC2616])에 따른 fragment을 포함하지 않음)에 요청을하여 리디렉션 지침을 따릅니다. 사용자 에이전트는 fragment 정보를 로컬로 유지합니다.
(E) 웹 호스팅 클라이언트 리소스는 사용자 에이전트가 보유한 fragment을 포함하는 전체 리디렉션 URI에 액세스하고 액세스 토큰 (및 기타 매개 변수)을 추출 할 수있는 웹 페이지 (일반적으로 스크립트가 포함 된 HTML 문서)를 반환합니다. fragment내 포함되어 있습니다.
(F) 사용자 에이전트는 웹 호스팅 클라이언트 리소스에서 제공하는 스크립트를 로컬로 실행하여 액세스 토큰을 추출합니다.
(G) 사용자 에이전트는 액세스 토큰을 클라이언트에 전달합니다.
암시 적 허용 사용에 대한 배경 정보는 Sections 1.3.2 and 9를 참조하십시오.
암시 적 허용을 사용할 때 중요한 보안 고려 사항은 Sections 10.3 and 10.16을 참조하십시오.
클라이언트는 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 권한 부여 Endpoint URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 요청 URI를 구성합니다.
response_type
REQUIRED. 값은 "token"으로 설정되어야합니다.
client_id
REQUIRED. Section 2.2에 설명 된 클라이언트 식별자.
redirect_uri
OPTIONAL. Section 3.1.2에 설명 된대로.
scope
OPTIONAL. Section 3.3에 설명 된 액세스 요청의 범위.
state
RECOMMENDED. 요청과 콜백 사이의 상태를 유지하기 위해 클라이언트가 사용하는 불투명 한 값입니다. 권한 부여 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션 할 때 이 값을 포함합니다. 매개 변수는 Section 10.12에 설명 된대로 교차 사이트 요청 위조를 방지하기 위해 사용되어야합니다 (SHOULD).
클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수있는 다른 방법을 사용하여 리소스 소유자를 구성된 URI로 보냅니다.
예를 들어 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 수행하도록 사용자 에이전트에 지시합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
권한 부여 서버는 모든 필수 매개 변수가 있고 유효한지 확인하기 위해 요청의 유효성을 검증합니다. 권한 서버는 액세스 토큰을 리디렉션 할 리디렉션 URI가 Section 3.1.2에 설명 된대로 클라이언트가 등록한 리디렉션 URI와 일치하는지 확인해야합니다.
요청이 유효한 경우 권한 부여 서버는 리소스 소유자를 인증하고 권한 결정을 얻습니다 (리소스 소유자에게 요청하거나 다른 방법을 통해 승인을 설정).
결정이 설정되면 권한 부여 서버는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수있는 다른 수단을 사용하여 제공된 클라이언트 리디렉션 URI로 사용자 에이전트를 보냅니다.
리소스 소유자가 액세스 요청을 허용하면 권한 부여 서버는 Appendix B의 "application/x-www-form-urlencoded"형식을 사용하여 리디렉션 URI의 fragment 구성 요소에 다음 매개 변수를 추가하여 액세스 토큰을 발급하고 클라이언트에 전달합니다.:
access_token
REQUIRED. 권한 부여 서버에서 발급 한 액세스 토큰입니다.
token_type
REQUIRED. Section 7.1에 설명 된대로 발행 된 토큰의 유형. 값은 대소 문자를 구분하지 않습니다.
expires_in
RECOMMENDED. 액세스 토큰의 수명(초)입니다. 예를 들어, "3600"값은 응답이 생성 된 후 1 시간 후에 액세스 토큰이 만료됨을 나타냅니다. 생략 된 경우 권한 부여 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야합니다.
scope
OPTIONAL, 클라이언트가 요청한 scope과 동일한 경우; 그렇지 않으면 REQUIRED. Section 3.3에 설명 된 액세스 토큰의 범위.
state
클라이언트 권한 요청에 "state"매개 변수가있는 경우 REQUIRED. 클라이언트로부터 받은 정확한 값입니다.
권한 부여 서버는 새로 고침 토큰을 발행해서는 안됩니다.
예를 들어 권한 부여 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다. (표시 용으로 만 추가 줄 바꿈 포함):
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
개발자는 일부 사용자 에이전트가 HTTP "Location"응답 헤더 필드에 조각 구성 요소를 포함하는 것을 지원하지 않는다는 점에 유의해야합니다. 이러한 클라이언트는 3xx 리디렉션 응답 이외의 다른 방법을 사용하여 클라이언트를 리디렉션해야합니다. 예를 들어 리디렉션 URI에 연결된 작업이있는 'continue'버튼이 포함 된 HTML 페이지를 반환합니다.
클라이언트는 인식되지 않는 응답 매개 변수를 무시해야합니다. 액세스 토큰 문자열 크기는 이 사양에 정의되지 않은 상태로 남아 있습니다. 클라이언트는 값 크기에 대한 추측을 피해야합니다. 권한 부여 서버는 발행하는 값의 크기를 문서화해야합니다.
요청이 누락, 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 실패하거나 클라이언트 식별자가 누락되거나 유효하지 않은 경우 권한 부여 서버는 리소스 소유자에게 오류를 알려야하며 사용자 에이전트를 잘못된 리디렉션 URI로 자동 리디렉션해서는 안됩니다.
리소스 소유자가 액세스 요청을 거부하거나 누락되거나 잘못된 리디렉션 URI 이외의 이유로 요청이 실패하는 경우 권한 부여 서버는 Appendix B의 "application/x-www-form-urlencoded"형식을 사용하여 리디렉션 URI의 fragment 구성 요소에 다음 매개 변수를 추가하여 클라이언트에 알립니다.:
error
REQUIRED. A single ASCII [USASCII] error code from the following:
invalid_request
요청에 필수 매개 변수가 누락되었거나, 잘못된 매개 변수 값이 포함되어 있거나,
매개 변수가 두 번 이상 포함되어 있거나, 형식이 잘못되었습니다.
unauthorized_client
클라이언트는 이 방법을 사용하여 액세스 토큰을 요청할 권한이 없습니다.
access_denied
자원 소유자 또는 권한 부여 서버가 요청을 거부했습니다.
unsupported_response_type
권한 부여 서버는 이 방법을 사용한 액세스 토큰 획득을 지원하지 않습니다.
invalid_scope
요청한 범위가 잘못되었거나 알 수 없거나 형식이 잘못되었습니다.
server_error
권한 부여 서버가 요청을 이행하지 못하게하는 예기치 않은 조건을 발견했습니다.
(이 오류 코드는 500 내부 서버 오류 HTTP 상태 코드를 HTTP 리디렉션을 통해
클라이언트로 반환 할 수 없기 때문에 필요합니다.)
temporarily_unavailable
권한 부여 서버는 현재 서버의 일시적인 과부하 또는 유지 보수로 인해
요청을 처리 할 수 없습니다.
(이 오류 코드는 503 Service Unavailable HTTP 상태 코드를
HTTP 리디렉션을 통해 클라이언트에 반환 할 수 없기 때문에 필요합니다.)
"오류"매개 변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를
포함하면 안됩니다.
error_description
OPTIONAL. 클라이언트 개발자가 발생한 오류를 이해하는 데 사용되는 추가 정보를 제공하는 사람이 읽을 수있는 ASCII [USASCII] 텍스트입니다. "error_description"매개 변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다 (MUST NOT).
error_uri
OPTIONAL. 오류에 대한 정보가있는 사람이 읽을 수 있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error_uri"매개 변수의 값은 URI 참조 구문을 준수해야하며 따라서 %x21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다.
state
클라이언트 인증 요청에 "state"매개 변수가있는 경우 REQUIRED. 클라이언트로부터받은 정확한 값입니다.
예를 들어 권한 부여 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.
HTTP/1.1 302 Found
Location: https://client.example.com/cb#error=access_denied&state=xyz
리소스 소유자 암호 자격 증명 부여 유형은 리소스 소유자가 장치 운영 체제 또는 높은 권한을 가진 응용 프로그램과 같이 클라이언트와 신뢰 관계가있는 경우에 적합합니다. 권한 부여 서버는 이 권한 부여 유형을 활성화 할 때 특별한 주의를 기울여야하며 다른 흐름이 실행 가능하지 않은 경우에만 허용해야합니다.
이 부여 유형은 리소스 소유자의 자격 증명 (일반적으로 대화 형 양식을 사용하는 사용자 이름 및 암호)을 얻을 수있는 클라이언트에 적합합니다. 또한 저장된 자격 증명을 액세스 토큰으로 변환하여 HTTP 기본 또는 다이제스트 인증과 같은 직접 인증 체계를 사용하는 기존 클라이언트를 OAuth로 마이그레이션하는 데 사용됩니다.
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials Flow
그림 5에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 리소스 소유자는 클라이언트에게 사용자 이름과 암호를 제공합니다.
(B) 클라이언트는 리소스 소유자로부터받은 자격 증명을 포함하여 권한 부여 서버의 토큰 Endpoint에서 액세스 토큰을 요청합니다. 요청을 할 때 클라이언트는 권한 부여 서버로 인증합니다.
(C) 권한 부여 서버는 클라이언트를 인증하고 리소스 소유자 자격 증명의 유효성을 검사하고 유효한 경우 액세스 토큰을 발급합니다.
클라이언트가 리소스 소유자 자격 증명을 얻는 방법은 이 사양의 범위를 벗어납니다. 클라이언트는 액세스 토큰이 확보되면 자격 증명을 폐기해야합니다.
클라이언트는 HTTP 요청 엔티티 본문에 UTF-8 문자 인코딩과 함께 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 다음 매개 변수를 추가하여 토큰 엔드 포인트에 요청합니다.
grant_type
REQUIRED. 값은 "password"로 설정해야합니다.
username
REQUIRED. 리소스 소유자 사용자 이름입니다.
password
REQUIRED. 자원 소유자 비밀번호입니다.
scope
OPTIONAL. Section 3.3에 설명 된 액세스 요청의 범위.
클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우 (또는 다른 인증 요구 사항이 할당 된 경우) 클라이언트는 Section 3.2.1에 설명 된대로 인증 서버로 인증해야합니다.
예를 들어 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
권한 부여 서버는 다음을 수행해야합니다:
o 기밀 클라이언트 또는 클라이언트 자격 증명 (또는 기타 인증 요구 사항)이 발급 된 클라이언트에 대해 클라이언트 인증을 요구합니다.
o 클라이언트 인증이 포함 된 경우 클라이언트를 인증합니다.
o 기존 비밀번호 검증 알고리즘을 사용하여 자원 소유자 비밀번호 정보를 검증합니다.
이 액세스 토큰 요청은 리소스 소유자의 비밀번호를 사용하므로 권한 부여 서버는 무차별 대입 공격 (예 : 속도 제한 사용 또는 경고 생성)으로부터 엔드 포인트를 보호해야합니다.
액세스 토큰 요청이 유효하고 권한 부여 된 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰과 선택적으로 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
성공적인 응답의 예 :
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
클라이언트는 클라이언트가 제어하에있는 보호 된 리소스에 대한 액세스를 요청할 때 또는 이전에 권한 부여 서버에 배치 된 다른 리소스 소유자(이 방법은 이 사양의 범위를 벗어납니다)의 액세스를 요청할 때 클라이언트 자격 증명 (또는 기타 지원되는 인증 수단) 만 사용하여 액세스 토큰을 요청할 수 있습니다.
클라이언트 자격 증명 부여 유형은 기밀 클라이언트 만 사용해야합니다.
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
그림 6에 표시된 흐름에는 다음 단계가 포함됩니다.
(A) 클라이언트는 권한 부여 서버로 인증하고 토큰 Endpoint에서 액세스 토큰을 요청합니다.
(B) 인증 서버는 클라이언트를 인증하고 유효한 경우 액세스 토큰을 발급합니다.
클라이언트 인증이 권한 부여로 사용되므로 추가 권한 요청이 필요하지 않습니다.
클라이언트는 HTTP 요청 엔티티 본문에 UTF-8 문자 인코딩과 함께 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 다음 매개 변수를 추가하여 토큰 엔드 포인트에 요청을합니다.
grant_type
REQUIRED. 값은 "client_credentials"로 설정되어야합니다.
scope
OPTIONAL. Section 3.3 설명 된 액세스 요청의 범위.
클라이언트는 Section 3.2.1에 설명 된대로 권한 부여 서버로 인증해야합니다.
예를 들어 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
권한 서버는 클라이언트를 인증해야합니다.
액세스 토큰 요청이 유효하고 권한이있는 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰을 발급합니다. 새로 고침 토큰은 포함하지 않아야합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
성공적인 응답의 예 :
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
클라이언트는 토큰 엔드 포인트의 "grant_type"매개 변수 값으로 절대 URI (권한 부여 서버에 의해 정의 됨)를 사용하여 부여 유형을 지정하고 필요한 추가 매개 변수를 추가하여 확장 부여 유형을 사용합니다.
예를 들어 [OAuth-SAML2]에서 정의한 SAML (Security Assertion Markup Language) 2.0 assertion 부여 유형을 사용하여 액세스 토큰을 요청하려면 클라이언트가 TLS를 사용하여 다음 HTTP 요청을 수행 할 수 있습니다. (표시 목적으로 만 추가 줄 바꿈 포함):
클라이언트는 토큰 엔드 포인트의 "grant_type"매개 변수 값으로 절대 URI (권한 부여 서버에 의해 정의 됨)를 사용하여 부여 유형을 지정하고 필요한 추가 매개 변수를 추가하여 확장 부여 유형을 사용합니다.
예를 들어 [OAuth-SAML2]에서 정의한 SAML (Security Assertion Markup Language) 2.0 assertion 부여 유형을 사용하여 액세스 토큰을 요청하려면 클라이언트가 TLS를 사용하여 다음 HTTP 요청을 수행 할 수 있습니다. (표시 목적으로 만 추가 줄 바꿈 포함):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-
bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU
[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
액세스 토큰 요청이 유효하고 권한이있는 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰과 선택적으로 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
액세스 토큰 요청이 유효하고 권한부여 된 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰과 선택적으로 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
권한 부여 서버는 액세스 토큰과 선택적으로 새로 고침 토큰을 발급하고 200(OK) 상태 코드를 사용하여 HTTP 응답의 엔티티 본문에 다음 매개 변수를 추가하여 응답을 구성합니다.
access_token
필수입니다. 권한 부여 서버에서 발급 한 액세스 토큰입니다.
token_type
REQUIRED. Section 7.1에 설명 된대로 발행 된 토큰의 유형. 값은 대소 문자를 구분하지 않습니다.
expires_in
RECOMMENDED. 액세스 토큰의 수명(초)입니다. 예를 들어, "3600"값은 응답이 생성 된 후 1 시간 후에 액세스 토큰이 만료됨을 나타냅니다. 생략 된 경우 권한 부여 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야합니다.
refresh_token
OPTIONAL. Section 6에 설명 된 것과 동일한 권한 부여를 사용하여 새 액세스 토큰을 얻는 데 사용할 수 있는 새로 고침 토큰.
scope
OPTIONAL, 클라이언트가 요청한 범위와 동일한 경우; 그렇지 않으면,
REQUIRED. Section 3.3에 설명 된 액세스 토큰의 범위.
매개 변수는 [RFC4627]에 정의 된대로 "application/json"미디어 유형을 사용하여 HTTP 응답의 엔티티 본문에 포함됩니다. 매개 변수는 가장 높은 구조 수준에서 각 매개 변수를 추가하여 JSON (JavaScript Object Notation) 구조로 직렬화됩니다. 매개 변수 이름과 문자열 값은 JSON 문자열로 포함됩니다. 숫자 값은 JSON 숫자로 포함됩니다. 매개 변수의 순서는 중요하지 않으며 다를 수 있습니다.
인증 서버는 값이 "no-cache"인 [RFC2616] "Pragma"응답 헤더 필드뿐만 아니라 토큰, 자격 증명 또는 기타 민감한 정보가 포함 된 모든 응답에 "no-store"값이있는 HTTP "Cache-Control"응답 헤더 필드 [RFC2616]를 포함해야합니다.
예를 들면 :
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
클라이언트는 응답에서 인식되지 않는 값 이름을 무시해야합니다. 권한 부여 서버에서 수신 한 토큰 및 기타 값의 크기는 정의되지 않은 상태로 남아 있습니다. 클라이언트는 값 크기에 대한 추측을 피해야합니다. 권한 부여 서버는 발행하는 값의 크기를 문서화해야합니다.
인증 서버는 HTTP 400(잘못된 요청) 상태 코드 (리 지정하지 않는 한)로 응답하고 응답에 다음 매개 변수를 포함합니다.
error
REQUIRED. A single ASCII [USASCII] error code from the following:
invalid_request
요청에 필수 매개 변수가 누락되었거나 지원되지 않는 매개 변수 값(허가 유형 제외)이
포함되어 있거나 매개 변수를 반복하거나 여러 자격 증명을 포함하거나
클라이언트 인증을 위해 둘 이상의 메커니즘을 사용하거나 기타 형식이 잘못되었습니다.
invalid_client
클라이언트 인증에 실패했습니다. (예 : 알 수없는 클라이언트,
포함 된 클라이언트 인증 없음 또는 지원되지 않는 인증 방법).
인증 서버는 HTTP 401(Unauthorized) 상태 코드를 반환하여
지원되는 HTTP 인증 체계를 나타낼 수 있습니다.
클라이언트가 "Authorization"요청 헤더 필드를 통해 인증을 시도한 경우
권한 서버는 반드시 HTTP 401(Unauthorized) 상태 코드로 응답하고
클라이언트가 사용하는 인증 체계와 일치하는
"WWW-Authenticate"응답 헤더 필드를 포함해야합니다.
invalid_grant
제공된 권한 부여 (예 : 권한 부여 코드, 리소스 소유자 자격 증명)
또는 새로 고침 토큰이 유효하지 않거나 만료되었거나 취소되었거나
권한 요청에 사용 된 리디렉션 URI와 일치하지 않거나 다른 클라이언트에 발급되었습니다.
unauthorized_client
인증 된 클라이언트는 이 권한 부여 유형을 사용할 권한이 없습니다.
unsupported_grant_type
권한 부여 유형이 권한 부여 서버에서 지원되지 않습니다.
invalid_scope
요청 된 범위가 잘못되었거나 알 수 없거나 형식이 잘못되었거나
리소스 소유자가 부여한 범위를 초과합니다.
"오류"매개 변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를
포함하면 안됩니다.
error_description
OPTIONAL. 클라이언트 개발자가 발생한 오류를 이해하는 데 사용되는 추가 정보를 제공하는 사람이 읽을 수있는 ASCII [USASCII] 텍스트입니다. "error_description"매개 변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다 (MUST NOT).
error_uri
OPTIONAL. 오류에 대한 정보가있는 사람이 읽을 수있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error_uri"매개 변수의 값은 URI 참조 구문을 준수해야하며 따라서 %x21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함하면 안됩니다.
매개 변수는 [RFC4627]에 정의 된대로 "application/json"미디어 유형을 사용하여 HTTP 응답의 엔티티 본문에 포함됩니다. 매개 변수는 가장 높은 구조 수준에서 각 매개 변수를 추가하여 JSON 구조로 직렬화됩니다. 매개 변수 이름과 문자열 값은 JSON 문자열로 포함됩니다. 숫자 값은 JSON 숫자로 포함됩니다. 매개 변수의 순서는 중요하지 않으며 다를 수 있습니다.
예를 들면 :
For example:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
권한 부여 서버가 클라이언트에 새로 고침 토큰을 발행 한 경우 클라이언트는 HTTP 요청 엔티티 본문에 UTF-8 문자 인코딩으로 Appendix B에 따라 "application/x-www-form-urlencoded"형식을 사용하여 다음 매개 변수를 추가하여 토큰 엔드 포인트에 새로 고침을 요청합니다.
grant_type
REQUIRED. 값은 "refresh_token"으로 설정되어야합니다.
refresh_token
REQUIRED. 클라이언트에 발급 된 새로 고침 토큰입니다.
scope
OPTIONAL. Section 3.3에 설명 된 액세스 요청의 범위. 요청 된 범위는 자원 소유자가 원래 부여하지 않은 범위를 포함하지 않아야하며 생략 된 경우 자원 소유자가 원래 부여한 범위와 동일하게 처리됩니다.
새로 고침 토큰은 일반적으로 추가 액세스 토큰을 요청하는 데 사용되는 오래 지속되는 자격 증명이므로 새로 고침 토큰은 발급 된 클라이언트에 바인딩됩니다. 클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받은 경우 (또는 다른 인증 요구 사항이 할당 된 경우) 클라이언트는 Section 3.2.1에 설명 된대로 인증 서버로 인증해야합니다.
예를 들어 클라이언트는 전송 계층 보안을 사용하여 다음 HTTP 요청을 수행합니다. (표시 목적으로 만 추가 줄 바꿈 포함):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
권한 부여 서버는 다음을 수행해야합니다:
o 기밀 클라이언트 또는 클라이언트 자격 증명 (또는 기타 인증 요구 사항)이 발급 된 클라이언트에 대해 클라이언트 인증을 요구합니다.
o 클라이언트 인증이 포함 된 경우 클라이언트를 인증하고 인증 된 클라이언트에 새로 고침 토큰이 발급되었는지 확인합니다.
o 새로 고침 토큰의 유효성을 검사합니다.
유효하고 권한이있는 경우 권한 부여 서버는 Section 5.1에 설명 된대로 액세스 토큰을 발급합니다. 요청이 확인에 실패했거나 유효하지 않은 경우 권한 부여 서버는 Section 5.2에 설명 된대로 오류 응답을 반환합니다.
권한 부여 서버는 새 새로 고침 토큰을 발행 할 수 있으며,이 경우 클라이언트는 이전 새로 고침 토큰을 폐기하고 새 새로 고침 토큰으로 교체해야합니다. 권한 부여 서버는 클라이언트에 새 새로 고침 토큰을 발급 한 후 이전 새로 고침 토큰을 취소 할 수 있습니다. 새 새로 고침 토큰이 발행되면 새로 고침 토큰 범위는 클라이언트가 요청에 포함하는 새로 고침 토큰의 범위와 동일해야합니다.
클라이언트는 리소스 서버에 액세스 토큰을 제공하여 보호 된 리소스에 액세스합니다. 리소스 서버는 액세스 토큰의 유효성을 검사하고 만료되지 않았는지 그리고 해당 범위가 요청 된 리소스를 포함하는지 확인해야합니다. 액세스 토큰 (및 오류 응답)을 확인하기 위해 리소스 서버가 사용하는 방법은 이 사양의 범위를 벗어나지 만 일반적으로 리소스 서버와 권한 부여 서버 간의 상호 작용 또는 조정을 포함합니다.
클라이언트가 액세스 토큰을 사용하여 리소스 서버에 인증하는 방법은 권한 부여 서버에서 발급 한 액세스 토큰 유형에 따라 다릅니다. 일반적으로 [RFC6750]과 같이 사용되는 액세스 토큰 유형의 사양에 의해 정의 된 인증 체계와 함께 HTTP "Authorization"요청 헤더 필드 [RFC2617]를 사용합니다.
액세스 토큰 유형은 클라이언트에게 액세스 토큰을 성공적으로 활용하여 보호 된 리소스 요청 (유형별 속성과 함께)을 만드는 데 필요한 정보를 제공합니다. 클라이언트는 토큰 유형을 이해하지 못하는 경우 액세스 토큰을 사용해서는 안됩니다.
예를 들어 [RFC6750]에 정의 된 "bearer"토큰 유형은 요청에 액세스 토큰 문자열을 포함하기 만하면 활용됩니다:
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
[OAuth-HTTP-MAC]에 정의 된 "mac"토큰 유형은 HTTP 요청의 특정 구성 요소에 서명하는 데 사용되는 액세스 토큰과 함께 메시지 인증 코드 (MAC) 키를 발행하여 활용됩니다:
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 인증 방법을 정의합니다.
리소스 액세스 요청이 실패하면 리소스 서버는 클라이언트에게 오류를 알려야합니다 (SHOULD). 이러한 오류 응답의 세부 사항은 이 사양의 범위를 벗어나지 만이 문서는 OAuth 토큰 인증 체계간에 오류 값을 공유하기 위해 Section 11.4에서 공통 레지스트리를 설정합니다.
주로 OAuth 토큰 인증을 위해 설계된 새로운 인증 체계는 클라이언트에 오류 상태 코드를 제공하는 메커니즘을 정의해야합니다 (SHOULD). 여기서 허용 된 오류 값은 이 사양에 의해 설정된 오류 레지스트리에 등록됩니다.
이러한 scheme는 유효한 오류 코드 집합을 등록 된 값의 하위 집합으로 제한 할 수 있습니다. 명명 된 매개 변수를 사용하여 오류 코드가 반환되는 경우 매개 변수 이름은 "error"여야합니다 (SHOULD).
OAuth 토큰 인증에 사용할 수 있지만 주로 해당 목적으로 설계되지 않은 다른 체계는 동일한 방식으로 오류 값을 레지스트리에 바인딩 할 수 있습니다.
새로운 인증 체계는 "error_description"및 "error_uri"매개 변수의 사용을 지정하여 이 사양에서의 사용과 병렬로 오류 정보를 반환하도록 선택할 수도 있습니다.
액세스 토큰 유형은 액세스 토큰 유형 레지스트리에 등록 (Section 11.1)의 절차에 따라)하거나 고유 한 절대 URI를 이름으로 사용하는 두 가지 방법 중 하나로 정의 할 수 있습니다.
URI 이름을 사용하는 유형은 일반적으로 적용 할 수 없는 공급 업체별 구현으로 제한되어야하며 이들이 사용되는 리소스 서버의 구현 세부 사항에 고유해야합니다.
다른 모든 유형은 등록해야합니다. 유형 이름은 유형 이름 ABNF를 준수해야합니다. 유형 정의에 새로운 HTTP 인증 체계가 포함 된 경우 유형 이름은 HTTP 인증 체계 이름 ([RFC2617])에 정의 된대로)과 동일해야합니다 (SHOULD). 토큰 유형 "example"은 예제에서 사용하도록 예약되어 있습니다.
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
권한 부여 Endpoint 또는 토큰 Endpoint와 함께 사용 할 새 요청 또는 응답 매개 변수는 Section 11.2의 절차에 따라 OAuth 매개 변수 레지스트리에 정의되고 등록됩니다.
매개 변수 이름은 매개 변수 이름 ABNF를 준수해야하며 매개 변수 값 구문은 잘 정의되어야합니다 (예 : ABNF 사용 또는 기존 매개 변수의 구문 참조).
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
일반적으로 적용 할 수 없고 사용되는 권한 부여 서버의 구현 세부 사항에 특정한 등록되지 않은 공급 업체별 매개 변수 확장은 다른 등록 된 값과 충돌 할 가능성이 없는 공급 업체별 접두사를 사용해야합니다 (예 : 'companyname_'로 시작).
새로운 권한 부여 유형은 "grant_type"매개 변수와 함께 사용할 고유 한 절대 URI를 할당하여 정의 할 수 있습니다. 확장 부여 유형에 추가 토큰 엔드 포인트 매개 변수가 필요한 경우 Section 11.2에 설명 된대로 OAuth 매개 변수 레지스트리에 등록해야합니다.
권한 부여 Endpoint와 함께 사용할 새 응답 유형은 Section 11.3의 절차에 따라 권한 부여 Endpoint 응답 유형 레지스트리에 정의되고 등록됩니다. 응답 유형 이름은 응답 유형 ABNF를 준수해야합니다.
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
응답 유형에 공백 문자 (%x20)가 하나 이상 포함되어 있으면 값 순서가 중요하지 않은 공백으로 구분 된 값 목록과 비교됩니다. 동일한 값 세트의 다른 모든 배열을 포함하는 하나의 값 순서 만 등록 할 수 있습니다.
예를 들어, 응답 유형 "token code"는 이 사양에 정의되지 않은 상태로 남아 있습니다. 그러나 확장은 "token code"응답 유형을 정의하고 등록 할 수 있습니다. 등록한 후에는 동일한 조합을 "token code"으로 등록 할 수 없지만 두 값을 모두 사용하여 동일한 응답 유형을 나타낼 수 있습니다.
프로토콜 확장 (예 : 액세스 토큰 유형, 확장 매개 변수 또는 확장 권한 부여 유형)에서 권한 부여 코드 부여 오류 응답 (Section 4.1.2.1), 암시 적 권한 부여 오류 응답 (Section 4.2.2.1), 토큰 오류 응답 (Section 5.2) 또는 리소스 액세스 오류 응답 (Section 7.2)과 함께 추가 오류 코드가 필요한 경우 이러한 오류 코드는 정의 될 수 있습니다.
확장 오류 코드는 함께 사용되는 확장이 등록 된 액세스 토큰 유형, 등록 된 엔드 포인트 매개 변수 또는 확장 부여 유형 인 경우 반드시 등록되어야합니다 (Section 11.4)의 절차에 따라). 등록되지 않은 확장에 사용 된 오류 코드를 등록 할 수 있습니다.
오류 코드는 오류 ABNF를 준수해야하며 가능하면 식별 이름을 접두사로 붙여야합니다 (SHOULD). 예를 들어, 확장 매개 변수 "example"에 설정된 유효하지 않은 값을 식별하는 오류는 "example_invalid"로 이름을 지정해야합니다 (SHOULD).
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
기본 응용 프로그램은 리소스 소유자가 사용하는 장치 (예 : 데스크톱 응용 프로그램, 기본 모바일 응용 프로그램)에 설치되고 실행되는 클라이언트입니다. 기본 애플리케이션에는 보안, 플랫폼 기능 및 전반적인 최종 사용자 경험과 관련된 특별한 고려 사항이 필요합니다.
권한 부여 Endpoint에는 클라이언트와 리소스 소유자의 사용자 에이전트 간의 상호 작용이 필요합니다. 기본 애플리케이션은 외부 사용자 에이전트를 호출하거나 애플리케이션 내에 사용자 에이전트를 포함 할 수 있습니다. 예를 들면 :
o 외부 사용자 에이전트-네이티브 애플리케이션은 운영 체제에 등록 된 체계가있는 리디렉션 URI를 사용하여 권한 부여 서버에서 응답을 캡처하여 클라이언트를 핸들러로 호출하고 자격 증명의 수동 복사 및 붙여 넣기, 로컬 실행 웹 서버, 사용자 에이전트 확장을 설치하거나 클라이언트의 제어하에 서버 호스팅 리소스를 식별하는 리디렉션 URI를 제공하여 네이티브 애플리케이션에서 응답을 사용할 수 있도록합니다.
o 임베디드 사용자 에이전트-네이티브 애플리케이션은 리소스 로드 중에 발생하는 상태 변경을 모니터링하거나 사용자 에이전트의 쿠키 저장소에 액세스하여 임베디드 사용자 에이전트와 직접 통신하여 응답을 얻습니다.
외부 또는 임베디드 사용자 에이전트 중에서 선택할 때 개발자는 다음 사항을 고려해야합니다.
o 외부 사용자 에이전트는 자원 소유자가 이미 권한 부여 서버와 활성 세션을 가지고있을 수 있으므로 재 인증 필요성을 제거하여 익숙한 최종 사용자 경험과 기능을 제공합니다.
리소스 소유자는 인증을 지원하기 위해 사용자 에이전트 기능 또는 확장 (예 : 암호 관리자, 2 단계 장치 판독기)에 의존 할 수도 있습니다.
o 내장 된 사용자 에이전트는 컨텍스트를 전환하고 새 창을 열 필요가 없으므로 향상된 사용성을 제공 할 수 있습니다.
o 내장 된 사용자 에이전트는 대부분의 외부 사용자 에이전트에서 볼 수있는 시각적 보호에 액세스하지 않고 리소스 소유자가 식별되지 않은 창에서 인증하기 때문에 보안 문제를 제기합니다. 내장 된 사용자 에이전트는 최종 사용자가 식별되지 않은 인증 요청을 신뢰하도록 교육합니다 (피싱 공격을 더 쉽게 실행할 수 있음).
암시 적 부여 유형과 권한 부여 코드 부여 유형 중에서 선택할 때 다음 사항을 고려해야합니다.
o 인증 코드 부여 유형을 사용하는 네이티브 애플리케이션은 네이티브 애플리케이션이 클라이언트 자격 증명을 기밀로 유지할 수 없기 때문에 클라이언트 자격 증명을 사용하지 않아야 합니다 (SHOULD).
o 암시 적 권한 부여 유형 흐름을 사용할 때 새로 고침 토큰이 반환되지 않으므로 액세스 토큰이 만료되면 권한 부여 프로세스를 반복해야합니다.
유연하고 확장 가능한 프레임워크 인 OAuth의 보안 고려 사항은 여러 요소에 따라 달라집니다. Section 2.1에 설명 된 세 가지 클라이언트 프로필 인 웹 애플리케이션, 사용자 에이전트 기반 애플리케이션 및 기본 애플리케이션에 초점을 맞춘 보안 지침을 구현 자에게 제공합니다.
[OAuth-THREATMODEL]은 포괄적 인 OAuth 보안 모델 및 분석과 프로토콜 설계의 배경을 제공합니다.
권한 부여 서버는 클라이언트 인증을 위해 웹 응용 프로그램 클라이언트에 클라이언트 자격 증명을 설정합니다. 권한 부여 서버는 클라이언트 암호보다 더 강력한 클라이언트 인증 수단을 고려하는 것이 좋습니다. 웹 애플리케이션 클라이언트는 클라이언트 암호 및 기타 클라이언트 자격 증명의 기밀성을 보장해야합니다.
권한 부여 서버는 클라이언트 인증을 위해 클라이언트 암호 또는 기타 클라이언트 자격 증명을 기본 응용 프로그램 또는 사용자 에이전트 기반 응용 프로그램 클라이언트에 발급해서는 안됩니다. 권한 부여 서버는 특정 장치에 기본 응용 프로그램 클라이언트의 특정 설치를 위해 클라이언트 암호 또는 기타 자격 증명을 발급 할 수 있습니다.
클라이언트 인증이 불가능한 경우 권한 부여 서버는 클라이언트의 ID를 확인하기 위해 다른 수단을 사용해야합니다 (예 : 클라이언트 리디렉션 URI의 등록을 요구하거나 리소스 소유자에게 ID를 확인하도록 요청). 유효한 리디렉션 URI는 리소스 소유자 권한 부여를 요청할 때 클라이언트의 ID를 확인하는 데 충분하지 않지만 리소스 소유자 권한을 얻은 후 위조 클라이언트에 자격 증명을 전달하는 것을 방지하는 데 사용할 수 있습니다.
권한 부여 서버는 인증되지 않은 클라이언트와 상호 작용할 때의 보안 의미를 고려하고 해당 클라이언트에 발급 된 다른 자격 증명 (예 : 새로 고침 토큰)의 잠재적 인 노출을 제한하는 조치를 취해야합니다.
악의적 인 클라이언트는 가장 된 클라이언트가 클라이언트 자격 증명을 기밀로 유지하지 못하거나 유지할 수없는 경우 다른 클라이언트를 가장하고 보호 된 리소스에 대한 액세스 권한을 얻을 수 있습니다.
권한 부여 서버는 가능할 때마다 클라이언트를 인증해야합니다. 권한 부여 서버가 클라이언트의 특성으로 인해 클라이언트를 인증 할 수없는 경우 권한 부여 서버는 인증 응답을 수신하는 데 사용되는 리디렉션 URI의 등록을 요구해야하며 잠재적으로 악의적 인 클라이언트로부터 자원 소유자를 보호하기 위해 다른 수단을 사용해야합니다 (SHOULD). 예를 들어, 권한 부여 서버는 클라이언트 및 해당 출처를 식별하는 데 도움을주기 위해 자원 소유자를 참여시킬 수 있습니다.
권한 부여 서버는 명시 적 자원 소유자 인증을 시행하고 클라이언트에 대한 정보와 요청 된 권한 범위 및 수명을 자원 소유자에게 제공해야합니다. 현재 클라이언트의 컨텍스트에서 정보를 검토하고 요청을 승인하거나 거부하는 것은 리소스 소유자에게 달려 있습니다.
권한 부여 서버는 클라이언트를 인증하거나 다른 조치에 의존하지 않고 반복 된 권한 요청이 가장자가 아닌 원래 클라이언트에서 오는지 확인하지 않고 자동으로 (활성 리소스 소유자 상호 작용없이) 요청을 처리해서는 안됩니다.
액세스 토큰 자격 증명 (기밀 액세스 토큰 속성 포함)은 전송 및 저장시 기밀로 유지되어야하며 권한 부여 서버, 액세스 토큰이 유효한 리소스 서버 및 액세스 토큰이 발급 된 클라이언트간에만 공유되어야합니다. 액세스 토큰 자격 증명은 [RFC2818]에 정의 된 서버 인증과 함께 Section 1.6에 설명 된대로 TLS를 사용하여 전송되어야합니다.
암시 적 허용 유형을 사용하는 경우 액세스 토큰은 URI fragment로 전송되어 권한이 없는 당사자에게 노출 될 수 있습니다.
인증 서버는 인증되지 않은 당사자가 유효한 액세스 토큰을 생성하기 위해 액세스 토큰을 생성, 수정 또는 추측 할 수 없도록 해야합니다.
클라이언트는 필요한 최소한의 범위로 액세스 토큰을 요청해야합니다. 인증 서버는 요청 된 범위를 선택할 때 클라이언트 ID를 고려해야하며 요청 된 것보다 적은 권한으로 액세스 토큰을 발급 할 수 있습니다.
이 사양은 주어진 클라이언트가 제공 한 액세스 토큰이 권한 부여 서버에 의해 해당 클라이언트에 발급되었는지 확인하기 위해 리소스 서버에 대한 방법을 제공하지 않습니다.
권한 부여 서버는 웹 애플리케이션 클라이언트와 네이티브 애플리케이션 클라이언트에 새로 고침 토큰을 발행 할 수 있습니다.
새로 고침 토큰은 전송 및 저장시 기밀로 유지되어야하며 갱신 토큰이 발행 된 인증 서버와 클라이언트 사이에서만 공유되어야합니다. 권한 부여 서버는 갱신 토큰과 발행 된 클라이언트 사이의 바인딩을 유지해야합니다. 갱신 토큰은 [RFC2818]에 정의 된대로 서버 인증과 함께 Section 1.6에 설명 된대로 TLS를 사용하여 전송되어야합니다.
권한 부여 서버는 클라이언트 ID가 인증 될 때마다 새로 고침 토큰과 클라이언트 ID 간의 바인딩을 확인해야합니다. 클라이언트 인증이 불가능한 경우 권한 부여 서버는 새로 고침 토큰 남용을 감지하기 위해 다른 수단을 배포해야합니다 (SHOULD).
예를 들어 권한 부여 서버는 모든 액세스 토큰 새로 고침 응답과 함께 새 새로 고침 토큰이 발급되는 새로 고침 토큰 순환을 사용하여 이전 새로 고침 토큰이 무효화되도록 합니다.
그러나 권한 부여 서버에 의해 유지됩니다. 새로 고침 토큰이 손상되어 공격자와 합법적 인 클라이언트가 모두 사용하는 경우 그중 하나가 무효화 된 새로 고침 토큰을 제공하여 위반 사실을 인증 서버에 알립니다.
권한 부여 서버는 권한이 없는 당사자가 유효한 새로 고침 토큰을 생성하기 위해 새로 고침 토큰을 생성, 수정 또는 추측 할 수 없도록 해야합니다.
권한 부여 코드의 전송은 보안 채널을 통해 이루어져야하며, URI가 네트워크 리소스를 식별하는 경우 클라이언트는 리디렉션 URI와 함께 TLS를 사용해야합니다 (SHOULD). 권한 부여 코드는 사용자 에이전트 리디렉션을 통해 전송되기 때문에 사용자 에이전트 기록 및 HTTP 참조 헤더를 통해 공개 될 수 있습니다.
권한 부여 코드는 권한 부여 서버에서 권한을 부여한 자원 소유자가 프로세스를 완료하기 위해 클라이언트에 반환하는 동일한 자원 소유자인지 확인하는 데 사용되는 일반 텍스트 전달자 자격 증명으로 작동합니다. 따라서 클라이언트가 자체 리소스 소유자 인증을위한 권한 부여 코드에 의존하는 경우 클라이언트 리디렉션 Endpoint는 TLS를 사용해야합니다.
권한 부여 코드는 수명이 짧고 일회용이어야합니다. 권한 부여 서버가 액세스 토큰에 대한 권한 부여 코드를 교환하려는 여러 번의 시도를 관찰하면 권한 부여 서버는 손상된 인증 코드를 기반으로 이미 부여 된 모든 액세스 토큰을 취소하려고 시도해야합니다 (SHOULD).
클라이언트가 인증 될 수있는 경우 권한 부여 서버는 클라이언트를 인증하고 권한 코드가 동일한 클라이언트에 발급되었는지 확인해야합니다.
권한 부여 코드 부여 유형을 사용하여 인증을 요청할 때 클라이언트는 "redirect_uri"매개 변수를 통해 리디렉션 URI를 지정할 수 있습니다. 공격자가 리디렉션 URI의 값을 조작 할 수있는 경우 권한 부여 서버가 리소스 소유자 사용자 에이전트를 권한 코드가있는 공격자의 제어하에있는 URI로 리디렉션하도록 할 수 있습니다.
공격자는 합법적인 클라이언트에서 계정을 만들고 권한 부여 흐름을 시작할 수 있습니다. 공격자의 사용자 에이전트가 액세스 권한을 부여하기 위해 권한 부여 서버로 전송되면 공격자는 합법적인 클라이언트가 제공 한 권한 부여 URI를 가져 와서 클라이언트의 리디렉션 URI를 공격자가 제어하는 URI로 바꿉니다. 그런 다음 공격자는 피해자가 조작 된 링크를 따라 가도록 속여 합법적 인 클라이언트에 대한 액세스 권한을 부여합니다.
권한 부여 서버에서 피해자는 합법적이고 신뢰할 수있는 클라이언트를 대신하여 정상적이고 유효한 요청을 프롬프트하고 요청을 승인합니다. 그런 다음 피해자는 인증 코드를 사용하여 공격자가 제어하는 엔드 포인트로 리디렉션됩니다. 공격자는 클라이언트가 제공 한 원래 리디렉션 URI를 사용하여 클라이언트에 인증 코드를 전송하여 인증 흐름을 완료합니다. 클라이언트는 인증 코드를 액세스 토큰과 교환하고이를 공격자의 클라이언트 계정에 연결합니다. 그러면 이제 피해자가 인증 한 보호 된 리소스에 액세스 할 수 있습니다 (클라이언트를 통해).
이러한 공격을 방지하기 위해 인증 서버는 인증 코드를 얻기 위해 사용 된 리디렉션 URI가 액세스 토큰에 대한 인증 코드를 교환 할 때 제공된 리디렉션 URI와 동일한 지 확인해야합니다. 권한 부여 서버는 반드시 공용 클라이언트를 필요로하고 기밀 클라이언트가 리디렉션 URI를 등록하도록 요구해야합니다 (SHOULD). 요청에 리디렉션 URI가 제공되면 권한 부여 서버는 등록 된 값에 대해 이를 확인해야합니다.
리소스 소유자 암호 자격 증명 부여 유형은 종종 레거시 또는 마이그레이션 이유로 사용됩니다. 클라이언트가 사용자 이름과 암호를 저장하는 전반적인 위험을 줄이지 만 높은 권한을 가진 자격 증명을 클라이언트에 노출 할 필요가 없습니다.
이 부여 유형은 이 프로토콜이 피하려는 암호 안티 패턴을 유지하기 때문에 다른 부여 유형보다 더 높은 위험을 수반합니다. 클라이언트가 암호를 남용하거나 의도하지 않게 공격자에게 암호가 공개 될 수 있습니다 (예 : 클라이언트가 보관하는 로그 파일 또는 기타 기록을 통해).
또한 리소스 소유자가 권한 부여 프로세스를 제어 할 수 없기 때문에 (리소스 소유자의 참여는 클라이언트에게 자격 증명을 넘겨 줄 때 종료 됨) 클라이언트는 리소스 소유자가 원하는 것보다 더 넓은 범위의 액세스 토큰을 얻을 수 있습니다. 권한 부여 서버는 이 권한 부여 유형을 통해 발급 된 액세스 토큰의 범위와 수명을 고려해야합니다.
권한 부여 서버와 클라이언트는 이 권한 부여 유형의 사용을 최소화하고 가능할 때마다 다른 권한 부여 유형을 활용해야합니다.
액세스 토큰, 새로 고침 토큰, 리소스 소유자 암호 및 클라이언트 자격 증명은 일반 정보로 전송하면 안됩니다. 인증 코드는 투명하게 전송하면 안됩니다.
"state"및 "scope"매개 변수는 안전하지 않은 채널을 통해 전송되거나 안전하지 않게 저장 될 수 있으므로 민감한 클라이언트 또는 리소스 소유자 정보를 일반 텍스트로 포함해서는 안됩니다.
man-in-the-middle 공격을 방지하기 위해 권한 부여 서버는 권한 부여 및 토큰 Endpoint로 전송 된 모든 요청에 대해 [RFC2818]에 정의 된 서버 인증과 함께 TLS를 사용해야합니다. 클라이언트는 [RFC6125]에 정의 된대로 그리고 서버 신원 인증에 대한 요구 사항에 따라 권한 부여 서버의 TLS 인증서를 확인해야합니다.
인증 서버는 공격자가 액세스 토큰, 인증 코드, 새로 고침 토큰, 리소스 소유자 암호 및 클라이언트 자격 증명을 추측하지 못하도록해야합니다.
공격자가 생성 된 토큰 (및 최종 사용자가 처리하도록 의도되지 않은 기타 자격 증명)을 추측 할 확률은 2^(-128)보다 작거나 같아야하고 2^(-160)보다 작거나 같아야합니다 (SHOULD).
권한 서버는 최종 사용자 사용을위한 자격 증명을 보호하기 위해 다른 수단을 사용해야합니다.
이 프로토콜과 유사한 프로토콜을 광범위하게 배포하면 최종 사용자가 암호를 입력하라는 웹 사이트로 리디렉션되는 관행에 익숙해 질 수 있습니다. 최종 사용자가 자격 증명을 입력하기 전에 이러한 웹 사이트의 진위 여부를 신중하게 확인하지 않으면 공격자가이 방법을 악용하여 리소스 소유자의 암호를 훔칠 수 있습니다.
서비스 제공 업체는 피싱 공격으로 인한 위험에 대해 최종 사용자를 교육해야하며 최종 사용자가 사이트의 진위 여부를 쉽게 확인할 수있는 메커니즘을 제공해야합니다. 클라이언트 개발자는 사용자 에이전트와 상호 작용하는 방식 (예 : 외부, 임베디드)의 보안 의미와 최종 사용자가 권한 부여 서버의 진위를 확인하는 능력을 고려해야합니다.
피싱 공격의 위험을 줄이기 위해 권한 부여 서버는 최종 사용자 상호 작용에 사용되는 모든 엔드 포인트에서 TLS를 사용해야합니다.
CSRF(Cross-Site Request Forgery)는 공격자가 피해자 최종 사용자의 사용자 에이전트가 악성 URI로 (예 : 사용자 에이전트에 오해의 소지가있는 링크, 이미지 또는 리디렉션으로 제공됨) 신뢰된 서버 (일반적으로 유효한 세션 쿠키의 존재를 통해 설정 됨)에 전송합니다.
클라이언트의 리디렉션 URI에 대한 CSRF 공격을 통해 공격자는 자신의 인증 코드 또는 액세스 토큰을 주입 할 수 있습니다. 이로 인해 클라이언트는 피해자의 리소스가 아닌 공격자의 보호 된 리소스와 관련된 액세스 토큰을 사용할 수 있습니다 (예 : 피해자의 은행 계좌 정보 저장). 공격자가 제어하는 보호 된 리소스에 연결).
클라이언트는 리디렉션 URI에 대한 CSRF 보호를 구현해야합니다. 이는 일반적으로 리디렉션 URI 엔드 포인트로 전송 된 모든 요청에 요청을 사용자 에이전트의 인증 된 상태 (예 : 사용자 에이전트를 인증하는 데 사용되는 세션 쿠키의 해시)에 바인딩하는 값을 포함하도록 요구하여 수행됩니다. 클라이언트는 인증 요청을 할 때 인증 서버에이 값을 전달하기 위해 "state"요청 매개 변수를 사용해야합니다.
최종 사용자로부터 인증을 받으면 인증 서버는 "state"매개 변수에 포함 된 필수 바인딩 값을 사용하여 최종 사용자의 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 바인딩 값을 사용하면 클라이언트가 바인딩 값을 사용자 에이전트의 인증 된 상태와 일치시켜 요청의 유효성을 확인할 수 있습니다. CSRF 보호에 사용되는 바인딩 값은 추정 할 수없는 값 (Section 10.10에 설명 됨)을 포함해야하며 사용자 에이전트의 인증 상태 (예 : 세션 쿠키, HTML5 로컬 저장소)는 클라이언트 만 액세스 할 수있는 위치에 유지되어야합니다. 및 사용자 에이전트 (즉, 동일 출처 정책에 의해 보호됨).
권한 부여 서버의 권한 부여 Endpoint에 대한 CSRF 공격은 공격자가 최종 사용자를 포함하거나 경고하지 않고 악의적인 클라이언트에 대한 최종 사용자 권한을 획득 할 수 있습니다.
권한 부여 서버는 권한 부여 Endpoint에 대한 CSRF 보호를 구현해야하며 악의적인 클라이언트가 리소스 소유자의 인식 및 명시 적 동의없이 권한을 얻을 수 없도록해야합니다.
Clickjacking 공격에서 공격자는 합법적 인 클라이언트를 등록한 다음 직접 배치 할 수 있도록 신중하게 구성된 더미 버튼 위에 오버레이 된 투명한 iframe에 권한 부여 서버의 권한 부여 Endpoint 웹 페이지를로드하는 악성 사이트를 구성합니다. 인증 페이지의 중요한 버튼 아래에 있습니다. 최종 사용자가 오해의 소지가있는 보이는 버튼을 클릭하면 최종 사용자는 실제로 인증 페이지에서 보이지 않는 버튼 (예 : "Authorize"버튼)을 클릭하는 것입니다. 이를 통해 공격자는 리소스 소유자를 속여 최종 사용자가 모르게 클라이언트 액세스 권한을 부여 할 수 있습니다.
이러한 형태의 공격을 방지하기 위해 네이티브 애플리케이션은 최종 사용자 인증을 요청할 때 애플리케이션 내에 브라우저를 포함하는 대신 외부 브라우저를 사용해야합니다. 대부분의 최신 브라우저에서는 (비표준) "x-frame-options"헤더를 사용하여 권한 부여 서버에서 iframe을 피할 수 있습니다. 이 헤더에는 "deny"및 "sameorigin"이라는 두 가지 값이있을 수 있으며, 이는 각각 다른 출처를 가진 사이트 별 프레임 또는 프레임을 차단합니다. 이전 브라우저의 경우 JavaScript frame-busting 기술을 사용할 수 있지만 모든 브라우저에서 효과적이지 않을 수 있습니다.
코드 삽입 공격은 입력 또는 기타 외부 변수가 응용 프로그램에 의해 사용되어 응용 프로그램 로직을 수정하는 경우 발생합니다. 이로 인해 공격자는 애플리케이션 장치 또는 해당 데이터에 대한 액세스 권한을 얻거나 서비스 거부를 유발하거나 광범위한 악의적인 부작용을 일으킬 수 있습니다.
권한 부여 서버와 클라이언트는 수신 된 모든 값, 특히 "state"및 "redirect_uri"매개 변수의 값을 삭제해야합니다 (가능한 경우 유효성 검사).
권한 부여 서버, 권한 부여 Endpoint 및 클라이언트 리디렉션 Endpoint가 잘못 구성되어 개방형 리디렉터로 작동 할 수 있습니다. 개방형 리디렉터는 매개 변수를 사용하여 유효성 검사없이 사용자 에이전트를 매개 변수 값에 지정된 위치로 자동 리디렉션하는 엔드 포인트입니다.
오픈 리디렉터는 피싱 공격에 사용되거나 공격자가 익숙하고 신뢰할 수있는 대상의 URI 기관 구성 요소를 사용하여 최종 사용자가 악성 사이트를 방문하도록 유도 할 수 있습니다. 또한 권한 부여 서버가 클라이언트가 리디렉션 URI의 일부만 등록하도록 허용하는 경우 공격자는 다음에서 운영하는 개방형 리디렉터를 사용할 수 있습니다.
클라이언트는 권한 부여 서버 유효성 검사를 통과하지만 공격자가 제어하는 Endpoint에 권한 부여 코드 또는 액세스 토큰을 보내는 리디렉션 URI를 구성합니다.
암시적 흐름을 사용하는 공용 클라이언트의 경우 이 사양은 클라이언트가 액세스 토큰이 발급 된 클라이언트를 확인할 수있는 방법을 제공하지 않습니다.
리소스 소유자는 공격자의 악의적인 클라이언트에 액세스 토큰을 부여하여 리소스에 대한 액세스 권한을 기꺼이 위임 할 수 있습니다. 이것은 피싱이나 다른 구실 때문일 수 있습니다. 공격자는 다른 메커니즘을 통해 토큰을 훔칠 수도 있습니다. 그런 다음 공격자는 합법적인 공용 클라이언트에 액세스 토큰을 제공하여 리소스 소유자를 가장하려고 할 수 있습니다.
암시적 흐름 (response_type = token)에서 공격자는 인증 서버의 응답에서 토큰을 쉽게 전환하여 실제 액세스 토큰을 공격자에게 이전에 발급 한 토큰으로 대체 할 수 있습니다.
클라이언트 사용자를 식별하기 위해 백 채널에서 액세스 토큰이 전달되는 데 의존하는 네이티브 애플리케이션과 통신하는 서버는 임의의 도난 된 액세스 토큰을 삽입 할 수있는 손상된 애플리케이션을 만드는 공격자에 의해 유사하게 손상 될 수 있습니다.
리소스 소유자만 리소스에 대한 유효한 액세스 토큰을 제공 할 수 있다고 가정하는 모든 공용 클라이언트는 이러한 유형의 공격에 취약합니다.
이러한 유형의 공격은 합법적인 클라이언트의 리소스 소유자에 대한 정보를 공격자 (악성 클라이언트)에게 노출 할 수 있습니다. 이렇게하면 공격자는 원래 액세스 토큰 또는 인증 코드를 부여한 리소스 소유자와 동일한 권한으로 합법적인 클라이언트에서 작업을 수행 할 수 있습니다.
클라이언트에 대한 리소스 소유자 인증은 이 사양의 범위를 벗어납니다. 권한 부여 프로세스를 클라이언트에 위임 된 최종 사용자 인증의 형식으로 사용하는 모든 사양 (예 : 타사 로그인 서비스)은 클라이언트가 액세스 권한을 결정할 수 있도록하는 추가 보안 메커니즘(예 : 액세스 토큰을 대상으로 제한) 없이 암시적 흐름을 사용해서는 안됩니다.
This specification establishes the OAuth Access Token Types registry.
Access token types are registered with a Specification Required ([RFC5226]) after a two-week review period on the [email protected] mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
Registration requests must be sent to the [email protected] mailing list for review and comment, with an appropriate subject (e.g., "Request for access token type: example").
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
Type name:
The name requested (e.g., "example").
Additional Token Endpoint Response Parameters:
Additional response parameters returned together with the "access_token" parameter. New parameters MUST be separately registered in the OAuth Parameters registry as described by Section 11.2.
HTTP Authentication Scheme(s):
The HTTP authentication scheme name(s), if any, used to authenticate protected resource requests using access tokens of this type.
Change controller:
For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Specification document(s):
Reference to the document(s) that specify the parameter, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
This specification establishes the OAuth Parameters registry.
Additional parameters for inclusion in the authorization endpoint request, the authorization endpoint response, the token endpoint request, or the token endpoint response are registered with a Specification Required ([RFC5226]) after a two-week review period on the [email protected] mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
Registration requests must be sent to the [email protected] mailing list for review and comment, with an appropriate subject (e.g., "Request for parameter: example").
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
Parameter name:
The name requested (e.g., "example").
Parameter usage location:
The location(s) where parameter can be used. The possible locations are authorization request, authorization response, token request, or token response.
Change controller:
For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Specification document(s):
Reference to the document(s) that specify the parameter, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
The OAuth Parameters registry's initial contents are:
o Parameter name: client_id
o Parameter usage location: authorization request, token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: client_secret
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: response_type
o Parameter usage location: authorization request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: redirect_uri
o Parameter usage location: authorization request, token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: scope
o Parameter usage location: authorization request, authorization
response, token request, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: state
o Parameter usage location: authorization request, authorization
response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: code
o Parameter usage location: authorization response, token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: error_description
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: error_uri
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: grant_type
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: access_token
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: token_type
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: expires_in
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: username
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: password
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): RFC 6749
o Parameter name: refresh_token
o Parameter usage location: token request, token response
o Change controller: IETF
o Specification document(s): RFC 6749
This specification establishes the OAuth Authorization Endpoint Response Types registry.
Additional response types for use with the authorization endpoint are registered with a Specification Required ([RFC5226]) after a two-week review period on the [email protected] mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
Registration requests must be sent to the [email protected] mailing list for review and comment, with an appropriate subject (e.g., "Request for response type: example").
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
Response type name:
The name requested (e.g., "example").
Change controller:
For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Specification document(s):
Reference to the document(s) that specify the type, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
The OAuth Authorization Endpoint Response Types registry's initial contents are:
o Response type name: code
o Change controller: IETF
o Specification document(s): RFC 6749
o Response type name: token
o Change controller: IETF
o Specification document(s): RFC 6749
This specification establishes the OAuth Extensions Error registry.
Additional error codes used together with other protocol extensions (i.e., extension grant types, access token types, or extension parameters) are registered with a Specification Required ([RFC5226]) after a two-week review period on the [email protected] mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
Registration requests must be sent to the [email protected] mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example").
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
Error name:
The name requested (e.g., "example"). Values for the error name MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
Error usage location:
The location(s) where the error can be used. The possible locations are authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), token error response (Section 5.2), or resource access error response (Section 7.2).
Related protocol extension:
The name of the extension grant type, access token type, or extension parameter that the error code is used in conjunction with.
Change controller:
For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Specification document(s):
Reference to the document(s) that specify the error code, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, http://www.w3.org/TR/1999/REC-html401-19991224.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, http://www.w3.org/TR/2008/REC-xml-20081126.
Hardt Standards Track [Page 69]
RFC 6749 OAuth 2.0 October 2012
[OAuth-HTTP-MAC] Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access Authentication", Work in Progress, February 2012.
[OAuth-SAML2] Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", Work in Progress, September 2012.
[OAuth-THREATMODEL] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", Work in Progress, October 2012.
[OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", Work in Progress, January 2010.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
Hardt Standards Track [Page 70]
RFC 6749 OAuth 2.0 October 2012
This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. The ABNF below is defined in terms of Unicode code points [W3C.REC-xml-20081126]; these characters are typically encoded in UTF-8. Elements are presented in the order first defined.
Some of the definitions that follow use the "URI-reference" definition from [RFC3986].
Some of the definitions that follow use these common definitions:
VSCHAR = %x20-7E
NQCHAR = %x21 / %x23-5B / %x5D-7E
NQSCHAR = %x20-21 / %x23-5B / %x5D-7E
UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
%xE000-FFFD / %x10000-10FFFF
(The UNICODECHARNOCRLF definition is based upon the Char definition in Section 2.2 of [W3C.REC-xml-20081126], but omitting the Carriage Return and Linefeed characters.)
The "client_id" element is defined in Section 2.3.1:
client-id = *VSCHAR
The "client_secret" element is defined in Section 2.3.1:
client-secret = *VSCHAR
The "response_type" element is defined in Sections 3.1.1 and 8.4:
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
Hardt Standards Track [Page 71]
RFC 6749 OAuth 2.0 October 2012
The "scope" element is defined in Section 3.3:
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
The "state" element is defined in Sections 4.1.1, 4.1.2, 4.1.2.1, 4.2.1, 4.2.2, and 4.2.2.1:
state = 1*VSCHAR
The "redirect_uri" element is defined in Sections 4.1.1, 4.1.3, and 4.2.1:
redirect-uri = URI-reference
The "error" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2, and 8.5:
error = 1*NQSCHAR
The "error_description" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2:
error-description = 1*NQSCHAR
The "error_uri" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2:
error-uri = URI-reference
Hardt Standards Track [Page 72]
RFC 6749 OAuth 2.0 October 2012
The "grant_type" element is defined in Sections 4.1.3, 4.3.2, 4.4.2, 4.5, and 6:
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
The "code" element is defined in Section 4.1.3:
code = 1*VSCHAR
The "access_token" element is defined in Sections 4.2.2 and 5.1:
access-token = 1*VSCHAR
The "token_type" element is defined in Sections 4.2.2, 5.1, and 8.1:
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
The "expires_in" element is defined in Sections 4.2.2 and 5.1:
expires-in = 1*DIGIT
The "username" element is defined in Section 4.3.2:
username = *UNICODECHARNOCRLF
The "password" element is defined in Section 4.3.2:
password = *UNICODECHARNOCRLF
Hardt Standards Track [Page 73]
RFC 6749 OAuth 2.0 October 2012
The "refresh_token" element is defined in Sections 5.1 and 6:
refresh-token = 1*VSCHAR
The syntax for new endpoint parameters is defined in Section 8.2:
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
At the time of publication of this specification, the "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 of [W3C.REC-html401-19991224] but not registered in the IANA MIME Media Types registry (http://www.iana.org/assignments/media-types). Furthermore, that definition is incomplete, as it does not consider non-US-ASCII characters.
To address this shortcoming when generating payloads using this media type, names and values MUST be encoded using the UTF-8 character encoding scheme [RFC3629] first; the resulting octet sequence then needs to be further encoded using the escaping rules defined in [W3C.REC-html401-19991224].
When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the UTF-8 character encoding scheme.
For example, the value consisting of the six Unicode code points
(1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
(3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
(5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded
into the octet sequence below (using hexadecimal notation):
20 25 26 2B C2 A3 E2 82 AC
and then represented in the payload as:
+%25%26%2B%C2%A3%E2%82%AC