```text
Internet Engineering Task Force (IETF) D. Hardt, Ed.
Request for Comments: 6749 Microsoft
Obsoletes: 5849 October 2012
Category: Standards Track
ISSN: 2070-1721
The OAuth 2.0 Authorization Framework
```
---
# **Abstract**
OAuth 2.0 인증 프레임워크를 사용하면 리소스 소유자와 HTTP 서비스 간의 승인 상호 작용을 조정하거나 타사 애플리케이션이 다음을 수행하도록 허용하여 리소스 소유자를 대신하여 타사 애플리케이션이 HTTP 서비스에 대한 제한된 액세스를 얻을 수 있습니다. 자체적으로 액세스 권한을 얻습니다. 이 사양은 RFC 5849에 설명된 OAuth 1.0 프로토콜을 대체하고 더 이상 사용되지 않습니다.
---
# **Status of This Memo**
이것은 인터넷 표준 추적 문서입니다.
이 문서는 IETF\(Internet Engineering Task Force\)의 제품입니다. 이는 IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 받았으며 IESG\(Internet Engineering Steering Group\)의 출판 승인을 받았습니다. 인터넷 표준에 대한 자세한 내용은 RFC 5741의 섹션 2에서 확인할 수 있습니다.
이 문서의 현재 상태, 정오표, 피드백 제공 방법에 대한 정보는 http://www.rfc-editor.org/info/rfc6749에서 얻을 수 있습니다.
---
# **Copyright Notice**
Copyright \(c\) 2012 IETF Trust 및 문서 작성자로 식별된 사람. 판권 소유.
이 문서는 이 문서의 발행일에 유효한 BCP 78 및 IETF 문서에 관한 IETF 트러스트의 법적 조항\(http://trustee.ietf.org/license-info\)의 적용을 받습니다. 이 문서와 관련된 귀하의 권리 및 제한 사항을 설명하므로 이 문서를 주의 깊게 검토하십시오. 이 문서에서 추출한 코드 구성 요소는 Trust Legal Provisions의 섹션 4.e에 설명된 대로 Simplified BSD License 텍스트를 포함해야 하며 Simplified BSD License에 설명된 대로 보증 없이 제공됩니다.
---
# **Table of Contents**
```text
1. Introduction ....................................................4
1.1. Roles ......................................................6
1.2. Protocol Flow ..............................................7
1.3. Authorization Grant ........................................8
1.3.1. Authorization Code ..................................8
1.3.2. Implicit ............................................8
1.3.3. Resource Owner Password Credentials .................9
1.3.4. Client Credentials ..................................9
1.4. Access Token ..............................................10
1.5. Refresh Token .............................................10
1.6. TLS Version ...............................................12
1.7. HTTP Redirections .........................................12
1.8. Interoperability ..........................................12
1.9. Notational Conventions ....................................13
2. Client Registration ............................................13
2.1. Client Types ..............................................14
2.2. Client Identifier .........................................15
2.3. Client Authentication .....................................16
2.3.1. Client Password ....................................16
2.3.2. Other Authentication Methods .......................17
2.4. Unregistered Clients ......................................17
3. Protocol Endpoints .............................................18
3.1. Authorization Endpoint ....................................18
3.1.1. Response Type ......................................19
3.1.2. Redirection Endpoint ...............................19
3.2. Token Endpoint ............................................21
3.2.1. Client Authentication ..............................22
3.3. Access Token Scope ........................................23
4. Obtaining Authorization ........................................23
4.1. Authorization Code Grant ..................................24
4.1.1. Authorization Request ..............................25
4.1.2. Authorization Response .............................26
4.1.3. Access Token Request ...............................29
4.1.4. Access Token Response ..............................30
4.2. Implicit Grant ............................................31
4.2.1. Authorization Request ..............................33
4.2.2. Access Token Response ..............................35
4.3. Resource Owner Password Credentials Grant .................37
4.3.1. Authorization Request and Response .................39
4.3.2. Access Token Request ...............................39
4.3.3. Access Token Response ..............................40
4.4. Client Credentials Grant ..................................40
4.4.1. Authorization Request and Response .................41
4.4.2. Access Token Request ...............................41
4.4.3. Access Token Response ..............................42
4.5. Extension Grants ..........................................42
5. Issuing an Access Token ........................................43
5.1. Successful Response .......................................43
5.2. Error Response ............................................45
6. Refreshing an Access Token .....................................47
7. Accessing Protected Resources ..................................48
7.1. Access Token Types ........................................49
7.2. Error Response ............................................49
8. Extensibility ..................................................50
8.1. Defining Access Token Types ...............................50
8.2. Defining New Endpoint Parameters ..........................50
8.3. Defining New Authorization Grant Types ....................51
8.4. Defining New Authorization Endpoint Response Types ........51
8.5. Defining Additional Error Codes ...........................51
9. Native Applications ............................................52
10. Security Considerations .......................................53
10.1. Client Authentication ....................................53
10.2. Client Impersonation .....................................54
10.3. Access Tokens ............................................55
10.4. Refresh Tokens ...........................................55
10.5. Authorization Codes ......................................56
10.6. Authorization Code Redirection URI Manipulation ..........56
10.7. Resource Owner Password Credentials ......................57
10.8. Request Confidentiality ..................................58
10.9. Ensuring Endpoint Authenticity ...........................58
10.10. Credentials-Guessing Attacks ............................58
10.11. Phishing Attacks ........................................58
10.12. Cross-Site Request Forgery ..............................59
10.13. Clickjacking ............................................60
10.14. Code Injection and Input Validation .....................60
10.15. Open Redirectors ........................................60
10.16. Misuse of Access Token to Impersonate Resource
Owner in Implicit Flow ..................................61
11. IANA Considerations ...........................................62
11.1. OAuth Access Token Types Registry ........................62
11.1.1. Registration Template .............................62
11.2. OAuth Parameters Registry ................................63
11.2.1. Registration Template .............................63
11.2.2. Initial Registry Contents .........................64
11.3. OAuth Authorization Endpoint Response Types Registry .....66
11.3.1. Registration Template .............................66
11.3.2. Initial Registry Contents .........................67
11.4. OAuth Extensions Error Registry ..........................67
11.4.1. Registration Template .............................68
12. References ....................................................68
12.1. Normative References .....................................68
12.2. Informative References ...................................70
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71
A.1. "client_id" Syntax ........................................71
A.2. "client_secret" Syntax ....................................71
A.3. "response_type" Syntax ....................................71
A.4. "scope" Syntax ............................................72
A.5. "state" Syntax ............................................72
A.6. "redirect_uri" Syntax .....................................72
A.7. "error" Syntax ............................................72
A.8. "error_description" Syntax ................................72
A.9. "error_uri" Syntax ........................................72
A.10. "grant_type" Syntax .......................................73
A.11. "code" Syntax .............................................73
A.12. "access_token" Syntax .....................................73
A.13. "token_type" Syntax .......................................73
A.14. "expires_in" Syntax .......................................73
A.15. "username" Syntax .........................................73
A.16. "password" Syntax .........................................73
A.17. "refresh_token" Syntax ....................................74
A.18. Endpoint Parameter Syntax .................................74
Appendix B. Use of application/x-www-form-urlencoded Media Type ...74
Appendix C. Acknowledgements ......................................75
```
---
## **1. Introduction**
기존 클라이언트-서버 인증 모델에서 클라이언트는 리소스 소유자의 자격 증명을 사용하여 서버에 인증함으로써 서버에 대한 액세스가 제한된 리소스\(보호된 리소스\)를 요청합니다. 제한된 리소스에 대한 제3자 애플리케이션 액세스를 제공하기 위해 리소스 소유자는 자신의 자격 증명을 제3자와 공유합니다. 이로 인해 몇 가지 문제와 제한 사항이 발생합니다.
o 향후 사용을 위해 리소스 소유자의 자격 증명\(일반적으로 일반 텍스트의 비밀번호\)을 저장하려면 타사 애플리케이션이 필요합니다.
o 서버는 비밀번호에 내재된 보안 취약점에도 불구하고 비밀번호 인증을 지원해야 합니다.
o 제3자 응용 프로그램은 리소스 소유자의 보호된 리소스에 대해 지나치게 광범위한 액세스 권한을 얻으므로 리소스 소유자는 기간을 제한하거나 제한된 리소스 하위 집합에 대한 액세스를 제한할 수 없습니다.
o 리소스 소유자는 모든 제3자에 대한 액세스 권한을 취소하지 않고는 개별 제3자에 대한 액세스 권한을 취소할 수 없으며, 제3자의 비밀번호를 변경하여 취소해야 합니다.
o 제3자 애플리케이션이 손상되면 최종 사용자의 비밀번호와 해당 비밀번호로 보호되는 모든 데이터가 손상됩니다.
OAuth는 인증 계층을 도입하고 클라이언트 역할을 리소스 소유자 역할과 분리하여 이러한 문제를 해결합니다. OAuth에서 클라이언트는 리소스 소유자가 제어하고 리소스 서버에서 호스팅하는 리소스에 대한 액세스를 요청하며 리소스 소유자와 다른 자격 증명 집합을 발급받습니다.
클라이언트는 보호된 리소스에 액세스하기 위해 리소스 소유자의 자격 증명을 사용하는 대신 특정 범위, 수명 및 기타 액세스 속성을 나타내는 문자열인 액세스 토큰을 얻습니다. 액세스 토큰은 리소스 소유자의 승인을 받아 인증 서버에 의해 제3자 클라이언트에 발급됩니다. 클라이언트는 액세스 토큰을 사용하여 리소스 서버에서 호스팅하는 보호된 리소스에 액세스합니다.
예를 들어, 최종 사용자\(리소스 소유자\)는 자신의 사용자 이름과 비밀번호를 인쇄 서비스와 공유하지 않고도 사진 공유 서비스\(리소스 서버\)에 저장된 보호된 사진에 대한 액세스 권한을 인쇄 서비스\(클라이언트\)에 부여할 수 있습니다. 대신 그녀는 인쇄 서비스 위임 관련 자격 증명\(액세스 토큰\)을 발급하는 사진 공유 서비스\(인증 서버\)에서 신뢰하는 서버에 직접 인증합니다.
이 사양은 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에 익숙한 구현자는 구조 및 세부 사항에 대한 어떠한 가정도 없이 이 문서에 접근해야 합니다.
---
### **1.1. Roles**
```text
OAuth defines four roles:
```
자원 소유자
- 보호되는 자원에 대한 접근 권한을 부여할 수 있는 개체입니다. 리소스 소유자가 사람인 경우 이를 최종 사용자라고 합니다.
리소스 서버
- 액세스 토큰을 사용하여 보호된 리소스 요청을 수락하고 응답할 수 있는 보호된 리소스를 호스팅하는 서버입니다.
고객
- 리소스 소유자를 대신하여 권한을 부여받아 보호된 리소스를 요청하는 애플리케이션입니다. "클라이언트"라는 용어는 특정 구현 특성\(예: 응용 프로그램이 서버, 데스크톱 또는 기타 장치에서 실행되는지 여부\)을 의미하지 않습니다.
인증 서버
- 서버는 리소스 소유자를 성공적으로 인증하고 권한을 얻은 후 클라이언트에 액세스 토큰을 발급합니다.
인증 서버와 리소스 서버 간의 상호 작용은 이 사양의 범위를 벗어납니다. 인증 서버는 리소스 서버와 동일한 서버일 수도 있고 별도의 개체일 수도 있습니다. 단일 인증 서버는 여러 리소스 서버에서 허용하는 액세스 토큰을 발급할 수 있습니다.
---
### **1.2. Protocol Flow**
```text
+--------+ +---------------+
| |--(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\) 클라이언트는 권한 부여를 받습니다.
- 본 사양에 정의된 4가지 승인 유형 중 하나를 사용하거나 확장 승인 유형을 사용하여 표현되는 리소스 소유자의 권한을 나타내는 자격 증명입니다. 권한 부여 유형은 클라이언트가 권한 부여를 요청하는 데 사용하는 방법과 권한 부여 서버에서 지원하는 유형에 따라 다릅니다.
\(C\) 클라이언트는 권한 부여 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청합니다.
\(D\) 인증 서버는 클라이언트를 인증하고 인증 부여를 검증하고 유효한 경우 액세스 토큰을 발급합니다.
\(E\) 클라이언트는 리소스 서버에 보호되는 리소스를 요청하고 액세스 토큰을 제시하여 인증합니다.
\(F\) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 요청을 처리합니다.
클라이언트가 리소스 소유자로부터 권한 부여를 얻기 위해 선호하는 방법\(단계 \(A\) 및 \(B\)에 설명\)은 권한 부여 서버를 중개자로 사용하는 것입니다. 이는 섹션 4.1의 그림 3에 설명되어 있습니다.
---
### **1.3. Authorization Grant**
권한 부여는 클라이언트가 액세스 토큰을 얻기 위해 사용하는 리소스 소유자의 권한 부여\(보호된 리소스에 액세스하기 위한\)를 나타내는 자격 증명입니다. 이 사양은 인증 코드, 암시적, 리소스 소유자 비밀번호 자격 증명, 클라이언트 자격 증명 등 네 가지 권한 부여 유형과 추가 유형을 정의하기 위한 확장성 메커니즘을 정의합니다.
---
#### **1.3.1. Authorization Code**
인증 코드는 클라이언트와 리소스 소유자 사이의 중개자로서 인증 서버를 사용하여 얻습니다. 리소스 소유자에게 직접 권한 부여를 요청하는 대신 클라이언트는 리소스 소유자를 권한 부여 서버\(\[RFC2616\]에 정의된 사용자 에이전트를 통해\)로 안내하고, 이는 다시 리소스 소유자를 권한 부여 코드를 사용하여 클라이언트로 다시 안내합니다.
권한 부여 코드를 사용하여 리소스 소유자를 클라이언트로 다시 보내기 전에 권한 부여 서버는 리소스 소유자를 인증하고 권한을 얻습니다. 리소스 소유자는 권한 부여 서버로만 인증하기 때문에 리소스 소유자의 자격 증명은 클라이언트와 공유되지 않습니다.
인증 코드는 클라이언트를 인증하는 기능, 리소스 소유자의 사용자 에이전트를 통과하지 않고 액세스 토큰을 클라이언트에 직접 전송하는 기능, 잠재적으로 다른 사람에게 노출하는 기능 등 몇 가지 중요한 보안 이점을 제공합니다. 자원 소유자.
---
#### **1.3.2. Implicit**
암시적 승인은 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현된 클라이언트에 최적화된 단순화된 인증 코드 흐름입니다. 암시적 흐름에서는 클라이언트에 인증 코드를 발급하는 대신 클라이언트가 직접 액세스 토큰을 발급합니다.
\(리소스 소유자 권한 부여의 결과\) 인증 코드와 같은 중간 자격 증명이 발급되지 않고 나중에 액세스 토큰을 얻는 데 사용되므로 부여 유형은 암시적입니다.
암시적 승인 흐름 중에 액세스 토큰을 발급할 때 권한 부여 서버는 클라이언트를 인증하지 않습니다. 경우에 따라 클라이언트에 액세스 토큰을 전달하는 데 사용되는 리디렉션 URI를 통해 클라이언트 ID를 확인할 수 있습니다. 액세스 토큰은 리소스 소유자 또는 리소스 소유자의 사용자 에이전트에 액세스할 수 있는 다른 애플리케이션에 노출될 수 있습니다.
암시적 권한 부여는 액세스 토큰을 얻는 데 필요한 왕복 횟수를 줄여 일부 클라이언트\(예: 브라우저 내 애플리케이션으로 구현된 클라이언트\)의 응답성과 효율성을 향상시킵니다. 그러나 이러한 편리함은 특히 인증 코드 부여 유형을 사용할 수 있는 경우 섹션 10.3 및 10.16에 설명된 것과 같은 암시적 부여 사용의 보안 영향과 비교하여 평가되어야 합니다.
---
#### **1.3.3. Resource Owner Password Credentials**
리소스 소유자 비밀번호 자격 증명\(예: 사용자 이름 및 비밀번호\)은 액세스 토큰을 얻기 위한 권한 부여로 직접 사용될 수 있습니다. 자격 증명은 리소스 소유자와 클라이언트 사이에 높은 수준의 신뢰가 있고\(예: 클라이언트가 장치 운영 체제의 일부이거나 권한이 높은 응용 프로그램인 경우\) 다른 권한 부여 유형을 사용할 수 없는 경우에만 사용해야 합니다\( 인증 코드 등\).
이 부여 유형에는 리소스 소유자 자격 증명에 대한 클라이언트의 직접적인 액세스가 필요하지만 리소스 소유자 자격 증명은 단일 요청에 사용되며 액세스 토큰으로 교환됩니다. 이 부여 유형은 자격 증명을 수명이 긴 액세스 토큰 또는 새로 고침 토큰과 교환함으로써 나중에 사용할 수 있도록 클라이언트가 리소스 소유자 자격 증명을 저장할 필요가 없도록 해줍니다.
---
#### **1.3.4. Client Credentials**
클라이언트 자격 증명\(또는 다른 형태의 클라이언트 인증\)은 권한 부여 범위가 클라이언트의 제어 하에 있는 보호 리소스로 제한되거나 사전에 권한 부여 서버와 함께 정렬된 보호 리소스로 제한되는 경우 권한 부여로 사용될 수 있습니다. 클라이언트 자격 증명은 일반적으로 클라이언트가 자신을 대신하여 작업하거나\(클라이언트가 리소스 소유자이기도 함\) 권한 부여 서버와 사전에 합의된 권한 부여를 기반으로 보호된 리소스에 대한 액세스를 요청할 때 권한 부여로 사용됩니다.
---
### **1.4. Access Token**
액세스 토큰은 보호된 리소스에 액세스하는 데 사용되는 자격 증명입니다. 액세스 토큰은 클라이언트에 발급된 인증을 나타내는 문자열입니다. 문자열은 일반적으로 클라이언트에게 불투명합니다. 토큰은 리소스 소유자가 부여하고 리소스 서버 및 인증 서버에서 시행하는 특정 액세스 범위와 기간을 나타냅니다.
토큰은 인증 정보를 검색하는 데 사용되는 식별자를 의미하거나 검증 가능한 방식으로 인증 정보를 자체적으로 포함할 수 있습니다\(즉, 일부 데이터와 서명으로 구성된 토큰 문자열\). 클라이언트가 토큰을 사용하려면 이 사양의 범위를 벗어나는 추가 인증 자격 증명이 필요할 수 있습니다.
액세스 토큰은 추상화 계층을 제공하여 다양한 인증 구성\(예: 사용자 이름 및 비밀번호\)을 리소스 서버가 이해하는 단일 토큰으로 대체합니다. 이러한 추상화를 통해 액세스 토큰을 획득하는 데 사용되는 권한 부여보다 더 제한적인 액세스 토큰을 발급할 수 있을 뿐만 아니라 리소스 서버가 광범위한 인증 방법을 이해해야 할 필요성도 제거됩니다.
액세스 토큰은 리소스 서버 보안 요구 사항에 따라 다양한 형식, 구조 및 활용 방법\(예: 암호화 속성\)을 가질 수 있습니다. 보호된 리소스에 액세스하는 데 사용되는 액세스 토큰 속성 및 방법은 이 사양의 범위를 벗어나며 \[RFC6750\]과 같은 동반 사양에 의해 정의됩니다.
---
### **1.5. Refresh Token**
새로 고침 토큰은 액세스 토큰을 얻는 데 사용되는 자격 증명입니다. 새로 고침 토큰은 권한 부여 서버에 의해 클라이언트에 발급되며 현재 액세스 토큰이 유효하지 않거나 만료될 때 새 액세스 토큰을 얻거나 동일하거나 더 좁은 범위의 추가 액세스 토큰을 얻는 데 사용됩니다\(액세스 토큰의 수명은 더 짧을 수 있으며 리소스 소유자가 승인한 권한보다 적은 권한\) 새로 고침 토큰 발행은 인증 서버의 재량에 따라 선택 사항입니다. Authorization Server가 Refresh Token을 발급하면 Access Token 발급 시 포함됩니다\(예: 그림 1의 \(D\) 단계\).
새로 고침 토큰은 리소스 소유자가 클라이언트에 부여한 권한을 나타내는 문자열입니다. 문자열은 일반적으로 클라이언트에게 불투명합니다. 토큰은 데이터를 검색하는 데 사용되는 식별자를 나타냅니다.
승인 정보. 액세스 토큰과 달리 새로 고침 토큰은 인증 서버에서만 사용하도록 고안되었으며 리소스 서버로 전송되지 않습니다.
```text
+--------+ +---------------+
| |--(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 +---------------+
```
- 그림 2: 만료된 액세스 토큰 새로 고침
그림 2에 표시된 흐름에는 다음 단계가 포함됩니다.
\(A\) 클라이언트는 권한 부여 서버로 인증하고 권한 부여를 제시하여 액세스 토큰을 요청합니다.
\(B\) 권한 부여 서버는 클라이언트를 인증하고 권한 부여를 검증하고 유효한 경우 액세스 토큰과 새로 고침 토큰을 발급합니다.
\(C\) 클라이언트는 액세스 토큰을 제시하여 리소스 서버에 보호된 리소스를 요청합니다.
\(D\) 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 요청을 처리합니다.
\(E\) 액세스 토큰이 만료될 때까지 \(C\) 및 \(D\) 단계를 반복합니다. 클라이언트가 액세스 토큰이 만료되었음을 알면 단계 \(G\)로 건너뜁니다. 그렇지 않으면 또 다른 보호된 리소스를 요청합니다.
\(F\) 액세스 토큰이 유효하지 않기 때문에 리소스 서버는 유효하지 않은 토큰 오류를 반환합니다.
\(G\) 클라이언트는 권한 부여 서버로 인증하고 새로 고침 토큰을 제시하여 새로운 액세스 토큰을 요청합니다. 클라이언트 인증 요구 사항은 클라이언트 유형과 권한 부여 서버 정책을 기반으로 합니다.
\(H\) 권한 부여 서버는 클라이언트를 인증하고 새로 고침 토큰의 유효성을 검사하고 유효한 경우 새 액세스 토큰\(및 선택적으로 새 새로 고침 토큰\)을 발급합니다.
섹션 7에 설명된 대로 단계 \(C\), \(D\), \(E\) 및 \(F\)는 이 사양의 범위를 벗어납니다.
---
### **1.6. TLS Version**
이 사양에서 TLS\(전송 계층 보안\)를 사용할 때마다 적절한 TLS 버전은 광범위한 배포 및 알려진 보안 취약성을 기반으로 시간이 지남에 따라 달라집니다. 이 글을 쓰는 시점에서는 TLS 버전 1.2 \[RFC5246\]가 최신 버전이지만 배포 기반이 매우 제한되어 있어 쉽게 구현하지 못할 수도 있습니다. TLS 버전 1.0 \[RFC2246\]은 가장 널리 배포된 버전이며 가장 광범위한 상호 운용성을 제공합니다.
구현은 보안 요구 사항을 충족하는 추가 전송 계층 보안 메커니즘을 지원할 수도 있습니다.\(MAY\)
---
### **1.7. HTTP Redirections**
이 사양에서는 클라이언트 또는 인증 서버가 리소스 소유자의 사용자 에이전트를 다른 대상으로 보내는 HTTP 리디렉션을 광범위하게 사용합니다. 이 사양의 예에서는 HTTP 302 상태 코드의 사용을 보여주지만, 이 리디렉션을 수행하기 위해 사용자 에이전트를 통해 사용할 수 있는 다른 방법은 허용되며 구현 세부 사항으로 간주됩니다.
---
### **1.8. Interoperability**
OAuth 2.0은 잘 정의된 보안 속성을 갖춘 풍부한 인증 프레임워크를 제공합니다. 그러나 많은 선택적 구성 요소를 포함하는 풍부하고 확장성이 뛰어난 프레임워크로서 이 사양은 그 자체로 상호 운용할 수 없는 광범위한 구현을 생성할 가능성이 높습니다.
또한 이 사양에서는 몇 가지 필수 구성 요소를 부분적으로 또는 완전히 정의되지 않은 상태로 둡니다\(예: 클라이언트 등록, 인증 서버 기능, 엔드포인트 검색\). 없이
이러한 구성 요소가 상호 운용되려면 클라이언트를 특정 인증 서버 및 리소스 서버에 대해 수동으로 구체적으로 구성해야 합니다.
이 프레임워크는 향후 작업이 완전한 웹 규모 상호 운용성을 달성하는 데 필요한 규정적 프로필과 확장을 정의할 것이라는 명확한 기대를 바탕으로 설계되었습니다.
---
### **1.9. Notational Conventions**
본 사양의 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 및 "OPTIONAL"은 다음과 같습니다. \[RFC2119\]에 설명된 대로 해석됩니다.\(MUST NOT\)
이 사양은 \[RFC5234\]의 ABNF\(Augmented Backus-Naur Form\) 표기법을 사용합니다. 또한 규칙 URI 참조는 "URI\(Uniform Resource Identifier\): 일반 구문" \[RFC3986\]에 포함되어 있습니다.
특정 보안 관련 용어는 \[RFC4949\]에 정의된 의미로 이해되어야 합니다. 이러한 용어에는 "공격", "인증", "허가", "인증서", "기밀성", "자격 증명", "암호화", "신원", "서명", "서명", "신뢰하다", "검증하다", "확인하다".
달리 명시하지 않는 한 모든 프로토콜 매개변수 이름과 값은 대소문자를 구분합니다.
---
## **2. Client Registration**
프로토콜을 시작하기 전에 클라이언트는 인증 서버에 등록합니다. 클라이언트가 인증 서버에 등록하는 방법은 이 사양의 범위를 벗어나지만 일반적으로 HTML 등록 양식과 최종 사용자의 상호 작용이 포함됩니다.
클라이언트 등록에는 클라이언트와 인증 서버 간의 직접적인 상호 작용이 필요하지 않습니다. 권한 부여 서버에서 지원하는 경우 등록은 신뢰를 설정하고 필요한 클라이언트 속성\(예: 리디렉션 URI, 클라이언트 유형\)을 얻기 위한 다른 수단을 사용할 수 있습니다. 예를 들어 등록은 자체 발행 또는 제3자 발행 어설션을 사용하거나 신뢰할 수 있는 채널을 사용하여 클라이언트 검색을 수행하는 인증 서버를 통해 수행될 수 있습니다.
클라이언트를 등록할 때 클라이언트 개발자는 다음을 수행해야 합니다.\(MUST\)
o 섹션 2.1에 설명된 대로 클라이언트 유형을 지정합니다.
o 섹션 3.1.2에 설명된 대로 클라이언트 리디렉션 URI를 제공합니다.
o 인증 서버에서 요구하는 기타 정보\(예: 애플리케이션 이름, 웹사이트, 설명, 로고 이미지, 법적 조건 동의\)를 포함합니다.
---
### **2.1. Client Types**
OAuth는 인증 서버를 통해 안전하게 인증하는 능력\(즉, 클라이언트 자격 증명의 기밀성을 유지하는 능력\)을 기반으로 두 가지 클라이언트 유형을 정의합니다.
비밀의
- 자격 증명의 기밀성을 유지할 수 있는 클라이언트\(예: 클라이언트 자격 증명에 대한 액세스가 제한된 보안 서버에 구현된 클라이언트\) 또는 다른 수단을 사용하여 보안 클라이언트 인증이 가능한 클라이언트.
공공의
- 자격 증명의 기밀성을 유지할 수 없는 클라이언트\(예: 설치된 기본 애플리케이션 또는 웹 브라우저 기반 애플리케이션과 같이 리소스 소유자가 사용하는 장치에서 실행되는 클라이언트\) 및 다른 수단을 통해 안전한 클라이언트 인증이 불가능한 클라이언트.
클라이언트 유형 지정은 권한 부여 서버의 보안 인증 정의와 클라이언트 자격 증명의 허용 가능한 노출 수준을 기반으로 합니다. 인증 서버는 클라이언트 유형에 대해 가정을 해서는 안 됩니다.\(SHOULD NOT\)
클라이언트는 각각 다른 클라이언트 유형과 보안 컨텍스트를 갖는 분산된 구성 요소 집합으로 구현될 수 있습니다\(예: 기밀 서버 기반 구성 요소와 공개 브라우저 기반 구성 요소를 모두 갖춘 분산 클라이언트\). 인증 서버가 그러한 클라이언트에 대한 지원을 제공하지 않거나 등록과 관련된 지침을 제공하지 않는 경우 클라이언트는 각 구성 요소를 별도의 클라이언트로 등록해야 합니다.\(SHOULD\)
이 사양은 다음 클라이언트 프로필을 중심으로 설계되었습니다.
웹 애플리케이션
- 웹 애플리케이션은 웹 서버에서 실행되는 기밀 클라이언트입니다. 리소스 소유자는 리소스 소유자가 사용하는 장치의 사용자 에이전트에서 렌더링된 HTML 사용자 인터페이스를 통해 클라이언트에 액세스합니다. 클라이언트 자격 증명과 클라이언트에 발급된 모든 액세스 토큰은 웹 서버에 저장되며 리소스 소유자에게 노출되거나 액세스할 수 없습니다.
사용자 에이전트 기반 애플리케이션
- 사용자 에이전트 기반 애플리케이션은 클라이언트 코드가 웹 서버에서 다운로드되어 리소스 소유자가 사용하는 장치의 사용자 에이전트\(예: 웹 브라우저\) 내에서 실행되는 공개 클라이언트입니다. 프로토콜 데이터 및 자격 증명은 리소스 소유자가 쉽게 액세스할 수 있고 종종 볼 수 있습니다. 이러한 애플리케이션은 사용자 에이전트 내에 상주하므로 인증을 요청할 때 사용자 에이전트 기능을 원활하게 사용할 수 있습니다.
기본 애플리케이션
- 네이티브 애플리케이션은 리소스 소유자가 사용하는 디바이스에 설치되어 실행되는 공용 클라이언트입니다. 프로토콜 데이터 및 자격 증명은 리소스 소유자가 액세스할 수 있습니다. 애플리케이션에 포함된 모든 클라이언트 인증 자격 증명을 추출할 수 있다고 가정합니다. 반면에 액세스 토큰이나 새로 고침 토큰과 같이 동적으로 발급된 자격 증명은 허용 가능한 수준의 보호를 받을 수 있습니다. 최소한 이러한 자격 증명은 애플리케이션이 상호 작용할 수 있는 적대적인 서버로부터 보호됩니다. 일부 플랫폼에서는 이러한 자격 증명이 동일한 장치에 있는 다른 애플리케이션으로부터 보호될 수 있습니다.
---
### **2.2. Client Identifier**
인증 서버는 등록된 클라이언트에 클라이언트 식별자\(클라이언트가 제공한 등록 정보를 나타내는 고유 문자열\)를 발급합니다. 클라이언트 식별자는 비밀이 아닙니다. 이는 리소스 소유자에게 노출되며 클라이언트 인증을 위해 단독으로 사용되어서는 안 됩니다. 클라이언트 식별자는 인증 서버에 고유합니다.\(MUST NOT\)
클라이언트 식별자 문자열 크기는 이 사양에 의해 정의되지 않은 상태로 남아 있습니다. 클라이언트는 식별자 크기에 대한 가정을 피해야 합니다. 인증 서버는 발행하는 모든 식별자의 크기를 문서화해야 합니다.\(SHOULD\)
---
### **2.3. Client Authentication**
클라이언트 유형이 기밀인 경우 클라이언트와 권한 부여 서버는 권한 부여 서버의 보안 요구 사항에 적합한 클라이언트 인증 방법을 설정합니다. 인증 서버는 보안 요구 사항을 충족하는 모든 형태의 클라이언트 인증을 허용할 수 있습니다.\(MAY\)
기밀 클라이언트는 일반적으로 인증 서버 인증에 사용되는 클라이언트 자격 증명 세트\(예: 비밀번호, 공개/개인 키 쌍\)를 발급\(또는 설정\)합니다.
인증 서버는 공개 클라이언트를 사용하여 클라이언트 인증 방법을 설정할 수 있습니다. 그러나 인증 서버는 클라이언트를 식별할 목적으로 공개 클라이언트 인증에 의존해서는 안 됩니다.\(MAY, MUST NOT\)
클라이언트는 각 요청에서 둘 이상의 인증 방법을 사용해서는 안 됩니다.\(MUST NOT\)
---
#### **2.3.1. Client Password**
클라이언트 비밀번호를 소유한 클라이언트는 \[RFC2617\]에 정의된 HTTP 기본 인증 체계를 사용하여 인증 서버에 인증할 수 있습니다. 클라이언트 식별자는 부록 B에 따라 "application/x-www-form-urlencoded" 인코딩 알고리즘을 사용하여 인코딩되며 인코딩된 값은 사용자 이름으로 사용됩니다. 클라이언트 비밀번호는 동일한 알고리즘을 사용하여 인코딩되어 비밀번호로 사용됩니다. 인증 서버는 클라이언트 비밀번호가 발급된 클라이언트를 인증하기 위해 HTTP 기본 인증 체계를 지원해야 합니다.\(MAY, MUST\)
예를 들어\(표시 목적으로만 추가 줄 바꿈 사용\):
```text
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
```
또는 인증 서버는 다음 매개변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함하도록 지원할 수 있습니다.\(MAY\)
클라이언트\_ID
- 필수의. 섹션 2.2에 설명된 등록 프로세스 중에 클라이언트에게 발급된 클라이언트 식별자입니다.\(MUST\)
클라이언트\_비밀
- 필수의. 클라이언트 비밀입니다. 클라이언트 비밀번호가 빈 문자열인 경우 클라이언트는 매개변수를 생략할 수 있습니다.\(MUST, MAY\)
두 매개변수를 사용하여 요청 본문에 클라이언트 자격 증명을 포함시키는 것은 권장되지 않으며 HTTP 기본 인증 체계\(또는 기타 비밀번호 기반 HTTP 인증 체계\)를 직접 활용할 수 없는 클라이언트로 제한되어야 합니다. 매개변수는 요청 본문에서만 전송될 수 있으며 요청 URI에 포함되어서는 안 됩니다.\(SHOULD NOT, MUST NOT\)
예를 들어 본문 매개변수를 사용하여 액세스 토큰\(섹션 6\)을 새로 고치는 요청은 다음과 같습니다\(표시 목적으로만 추가 줄 바꿈 사용\).
```text
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
```
인증 서버는 비밀번호 인증을 사용하여 요청을 보낼 때 섹션 1.6에 설명된 대로 TLS 사용을 요구해야 합니다.\(MUST\)
이 클라이언트 인증 방법에는 비밀번호가 포함되므로 인증 서버는 이를 사용하는 모든 엔드포인트를 무차별 대입 공격으로부터 보호해야 합니다.\(MUST\)
---
#### **2.3.2. Other Authentication Methods**
인증 서버는 보안 요구 사항과 일치하는 적절한 HTTP 인증 체계를 지원할 수 있습니다. 다른 인증 방법을 사용할 때 인증 서버는 클라이언트 식별자\(등록 기록\)와 인증 체계 간의 매핑을 정의해야 합니다.\(MAY, MUST\)
---
### **2.4. Unregistered Clients**
이 사양은 등록되지 않은 클라이언트의 사용을 배제하지 않습니다. 그러나 그러한 클라이언트의 사용은 이 사양의 범위를 벗어나며 상호 운용성 영향에 대한 추가 보안 분석 및 검토가 필요합니다.
---
## **3. Protocol Endpoints**
인증 프로세스에서는 두 개의 인증 서버 엔드포인트\(HTTP 리소스\)를 활용합니다.
o 권한 부여 끝점 - 클라이언트가 권한 부여 끝점을 얻기 위해 사용합니다.
- 사용자 에이전트 리디렉션을 통해 리소스 소유자로부터 승인을 받습니다.
o 토큰 끝점 - 클라이언트가 일반적으로 클라이언트 인증을 통해 액세스 토큰에 대한 권한 부여를 교환하는 데 사용됩니다.
또한 하나의 클라이언트 엔드포인트는 다음과 같습니다.
o 리디렉션 끝점 - 권한 부여 서버가 리소스 소유자 사용자 에이전트를 통해 클라이언트에 권한 부여 자격 증명이 포함된 응답을 반환하는 데 사용됩니다.
모든 권한 부여 유형이 두 끝점을 모두 활용하는 것은 아닙니다. 확장 권한 부여 유형은 필요에 따라 추가 엔드포인트를 정의할 수 있습니다.\(MAY\)
---
### **3.1. Authorization Endpoint**
권한 부여 끝점은 리소스 소유자와 상호 작용하고 권한 부여를 얻는 데 사용됩니다. 인증 서버는 먼저 리소스 소유자의 신원을 확인해야 합니다. 인증 서버가 리소스 소유자\(예: 사용자 이름 및 비밀번호 로그인, 세션 쿠키\)를 인증하는 방식은 이 사양의 범위를 벗어납니다.\(MUST\)
클라이언트가 권한 부여 끝점의 위치를 얻는 방법은 이 사양의 범위를 벗어나지만 위치는 일반적으로 서비스 문서에 제공됩니다.
엔드포인트 URI에는 \(부록 B에 따라\) 형식의 "application/x-www-form-urlencoded" 쿼리 구성 요소\(\[RFC3986\] 섹션 3.4\)가 포함될 수 있으며, 이는 추가 쿼리 매개 변수를 추가할 때 반드시 유지되어야 합니다. 엔드포인트 URI에는 조각 구성 요소가 포함되어서는 안 됩니다.\(MUST, MUST NOT\)
권한 부여 끝점에 대한 요청은 사용자 인증 및 일반 텍스트 자격 증명\(HTTP 응답에서\) 전송으로 이어지므로, 권한 부여 서버는 권한 부여 끝점에 요청을 보낼 때 섹션 1.6에 설명된 대로 TLS 사용을 요구해야 합니다.\(MUST\)
인증 서버는 인증 엔드포인트에 대해 HTTP "GET" 메소드 \[RFC2616\]의 사용을 지원해야 하며 "POST" 메소드의 사용도 지원할 수 있습니다.\(MUST\)
값 없이 전송된 매개변수는 요청에서 생략된 것처럼 처리되어야 합니다. 인증 서버는 인식되지 않은 요청 매개변수를 무시해야 합니다. 요청 및 응답 매개변수는 두 번 이상 포함되어서는 안 됩니다.\(MUST, MUST, MUST NOT\)
---
#### **3.1.1. Response Type**
권한 부여 끝점은 권한 부여 코드 부여 유형 및 암시적 부여 유형 흐름에서 사용됩니다. 클라이언트는 다음 매개변수를 사용하여 원하는 승인 유형을 인증 서버에 알립니다.
응답\_유형
- 필수의. 값은 섹션 4.1.1에 설명된 인증 코드를 요청하기 위한 "코드", 섹션 4.2.1에 설명된 액세스 토큰\(암시적 승인\)을 요청하기 위한 "토큰" 또는 등록된 확장 값 중 하나여야 합니다. 섹션 8.4.\(MUST, MUST\)
확장 응답 유형은 공백으로 구분된\(%x20\) 값 목록을 포함할 수 있으며, 여기서 값의 순서는 중요하지 않습니다\(예: 응답 유형 "a b"는 "ba a"와 동일함\). 이러한 복합 응답 유형의 의미는 해당 사양에 따라 정의됩니다.\(MAY\)
인증 요청에 "response\_type" 매개변수가 누락되거나 응답 유형이 이해되지 않는 경우 인증 서버는 섹션 4.1.2.1에 설명된 대로 오류 응답을 반환해야 합니다.\(MUST\)
---
#### **3.1.2. Redirection Endpoint**
리소스 소유자와의 상호 작용을 완료한 후 권한 부여 서버는 리소스 소유자의 사용자 에이전트를 다시 클라이언트로 보냅니다. 인증 서버는 클라이언트 등록 과정이나 인증 요청 시 인증 서버를 통해 이전에 설정된 클라이언트의 리디렉션 엔드포인트로 사용자 에이전트를 리디렉션합니다.
리디렉션 끝점 URI는 \[RFC3986\] 섹션 4.3에 정의된 절대 URI여야 합니다. 엔드포인트 URI에는 \(부록 B에 따라\) 형식의 "application/x-www-form-urlencoded" 쿼리 구성 요소\(\[RFC3986\] 섹션 3.4\)가 포함될 수 있으며, 이는 추가 쿼리 매개 변수를 추가할 때 반드시 유지되어야 합니다. 엔드포인트 URI에는 조각 구성 요소가 포함되어서는 안 됩니다.\(MUST, MUST, MUST NOT\)
---
##### **3.1.2.1. Endpoint Request Confidentiality**
리디렉션 끝점은 요청된 응답 유형이 "코드" 또는 "토큰"일 때 또는 리디렉션 요청으로 인해 개방형 네트워크를 통해 민감한 자격 증명이 전송될 때 섹션 1.6에 설명된 대로 TLS를 사용해야 합니다\(SHOULD\). 이 문서를 작성하는 시점에는 클라이언트에 TLS 배포를 요구하는 것이 많은 클라이언트 개발자에게 큰 장애물이기 때문에 이 사양에서는 TLS 사용을 의무화하지 않습니다. TLS를 사용할 수 없는 경우 인증 서버는 리디렉션 전에 안전하지 않은 엔드포인트에 대해 리소스 소유자에게 경고해야 합니다\(예: 인증 요청 중에 메시지 표시\).\(SHOULD, SHOULD\)
전송 계층 보안이 부족하면 클라이언트 보안과 액세스 권한이 부여된 보호 리소스에 심각한 영향을 미칠 수 있습니다. 전송 계층 보안의 사용은 권한 부여 프로세스가 클라이언트\(예: 제3자 로그인 서비스\)에 의해 위임된 최종 사용자 인증의 한 형태로 사용될 때 특히 중요합니다.
---
##### **3.1.2.2. Registration Requirements**
인증 서버는 리디렉션 끝점을 등록하기 위해 다음 클라이언트를 요구해야 합니다.\(MUST\)
```text
o Public clients.
```
o 암시적 부여 유형을 활용하는 기밀 클라이언트.
인증 서버는 모든 클라이언트가 인증 엔드포인트를 활용하기 전에 리디렉션 엔드포인트를 등록하도록 요구해야 합니다\(SHOULD\).\(SHOULD\)
인증 서버는 클라이언트에게 완전한 리디렉션 URI를 제공하도록 요구해야 합니다\(SHOULD\). 클라이언트는 요청별 사용자 정의를 달성하기 위해 "상태" 요청 매개변수를 사용할 수 있습니다. 전체 리디렉션 URI의 등록을 요구하는 것이 가능하지 않은 경우 인증 서버는 URI 체계, 권한 및 경로의 등록을 요구해야 합니다\(클라이언트가 인증을 요청할 때 리디렉션 URI의 쿼리 구성 요소만 동적으로 변경할 수 있도록 허용\).\(SHOULD, SHOULD\)
인증 서버는 클라이언트가 여러 리디렉션 끝점을 등록하도록 허용할 수 있습니다.\(MAY\)
리디렉션 URI 등록 요구 사항이 없으면 공격자가 섹션 10.15에 설명된 대로 인증 끝점을 개방형 리디렉션으로 사용할 수 있습니다.
---
##### **3.1.2.3. Dynamic Configuration**
여러 리디렉션 URI가 등록되었거나 리디렉션 URI의 일부만 등록되었거나 리디렉션 URI가 등록되지 않은 경우 클라이언트는 "redirect\_uri" 요청 매개변수를 사용하여 인증 요청에 리디렉션 URI를 포함해야 합니다.\(MUST\)
리디렉션 URI가 인증 요청에 포함된 경우, 인증 서버는 리디렉션 URI가 등록된 경우 \[RFC3986\] 섹션 6에 정의된 등록된 리디렉션 URI\(또는 URI 구성 요소\) 중 적어도 하나와 수신된 값을 비교하고 일치해야 합니다. . 클라이언트 등록에 전체 리디렉션 URI가 포함된 경우 인증 서버는 \[RFC3986\] 섹션 6.2.1에 정의된 대로 단순 문자열 비교를 사용하여 두 URI를 비교해야 합니다.\(MUST, MUST\)
---
##### **3.1.2.4. Invalid Endpoint**
누락, 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 인증 요청이 유효성 검사에 실패하는 경우 인증 서버는 리소스 소유자에게 오류를 알려야 하며 사용자 에이전트를 잘못된 리디렉션 URI로 자동으로 리디렉션해서는 안 됩니다.\(MUST NOT\)
---
##### **3.1.2.5. Endpoint Content**
클라이언트 끝점에 대한 리디렉션 요청은 일반적으로 사용자 에이전트에 의해 처리되는 HTML 문서 응답으로 이어집니다. 리디렉션 요청의 결과로 HTML 응답이 직접 제공되는 경우 HTML 문서에 포함된 모든 스크립트는 리디렉션 URI 및 여기에 포함된 자격 증명에 대한 전체 액세스 권한으로 실행됩니다.
클라이언트는 리디렉션 엔드포인트 응답에 제3자 스크립트\(예: 제3자 분석, 소셜 플러그인, 광고 네트워크\)를 포함해서는 안 됩니다. 대신, URI에서 자격 증명을 추출하고 \(URI 또는 다른 곳에서\) 자격 증명을 노출하지 않고 사용자 에이전트를 다른 엔드포인트로 다시 리디렉션해야 합니다. 타사 스크립트가 포함된 경우 클라이언트는 자체 스크립트\(URI에서 자격 증명을 추출하고 제거하는 데 사용됨\)가 먼저 실행되도록 해야 합니다.\(SHOULD NOT, SHOULD, MUST\)
---
### **3.2. Token Endpoint**
토큰 엔드포인트는 클라이언트가 권한 부여 또는 새로 고침 토큰을 제시하여 액세스 토큰을 얻는 데 사용됩니다. 토큰 엔드포인트는 암시적 부여 유형을 제외한 모든 권한 부여와 함께 사용됩니다\(액세스 토큰이 직접 발급되므로\).
클라이언트가 토큰 엔드포인트의 위치를 얻는 방법은 이 사양의 범위를 벗어나지만 위치는 일반적으로 서비스 설명서에 제공됩니다.
엔드포인트 URI에는 \(부록 B에 따라\) 형식의 "application/x-www-form-urlencoded" 쿼리 구성 요소\(\[RFC3986\] 섹션 3.4\)가 포함될 수 있으며, 이는 추가 쿼리 매개 변수를 추가할 때 반드시 유지되어야 합니다. 엔드포인트 URI에는 조각 구성 요소가 포함되어서는 안 됩니다.\(MUST, MUST NOT\)
토큰 끝점에 대한 요청으로 인해 HTTP 요청 및 응답에서 일반 텍스트 자격 증명이 전송되므로 인증 서버는 토큰 끝점에 요청을 보낼 때 섹션 1.6에 설명된 대로 TLS를 사용해야 합니다.\(MUST\)
클라이언트는 액세스 토큰을 요청할 때 HTTP "POST" 메서드를 사용해야 합니다.\(MUST\)
값 없이 전송된 매개변수는 요청에서 생략된 것처럼 처리되어야 합니다. 인증 서버는 인식되지 않은 요청 매개변수를 무시해야 합니다. 요청 및 응답 매개변수는 두 번 이상 포함되어서는 안 됩니다.\(MUST, MUST, MUST NOT\)
---
#### **3.2.1. Client Authentication**
기밀 클라이언트 또는 클라이언트 자격 증명을 발급한 다른 클라이언트는 토큰 끝점에 요청할 때 섹션 2.3에 설명된 대로 권한 부여 서버로 인증해야 합니다. 클라이언트 인증은 다음 용도로 사용됩니다.\(MUST\)
o 새로 고침 토큰과 인증 코드가 발급된 클라이언트에 대한 바인딩을 시행합니다. 인증 코드가 안전하지 않은 채널을 통해 리디렉션 끝점으로 전송되거나 리디렉션 URI가 완전히 등록되지 않은 경우 클라이언트 인증이 중요합니다.
o 클라이언트를 비활성화하거나 자격 증명을 변경하여 손상된 클라이언트를 복구함으로써 공격자가 훔친 새로 고침 토큰을 남용하는 것을 방지합니다. 단일 클라이언트 자격 증명 세트를 변경하는 것이 전체 새로 고침 토큰 세트를 취소하는 것보다 훨씬 빠릅니다.
o 주기적인 자격 증명 교체가 필요한 인증 관리 모범 사례를 구현합니다. 전체 새로 고침 토큰 세트를 교체하는 것은 어려울 수 있지만 단일 클라이언트 자격 증명 세트를 교체하는 것은 훨씬 쉽습니다.
클라이언트는 토큰 끝점에 요청을 보낼 때 자신을 식별하기 위해 "client\_id" 요청 매개변수를 사용할 수 있습니다. 토큰 엔드포인트에 대한 "authorization\_code" "grant\_type" 요청에서 인증되지 않은 클라이언트는 "client\_id"가 다른 클라이언트를 위한 코드를 실수로 수락하는 것을 방지하기 위해 반드시 "client\_id"를 보내야 합니다. 이는 인증 코드 대체로부터 클라이언트를 보호합니다. \(보호된 리소스에 대한 추가 보안을 제공하지 않습니다.\)\(MAY, MUST\)
---
### **3.3. Access Token Scope**
인증 및 토큰 엔드포인트를 통해 클라이언트는 "scope" 요청 매개변수를 사용하여 액세스 요청 범위를 지정할 수 있습니다. 그러면 인증 서버는 "scope" 응답 매개변수를 사용하여 발급된 액세스 토큰의 범위를 클라이언트에 알립니다.
범위 매개변수의 값은 공백으로 구분되고 대소문자를 구분하는 문자열 목록으로 표현됩니다. 문자열은 인증 서버에 의해 정의됩니다. 값에 공백으로 구분된 여러 문자열이 포함된 경우 순서는 중요하지 않으며 각 문자열은 요청된 범위에 추가 액세스 범위를 추가합니다.
```text
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
```
권한 부여 서버는 권한 부여 서버 정책이나 리소스 소유자의 지시에 따라 클라이언트가 요청한 범위를 완전히 또는 부분적으로 무시할 수 있습니다. 발급된 액세스 토큰 범위가 클라이언트가 요청한 범위와 다른 경우 인증 서버는 클라이언트에 부여된 실제 범위를 알리기 위해 "범위" 응답 매개변수를 포함해야 합니다.\(MAY, MUST\)
클라이언트가 권한 부여를 요청할 때 범위 매개변수를 생략하는 경우 권한 부여 서버는 미리 정의된 기본값을 사용하여 요청을 처리하거나 유효하지 않은 범위를 나타내는 요청을 실패해야 합니다. 인증 서버는 범위 요구사항과 기본값\(정의된 경우\)을 문서화해야 합니다.\(MUST, SHOULD\)
---
## **4. Obtaining Authorization**
액세스 토큰을 요청하기 위해 클라이언트는 리소스 소유자로부터 권한을 얻습니다. 권한 부여는 클라이언트가 액세스 토큰을 요청하는 데 사용하는 권한 부여 형식으로 표현됩니다. OAuth는 인증 코드, 암시적, 리소스 소유자 비밀번호 자격 증명, 클라이언트 자격 증명이라는 네 가지 권한 부여 유형을 정의합니다. 또한 추가 승인 유형을 정의하기 위한 확장 메커니즘도 제공합니다.
---
### **4.1. Authorization Code Grant**
인증 코드 부여 유형은 액세스 토큰과 새로 고침 토큰을 모두 얻는 데 사용되며 기밀 클라이언트에 최적화되어 있습니다. 이는 리디렉션 기반 흐름이므로 클라이언트는 리소스 소유자의 사용자 에이전트\(일반적으로 웹 브라우저\)와 상호 작용할 수 있어야 하며 인증 서버에서 들어오는 요청\(리디렉션을 통해\)을 수신할 수 있어야 합니다.
```text
+----------+
| 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)
```
참고: \(A\), \(B\), \(C\) 단계를 설명하는 선은 사용자 에이전트를 통과할 때 두 부분으로 나뉩니다.
```text
Figure 3: Authorization Code Flow
```
그림 3에 표시된 흐름에는 다음 단계가 포함됩니다.
\(A\) 클라이언트는 리소스 소유자의 사용자 에이전트를 인증 끝점으로 지정하여 흐름을 시작합니다. 클라이언트에는 클라이언트 식별자, 요청된 범위, 로컬 상태 및 액세스가 허용\(또는 거부\)되면 권한 부여 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI가 포함됩니다.
\(B\) 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고 리소스 소유자가 클라이언트의 액세스 요청을 승인할지 거부할지 여부를 설정합니다.
\(C\) 리소스 소유자가 액세스 권한을 부여한다고 가정하면 인증 서버는 이전에\(요청에서 또는 클라이언트 등록 중에\) 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 리디렉션 URI에는 클라이언트가 이전에 제공한 인증 코드와 로컬 상태가 포함됩니다.
\(D\) 클라이언트는 이전 단계에서 받은 인증 코드를 포함하여 인증 서버의 토큰 엔드포인트에서 액세스 토큰을 요청합니다. 요청할 때 클라이언트는 권한 부여 서버를 통해 인증합니다. 클라이언트에는 확인을 위한 인증 코드를 얻는 데 사용되는 리디렉션 URI가 포함되어 있습니다.
\(E\) 인증 서버는 클라이언트를 인증하고 인증 코드의 유효성을 검사하며 수신된 리디렉션 URI가 \(C\) 단계에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인합니다. 유효한 경우 인증 서버는 액세스 토큰과 선택적으로 새로 고침 토큰으로 응답합니다.
---
#### **4.1.1. Authorization Request**
클라이언트는 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 인증 끝점 URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 요청 URI를 구성합니다.
응답\_유형
- 필수의. 값은 "코드"로 설정되어야 합니다.\(MUST, MUST\)
클라이언트\_ID
- 필수의. 섹션 2.2에 설명된 클라이언트 식별자입니다.\(MUST\)
리디렉션\_우리
- 선택 사항입니다. 섹션 3.1.2에 설명된 대로.\(MAY\)
범위
- 선택 사항입니다. 섹션 3.3에 설명된 액세스 요청의 범위입니다.\(MAY\)
상태
- 추천합니다. 요청과 콜백 간의 상태를 유지하기 위해 클라이언트가 사용하는 불투명 값입니다. 인증 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션할 때 이 값을 포함합니다. 섹션 10.12에 설명된 대로 사이트 간 요청 위조를 방지하기 위해 매개변수를 사용해야 합니다.\(SHOULD, SHOULD\)
클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 방법을 사용하여 리소스 소유자를 구성된 URI로 안내합니다.
예를 들어, 클라이언트는 사용자 에이전트에게 TLS를 사용하여 다음 HTTP 요청을 생성하도록 지시합니다\(표시 목적으로만 추가 줄 바꿈 사용\).
```text
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로 보냅니다.
---
#### **4.1.2. Authorization Response**
리소스 소유자가 액세스 요청을 승인하면 인증 서버는 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 쿼리 구성 요소에 다음 매개변수를 추가하여 인증 코드를 발급하고 이를 클라이언트에 전달합니다. 부록 B에 따라:
암호
- 필수의. 인증 서버에서 생성된 인증 코드입니다. 인증 코드는 유출 위험을 완화하기 위해 발급된 직후 만료되어야 합니다. 최대 인증 코드 수명은 10분을 권장합니다. 클라이언트는 인증 코드를 사용해서는 안 됩니다.\(MUST, MUST, SHOULD, MUST NOT\)
- 한 번 이상. 인증 코드가 두 번 이상 사용되는 경우 인증 서버는 요청을 거부해야 하며 \(가능한 경우\) 해당 인증 코드를 기반으로 이전에 발행된 모든 토큰을 취소해야 합니다. 인증 코드는 클라이언트 식별자 및 리디렉션 URI에 바인딩됩니다.\(MUST\)
상태
- 클라이언트 인증 요청에 "state" 매개변수가 있는 경우 필수입니다. 클라이언트로부터 받은 정확한 값입니다.\(MUST\)
예를 들어 인증 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.
```text
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
```
클라이언트는 인식할 수 없는 응답 매개변수를 무시해야 합니다. 인증 코드 문자열 크기는 이 사양에 의해 정의되지 않은 상태로 남아 있습니다. 클라이언트는 코드 값 크기에 대한 가정을 피해야 합니다. 인증 서버는 발행하는 모든 값의 크기를 문서화해야 합니다.\(MUST, SHOULD\)
---
##### **4.1.2.1. Error Response**
누락, 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 요청이 실패하거나 클라이언트 식별자가 누락되거나 유효하지 않은 경우 인증 서버는 리소스 소유자에게 오류를 알려야 하며 자동으로 사용자 에이전트를 잘못된 리디렉션으로 리디렉션해서는 안 됩니다. URI.\(MUST NOT\)
리소스 소유자가 액세스 요청을 거부하거나 리디렉션 URI가 누락되거나 유효하지 않은 이유로 요청이 실패한 경우, 권한 부여 서버는 "application/x-"를 사용하여 리디렉션 URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 클라이언트에 알립니다. 부록 B에 따른 www-form-urlencoded" 형식:
오류
- 필수의. 다음 중 단일 ASCII \[USASCII\] 오류 코드:\(MUST\)
잘못된 요청
- 요청에 필수 매개변수가 누락되었거나, 잘못된 매개변수 값이 포함되어 있거나, 매개변수가 두 번 이상 포함되어 있거나, 형식이 잘못되었습니다.
무단\_클라이언트
- 클라이언트는 이 방법을 사용하여 인증 코드를 요청할 권한이 없습니다.
액세스가 거부되었습니다.
- 리소스 소유자 또는 권한 부여 서버가 요청을 거부했습니다.
지원되지 않는\_응답\_유형
- 인증 서버는 이 방법을 사용한 인증 코드 획득을 지원하지 않습니다.
유효하지 않은\_범위
- 요청한 범위가 유효하지 않거나 알 수 없거나 형식이 잘못되었습니다.
서버 오류
- 인증 서버에서 요청을 이행하지 못하게 하는 예상치 못한 상황이 발생했습니다. \(500 내부 서버 오류 HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요합니다.\)
일시적으로\_사용할 수 없음
- 현재 일시적인 과부하 또는 서버 점검으로 인해 인증 서버가 요청을 처리할 수 없습니다. \(503 Service Unavailable HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요합니다.\)
- "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MUST NOT\)
오류\_설명
- 선택 사항입니다. 클라이언트 개발자가 발생한 오류를 이해하는 데 도움이 되는 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII \[USASCII\] 텍스트입니다. "error\_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
error\_uri
- 선택 사항입니다. 오류에 대한 정보가 포함된 사람이 읽을 수 있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error\_uri" 매개변수의 값은 URI 참조 구문을 준수해야 하며 따라서 %x21 / %x23-5B / %x5D-7E 집합 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
상태
- 클라이언트 인증 요청에 "상태" 매개변수가 있는 경우 필수입니다. 클라이언트로부터 받은 정확한 값입니다.\(MUST\)
예를 들어 인증 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.
```text
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz
```
---
#### **4.1.3. Access Token Request**
클라이언트는 HTTP 요청 엔터티 본문에서 UTF-8 문자 인코딩을 사용하여 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 다음 매개변수를 전송하여 토큰 엔드포인트에 요청합니다.
보조금 유형
- 필수의. 값은 "authorization\_code"로 설정되어야 합니다.\(MUST, MUST\)
암호
- 필수의. 인증서버로부터 받은 인증코드입니다.\(MUST\)
리디렉션\_우리
- "redirect\_uri" 매개변수가 섹션 4.1.1에 설명된 대로 승인 요청에 포함된 경우 필수이며 해당 값은 동일해야 합니다.\(MUST\)
클라이언트\_ID
- 클라이언트가 섹션 3.2.1에 설명된 대로 인증 서버로 인증하지 않는 경우 필수입니다.\(MUST\)
클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받았거나 다른 인증 요구 사항이 할당된 경우 클라이언트는 섹션 3.2.1에 설명된 대로 권한 부여 서버로 인증해야 합니다.\(MUST\)
예를 들어 클라이언트는 TLS를 사용하여 다음 HTTP 요청을 수행합니다\(표시 목적으로만 추가 줄 바꿈 사용\).
```text
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
```
인증 서버는 다음을 수행해야 합니다.\(MUST\)
```text
o require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),
```
o 클라이언트 인증이 포함된 경우 클라이언트를 인증합니다.
o 인증된 기밀 클라이언트에 인증 코드가 발급되었는지 확인하거나, 클라이언트가 공개인 경우 요청에서 "client\_id"에 코드가 발급되었는지 확인하세요.
o 인증 코드가 유효한지 확인하고
o 섹션 4.1.1에 설명된 대로 "redirect\_uri" 매개변수가 초기 승인 요청에 포함된 경우 "redirect\_uri" 매개변수가 있는지 확인하고, 포함된 경우 해당 값이 동일한지 확인하세요.
---
#### **4.1.4. Access Token Response**
액세스 토큰 요청이 유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰과 선택적 새로 고침 토큰을 발급합니다. 요청 클라이언트 인증이 실패하거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.
성공적인 응답의 예:
```text
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"
}
```
---
### **4.2. Implicit Grant**
암시적 부여 유형은 액세스 토큰을 얻는 데 사용되며\(새로 고침 토큰 발행을 지원하지 않음\) 특정 리디렉션 URI를 작동하는 것으로 알려진 공용 클라이언트에 최적화되어 있습니다. 이러한 클라이언트는 일반적으로 JavaScript와 같은 스크립팅 언어를 사용하여 브라우저에서 구현됩니다.
이는 리디렉션 기반 흐름이므로 클라이언트는 리소스 소유자의 사용자 에이전트\(일반적으로 웹 브라우저\)와 상호 작용할 수 있어야 하며 인증 서버에서 들어오는 요청\(리디렉션을 통해\)을 수신할 수 있어야 합니다.
클라이언트가 권한 부여와 액세스 토큰을 별도로 요청하는 권한 부여 코드 부여 유형과 달리 클라이언트는 권한 부여 요청의 결과로 액세스 토큰을 받습니다.
암시적 권한 부여 유형에는 클라이언트 인증이 포함되지 않으며 리소스 소유자의 존재와 리디렉션 URI 등록에 의존합니다. 액세스 토큰은 리디렉션 URI로 인코딩되므로 동일한 장치에 있는 리소스 소유자 및 기타 애플리케이션에 노출될 수 있습니다.
```text
+----------+
| 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 |
| |
+---------+
```
참고: \(A\) 및 \(B\) 단계를 설명하는 선은 사용자 에이전트를 통과할 때 두 부분으로 나뉩니다.
```text
Figure 4: Implicit Grant Flow
```
그림 4에 표시된 흐름에는 다음 단계가 포함됩니다.
\(A\) 클라이언트는 리소스 소유자의 사용자 에이전트를 인증 끝점으로 지정하여 흐름을 시작합니다. 클라이언트에는 클라이언트 식별자, 요청된 범위, 로컬 상태 및 액세스가 허용\(또는 거부\)되면 권한 부여 서버가 사용자 에이전트를 다시 보낼 리디렉션 URI가 포함됩니다.
\(B\) 권한 부여 서버는 사용자 에이전트를 통해 리소스 소유자를 인증하고 리소스 소유자가 클라이언트의 액세스 요청을 승인할지 거부할지 여부를 설정합니다.
\(C\) 리소스 소유자가 액세스 권한을 부여한다고 가정하면 권한 부여 서버는 이전에 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 리디렉션 URI는 URI 조각에 액세스 토큰을 포함합니다.
\(D\) 사용자 에이전트는 웹 호스팅 클라이언트 리소스\(\[RFC2616\]에 따른 조각을 포함하지 않음\)에 요청하여 리디렉션 지침을 따릅니다. 사용자 에이전트는 조각 정보를 로컬로 유지합니다.
\(E\) 웹 호스팅 클라이언트 리소스는 사용자 에이전트가 보유한 조각을 포함하여 전체 리디렉션 URI에 액세스하고 액세스 토큰\(및 기타 매개변수\)을 추출할 수 있는 웹 페이지\(일반적으로 내장된 스크립트가 있는 HTML 문서\)를 반환합니다. 조각에 포함되어 있습니다.
\(F\) 사용자 에이전트는 웹 호스팅 클라이언트 리소스가 로컬로 제공한 스크립트를 실행하여 액세스 토큰을 추출합니다.
\(G\) 사용자 에이전트는 액세스 토큰을 클라이언트에 전달합니다.
암시적 부여 사용에 대한 배경 정보는 섹션 1.3.2 및 9를 참조하세요. 암시적 권한 부여를 사용할 때 중요한 보안 고려 사항은 섹션 10.3 및 10.16을 참조하세요.
---
#### **4.2.1. Authorization Request**
클라이언트는 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 인증 끝점 URI의 쿼리 구성 요소에 다음 매개 변수를 추가하여 요청 URI를 구성합니다.
응답\_유형
- 필수의. 값은 "토큰"으로 설정되어야 합니다.\(MUST, MUST\)
클라이언트\_ID
- 필수의. 섹션 2.2에 설명된 클라이언트 식별자입니다.\(MUST\)
리디렉션\_우리
- 선택 사항입니다. 섹션 3.1.2에 설명된 대로.\(MAY\)
범위
- 선택 사항입니다. 섹션 3.3에 설명된 액세스 요청의 범위입니다.\(MAY\)
상태
- 추천합니다. 요청과 콜백 간의 상태를 유지하기 위해 클라이언트가 사용하는 불투명 값입니다. 인증 서버는 사용자 에이전트를 클라이언트로 다시 리디렉션할 때 이 값을 포함합니다. 섹션 10.12에 설명된 대로 사이트 간 요청 위조를 방지하기 위해 매개변수를 사용해야 합니다.\(SHOULD, SHOULD\)
클라이언트는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 방법을 사용하여 리소스 소유자를 구성된 URI로 안내합니다.
예를 들어, 클라이언트는 사용자 에이전트에게 TLS를 사용하여 다음 HTTP 요청을 생성하도록 지시합니다\(표시 목적으로만 추가 줄 바꿈 사용\).
```text
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가 섹션 3.1.2에 설명된 대로 클라이언트가 등록한 리디렉션 URI와 일치하는지 확인해야 합니다.\(MUST\)
요청이 유효한 경우 권한 부여 서버는 리소스 소유자를 인증하고 권한 부여 결정을 얻습니다\(리소스 소유자에게 요청하거나 다른 수단을 통해 승인을 설정하여\).
결정이 내려지면 인증 서버는 HTTP 리디렉션 응답을 사용하거나 사용자 에이전트를 통해 사용할 수 있는 다른 수단을 사용하여 사용자 에이전트를 제공된 클라이언트 리디렉션 URI로 보냅니다.
---
#### **4.2.2. Access Token Response**
리소스 소유자가 액세스 요청을 승인하면 권한 부여 서버는 "application/x-www-form-urlencoded" 형식을 사용하여 리디렉션 URI의 조각 구성 요소에 다음 매개변수를 추가하여 액세스 토큰을 발급하고 이를 클라이언트에 전달합니다. 부록 B에 따라:
액세스 토큰
- 필수의. 인증 서버에서 발급한 액세스 토큰입니다.\(MUST\)
토큰 유형
- 필수의. 섹션 7.1에 설명된 대로 발행된 토큰의 유형입니다. 값은 대소문자를 구분하지 않습니다.\(MUST\)
만료
- 추천합니다. 액세스 토큰의 수명\(초\)입니다. 예를 들어 값 "3600"은 액세스 토큰이 응답이 생성된 후 1시간 후에 만료됨을 나타냅니다. 생략된 경우 인증 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야 합니다.\(SHOULD, SHOULD\)
범위
- 클라이언트가 요청한 범위와 동일한 경우 선택 사항입니다. 그렇지 않으면 필수입니다. 섹션 3.3에 설명된 액세스 토큰의 범위입니다.\(MUST\)
상태
- 클라이언트 인증 요청에 "state" 매개변수가 있는 경우 필수입니다. 클라이언트로부터 받은 정확한 값입니다.\(MUST\)
인증 서버는 새로 고침 토큰을 발행해서는 안 됩니다.\(MUST NOT\)
예를 들어 인증 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다\(표시 목적으로만 추가 줄 바꿈 포함\).
```text
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
```
개발자는 일부 사용자 에이전트가 HTTP "위치" 응답 헤더 필드에 조각 구성 요소를 포함하는 것을 지원하지 않는다는 점에 유의해야 합니다. 이러한 클라이언트는 클라이언트를 리디렉션하기 위해 3xx 리디렉션 응답 이외의 다른 방법을 사용해야 합니다. 예를 들어 리디렉션 URI에 연결된 작업이 있는 '계속' 버튼이 포함된 HTML 페이지를 반환합니다.
클라이언트는 인식할 수 없는 응답 매개변수를 무시해야 합니다. 액세스 토큰 문자열 크기는 이 사양에 의해 정의되지 않은 상태로 남아 있습니다. 클라이언트는 값 크기에 대한 가정을 피해야 합니다. 인증 서버는 발행하는 모든 값의 크기를 문서화해야 합니다.\(MUST, SHOULD\)
---
##### **4.2.2.1. Error Response**
누락, 유효하지 않거나 일치하지 않는 리디렉션 URI로 인해 요청이 실패하거나 클라이언트 식별자가 누락되거나 유효하지 않은 경우 인증 서버는 리소스 소유자에게 오류를 알려야 하며 자동으로 사용자 에이전트를 잘못된 리디렉션으로 리디렉션해서는 안 됩니다. URI.\(MUST NOT\)
리소스 소유자가 액세스 요청을 거부하거나 리디렉션 URI가 누락되거나 유효하지 않은 이외의 이유로 요청이 실패한 경우 권한 부여 서버는 "application/x- 부록 B에 따른 www-form-urlencoded" 형식:
오류
- 필수의. 다음 중 단일 ASCII \[USASCII\] 오류 코드:\(MUST\)
잘못된 요청
- 요청에 필수 매개변수가 누락되었거나, 잘못된 매개변수 값이 포함되어 있거나, 매개변수가 두 번 이상 포함되어 있거나, 형식이 잘못되었습니다.
무단\_클라이언트
- 클라이언트는 이 방법을 사용하여 액세스 토큰을 요청할 권한이 없습니다.
액세스가 거부되었습니다.
- 리소스 소유자 또는 권한 부여 서버가 요청을 거부했습니다.
지원되지 않는\_응답\_유형
- 인증 서버는 이 방법을 사용하여 액세스 토큰을 얻는 것을 지원하지 않습니다.
유효하지 않은\_범위
- 요청한 범위가 유효하지 않거나 알 수 없거나 형식이 잘못되었습니다.
서버 오류
- 인증 서버에서 요청을 이행하지 못하게 하는 예상치 못한 상황이 발생했습니다. \(500 내부 서버 오류 HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요합니다.\)
일시적으로\_사용할 수 없음
- 현재 일시적인 과부하 또는 서버 점검으로 인해 인증 서버가 요청을 처리할 수 없습니다. \(503 Service Unavailable HTTP 상태 코드는 HTTP 리디렉션을 통해 클라이언트에 반환될 수 없기 때문에 이 오류 코드가 필요합니다.\)
- "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MUST NOT\)
오류\_설명
- 선택 사항입니다. 클라이언트 개발자가 발생한 오류를 이해하는 데 도움이 되는 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII \[USASCII\] 텍스트입니다. "error\_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
error\_uri
- 선택 사항입니다. 오류에 대한 정보가 포함된 사람이 읽을 수 있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error\_uri" 매개변수의 값은 URI 참조 구문을 준수해야 하며 따라서 %x21 / %x23-5B / %x5D-7E 집합 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
상태
- 클라이언트 인증 요청에 "상태" 매개변수가 있는 경우 필수입니다. 클라이언트로부터 받은 정확한 값입니다.\(MUST\)
예를 들어 인증 서버는 다음 HTTP 응답을 전송하여 사용자 에이전트를 리디렉션합니다.
```text
HTTP/1.1 302 Found
Location: https://client.example.com/cb#error=access_denied&state=xyz
```
---
### **4.3. Resource Owner Password Credentials Grant**
리소스 소유자 비밀번호 자격 증명 부여 유형은 리소스 소유자가 장치 운영 체제 또는 높은 권한을 가진 클라이언트와 같이 클라이언트와 신뢰 관계를 갖고 있는 경우에 적합합니다.
애플리케이션. 권한 부여 서버는 이 승인 유형을 활성화할 때 특별한 주의를 기울여야 하며 다른 흐름이 실행 가능하지 않을 때만 허용해야 합니다.
이 부여 유형은 리소스 소유자의 자격 증명\(일반적으로 대화형 형식을 사용하는 사용자 이름 및 비밀번호\)을 얻을 수 있는 클라이언트에 적합합니다. 또한 저장된 자격 증명을 액세스 토큰으로 변환하여 HTTP 기본 또는 다이제스트 인증과 같은 직접 인증 체계를 사용하는 기존 클라이언트를 OAuth로 마이그레이션하는 데에도 사용됩니다.
```text
+----------+
| 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\) 클라이언트는 리소스 소유자로부터 받은 자격 증명을 포함하여 권한 부여 서버의 토큰 엔드포인트에서 액세스 토큰을 요청합니다. 요청할 때 클라이언트는 권한 부여 서버를 통해 인증합니다.
\(C\) 권한 부여 서버는 클라이언트를 인증하고 리소스 소유자 자격 증명의 유효성을 검사하고 유효한 경우 액세스 토큰을 발급합니다.
---
#### **4.3.1. Authorization Request and Response**
클라이언트가 리소스 소유자 자격 증명을 얻는 방법은 이 사양의 범위를 벗어납니다. 클라이언트는 액세스 토큰을 얻은 후에 자격 증명을 폐기해야 합니다.\(MUST\)
---
#### **4.3.2. Access Token Request**
클라이언트는 HTTP 요청 엔터티 본문에서 UTF-8 문자 인코딩과 함께 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 다음 매개변수를 추가하여 토큰 엔드포인트에 요청합니다.
보조금 유형
- 필수의. 값은 "password"로 설정되어야 합니다.\(MUST, MUST\)
사용자 이름
- 필수의. 리소스 소유자 사용자 이름입니다.\(MUST\)
비밀번호
- 필수의. 리소스 소유자 비밀번호입니다.\(MUST\)
범위
- 선택 사항입니다. 섹션 3.3에 설명된 액세스 요청의 범위입니다.\(MAY\)
클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받았거나 다른 인증 요구 사항이 할당된 경우 클라이언트는 섹션 3.2.1에 설명된 대로 권한 부여 서버로 인증해야 합니다.\(MUST\)
예를 들어 클라이언트는 전송 계층 보안\(표시 목적으로만 추가 줄 바꿈 포함\)을 사용하여 다음 HTTP 요청을 수행합니다.
```text
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
```
인증 서버는 다음을 수행해야 합니다.\(MUST\)
```text
o require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),
```
o 클라이언트 인증이 포함된 경우 클라이언트를 인증합니다.
o 기존 비밀번호 확인 알고리즘을 사용하여 자원 소유자 비밀번호 자격 증명의 유효성을 확인합니다.
이 액세스 토큰 요청은 리소스 소유자의 비밀번호를 활용하므로 인증 서버는 무차별 대입 공격\(예: 속도 제한 사용 또는 경고 생성\)으로부터 엔드포인트를 보호해야 합니다.\(MUST\)
---
#### **4.3.3. Access Token Response**
액세스 토큰 요청이 유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰과 선택적 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.
성공적인 응답의 예:
```text
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"
}
```
---
### **4.4. Client Credentials Grant**
클라이언트는 자신이 제어하는 보호된 리소스 또는 이전에 인증 서버와 함께 배열된 다른 리소스 소유자의 리소스에 대한 액세스를 요청할 때 클라이언트 자격 증명\(또는 기타 지원되는 인증 수단\)만을 사용하여 액세스 토큰을 요청할 수 있습니다. 그 방법은 이 사양의 범위를 벗어납니다\).
클라이언트 자격 증명 부여 유형은 기밀 클라이언트에서만 사용해야 합니다.\(MUST\)
```text
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
```
그림 6에 표시된 흐름에는 다음 단계가 포함됩니다.
\(A\) 클라이언트는 권한 부여 서버로 인증하고 토큰 엔드포인트에서 액세스 토큰을 요청합니다.
\(B\) 인증 서버는 클라이언트를 인증하고 유효한 경우 액세스 토큰을 발급합니다.
---
#### **4.4.1. Authorization Request and Response**
클라이언트 인증을 권한 부여로 사용하므로 별도의 권한 부여 요청이 필요하지 않습니다.
---
#### **4.4.2. Access Token Request**
클라이언트는 HTTP 요청 엔터티 본문에서 UTF-8 문자 인코딩과 함께 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 다음 매개변수를 추가하여 토큰 엔드포인트에 요청합니다.
보조금 유형
- 필수의. 값은 "client\_credentials"로 설정되어야 합니다.\(MUST, MUST\)
범위
- 선택 사항입니다. 섹션 3.3에 설명된 액세스 요청의 범위입니다.\(MAY\)
클라이언트는 섹션 3.2.1에 설명된 대로 인증 서버로 인증해야 합니다.\(MUST\)
예를 들어 클라이언트는 전송 계층 보안\(표시 목적으로만 추가 줄 바꿈 포함\)을 사용하여 다음 HTTP 요청을 수행합니다.
```text
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
```
인증 서버는 클라이언트를 인증해야 합니다.\(MUST\)
---
#### **4.4.3. Access Token Response**
액세스 토큰 요청이 유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰을 발급합니다. 새로 고침 토큰은 포함되어서는 안 됩니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.\(SHOULD NOT\)
성공적인 응답의 예:
```text
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"
}
```
---
### **4.5. Extension Grants**
클라이언트는 토큰 엔드포인트의 "grant\_type" 매개변수 값으로 절대 URI\(인증 서버에서 정의\)를 사용하여 권한 부여 유형을 지정하고 필요한 추가 매개변수를 추가하여 확장 권한 부여 유형을 사용합니다.
예를 들어, \[OAuth-SAML2\]에 정의된 SAML\(Security Assertion Markup Language\) 2.0 어설션 부여 유형을 사용하여 액세스 토큰을 요청하려면 클라이언트는 TLS\(표시 목적으로만 추가 줄 바꿈 포함\)를 사용하여 다음 HTTP 요청을 수행할 수 있습니다. :
```text
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-
```
액세스 토큰 요청이 유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰과 선택적 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.
---
## **5. Issuing an Access Token**
액세스 토큰 요청이 유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰과 선택적 새로 고침 토큰을 발급합니다. 요청이 클라이언트 인증에 실패했거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.
---
### **5.1. Successful Response**
인증 서버는 액세스 토큰과 선택적 새로 고침 토큰을 발급하고 200\(OK\) 상태 코드를 사용하여 HTTP 응답의 엔터티 본문에 다음 매개변수를 추가하여 응답을 구성합니다.
액세스 토큰
- 필수의. 인증 서버에서 발급한 액세스 토큰입니다.\(MUST\)
토큰 유형
- 필수의. 섹션 7.1에 설명된 대로 발행된 토큰의 유형입니다. 값은 대소문자를 구분하지 않습니다.\(MUST\)
만료
- 추천합니다. 액세스 토큰의 수명\(초\)입니다. 예를 들어 값 "3600"은 액세스 토큰이 응답이 생성된 후 1시간 후에 만료됨을 나타냅니다. 생략된 경우 인증 서버는 다른 수단을 통해 만료 시간을 제공하거나 기본값을 문서화해야 합니다.\(SHOULD, SHOULD\)
새로 고침\_토큰
- 선택 사항입니다. 섹션 6에 설명된 것과 동일한 권한 부여를 사용하여 새 액세스 토큰을 얻는 데 사용할 수 있는 새로 고침 토큰.\(MAY\)
범위
- 클라이언트가 요청한 범위와 동일한 경우 선택 사항입니다. 그렇지 않으면 필수입니다. 섹션 3.3에 설명된 액세스 토큰의 범위입니다.\(MUST\)
매개변수는 \[RFC4627\]에 정의된 대로 "application/json" 미디어 유형을 사용하여 HTTP 응답의 엔터티 본문에 포함됩니다. 매개변수는 가장 높은 구조 수준에 각 매개변수를 추가하여 JSON\(JavaScript Object Notation\) 구조로 직렬화됩니다. 매개변수 이름과 문자열 값은 JSON 문자열로 포함됩니다. 숫자 값은 JSON 숫자로 포함됩니다. 매개변수의 순서는 중요하지 않으며 다양할 수 있습니다.
인증 서버는 "Pragma" 응답 헤더 필드뿐만 아니라 토큰, 자격 증명 또는 기타 민감한 정보를 포함하는 모든 응답에 "no-store" 값을 가진 HTTP "Cache-Control" 응답 헤더 필드\[RFC2616\]를 포함해야 합니다. \[RFC2616\] 값이 "no-cache"입니다.\(MUST\)
예를 들어:
```text
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"
}
```
클라이언트는 응답에서 인식할 수 없는 값 이름을 무시해야 합니다. 인증 서버에서 받은 토큰의 크기와 기타 값은 정의되지 않은 상태로 유지됩니다. 클라이언트는 값 크기에 대한 가정을 피해야 합니다. 인증 서버는 발행하는 모든 값의 크기를 문서화해야 합니다.\(MUST, SHOULD\)
---
### **5.2. Error Response**
인증 서버는 달리 지정하지 않는 한 HTTP 400\(잘못된 요청\) 상태 코드로 응답하고 응답에 다음 매개변수를 포함합니다.
오류
- 필수의. 다음 중 단일 ASCII \[USASCII\] 오류 코드:\(MUST\)
잘못된 요청
- 요청에 필수 매개변수가 누락되었거나, 지원되지 않는 매개변수 값\(허가 유형 제외\)이 포함되어 있거나, 매개변수가 반복되거나, 여러 자격 증명이 포함되어 있거나, 클라이언트 인증을 위해 두 개 이상의 메커니즘을 사용하거나, 형식이 잘못된 경우입니다.
무효\_클라이언트
- 클라이언트 인증에 실패했습니다\(예: 알 수 없는 클라이언트, 클라이언트 인증이 포함되지 않음, 지원되지 않는 인증 방법\). 인증 서버는 어떤 HTTP 인증 체계가 지원되는지 나타내기 위해 HTTP 401\(인증되지 않음\) 상태 코드를 반환할 수 있습니다. 클라이언트가 "Authorization" 요청 헤더 필드를 통해 인증을 시도한 경우 인증 서버는 반드시 HTTP 401\(Unauthorized\) 상태 코드로 응답하고 클라이언트가 사용하는 인증 체계와 일치하는 "WWW-Authenticate" 응답 헤더 필드를 포함해야 합니다.\(MAY, MUST\)
무효\_그랜트
- 제공된 인증 부여\(예: 인증 코드, 리소스 소유자 자격 증명\) 또는 새로 고침 토큰이 유효하지 않거나, 만료되었거나, 취소되었거나, 인증 요청에 사용된 리디렉션 URI와 일치하지 않거나, 다른 클라이언트에 발급되었습니다.
무단\_클라이언트
- 인증된 클라이언트는 이 권한 부여 유형을 사용할 권한이 없습니다.
지원되지 않는\_grant\_type
- 권한 부여 유형은 권한 부여 서버에서 지원되지 않습니다.
유효하지 않은\_범위
- 요청한 범위가 유효하지 않거나, 알 수 없거나, 형식이 잘못되었거나, 리소스 소유자가 부여한 범위를 초과합니다.
- "error" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MUST NOT\)
오류\_설명
- 선택 사항입니다. 클라이언트 개발자가 발생한 오류를 이해하는 데 도움이 되는 추가 정보를 제공하는 사람이 읽을 수 있는 ASCII \[USASCII\] 텍스트입니다. "error\_description" 매개변수의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
error\_uri
- 선택 사항입니다. 오류에 대한 정보가 포함된 사람이 읽을 수 있는 웹 페이지를 식별하는 URI로, 클라이언트 개발자에게 오류에 대한 추가 정보를 제공하는 데 사용됩니다. "error\_uri" 매개변수의 값은 URI 참조 구문을 준수해야 하며 따라서 %x21 / %x23-5B / %x5D-7E 집합 외부의 문자를 포함해서는 안 됩니다.\(MAY, MUST NOT\)
매개변수는 \[RFC4627\]에 정의된 대로 "application/json" 미디어 유형을 사용하여 HTTP 응답의 엔터티 본문에 포함됩니다. 매개변수는 가장 높은 구조 수준에 각 매개변수를 추가하여 JSON 구조로 직렬화됩니다. 매개변수 이름과 문자열 값은 JSON 문자열로 포함됩니다. 숫자 값은 JSON 숫자로 포함됩니다. 매개변수의 순서는 중요하지 않으며 다양할 수 있습니다.
예를 들어:
```text
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
```
---
## **6. Refreshing an Access Token**
권한 부여 서버가 클라이언트에 새로 고침 토큰을 발행한 경우 클라이언트는 UTF 문자 인코딩과 함께 부록 B에 따라 "application/x-www-form-urlencoded" 형식을 사용하여 다음 매개변수를 추가하여 토큰 끝점에 새로 고침 요청을 합니다. -8 HTTP 요청 엔터티 본문:
보조금 유형
- 필수의. 값은 "refresh\_token"으로 설정되어야 합니다.\(MUST, MUST\)
새로 고침\_토큰
- 필수의. 클라이언트에 발급된 새로 고침 토큰입니다.\(MUST\)
범위
- 선택 사항입니다. 섹션 3.3에 설명된 액세스 요청의 범위입니다. 요청된 범위에는 리소스 소유자가 원래 부여하지 않은 범위가 포함되어서는 안 되며, 생략된 경우 리소스 소유자가 원래 부여한 범위와 동일한 것으로 간주됩니다.\(MAY, MUST NOT\)
새로 고침 토큰은 일반적으로 추가 액세스 토큰을 요청하는 데 사용되는 오래 지속되는 자격 증명이므로 새로 고침 토큰은 발급된 클라이언트에 바인딩됩니다. 클라이언트 유형이 기밀이거나 클라이언트가 클라이언트 자격 증명을 발급받았거나 다른 인증 요구 사항이 할당된 경우 클라이언트는 섹션 3.2.1에 설명된 대로 권한 부여 서버로 인증해야 합니다.\(MUST\)
예를 들어 클라이언트는 전송 계층 보안\(표시 목적으로만 추가 줄 바꿈 포함\)을 사용하여 다음 HTTP 요청을 수행합니다.
```text
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
```
인증 서버는 다음을 수행해야 합니다.\(MUST\)
```text
o require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),
```
o 클라이언트 인증이 포함된 경우 클라이언트를 인증하고 새로 고침 토큰이 인증된 클라이언트에 발급되었는지 확인합니다.
o 새로 고침 토큰의 유효성을 검사합니다.
유효하고 인증된 경우 인증 서버는 섹션 5.1에 설명된 대로 액세스 토큰을 발급합니다. 요청이 검증에 실패했거나 유효하지 않은 경우 인증 서버는 섹션 5.2에 설명된 대로 오류 응답을 반환합니다.
인증 서버는 새로운 새로 고침 토큰을 발행할 수 있으며, 이 경우 클라이언트는 이전 새로 고침 토큰을 폐기하고 이를 새로운 새로 고침 토큰으로 교체해야 합니다. 인증 서버는 클라이언트에 새 새로 고침 토큰을 발급한 후 이전 새로 고침 토큰을 취소할 수 있습니다. 새로운 새로 고침 토큰이 발행되면 새로 고침 토큰 범위는 클라이언트가 요청에 포함하는 새로 고침 토큰의 범위와 동일해야 합니다.\(MUST, MAY, MUST\)
---
## **7. Accessing Protected Resources**
클라이언트는 리소스 서버에 액세스 토큰을 제공하여 보호되는 리소스에 액세스합니다. 리소스 서버는 액세스 토큰의 유효성을 검사하고 만료되지 않았는지, 해당 범위가 요청된 리소스를 포함하는지 확인해야 합니다. 액세스 토큰\(및 오류 응답\)을 검증하기 위해 리소스 서버에서 사용하는 방법은 이 사양의 범위를 벗어나지만 일반적으로 리소스 서버와 인증 서버 간의 상호 작용 또는 조정이 포함됩니다.\(MUST\)
클라이언트가 액세스 토큰을 활용하여 리소스 서버에 인증하는 방법은 권한 부여 서버에서 발급한 액세스 토큰 유형에 따라 다릅니다. 일반적으로 \[RFC6750\]과 같이 사용된 액세스 토큰 유형의 사양에 의해 정의된 인증 체계와 함께 HTTP "Authorization" 요청 헤더 필드 \[RFC2617\]를 사용하는 것이 포함됩니다.
---
### **7.1. Access Token Types**
액세스 토큰 유형은 액세스 토큰을 성공적으로 활용하여 보호된 리소스 요청을 수행하는 데 필요한 정보\(유형별 속성과 함께\)를 클라이언트에 제공합니다. 클라이언트는 토큰 유형을 이해하지 못하는 경우 액세스 토큰을 사용해서는 안 됩니다.\(MUST NOT\)
예를 들어, \[RFC6750\]에 정의된 "베어러" 토큰 유형은 요청에 액세스 토큰 문자열을 포함함으로써 활용됩니다.
```text
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
```
\[OAuth-HTTP-MAC\]에 정의된 "mac" 토큰 유형은 HTTP 요청의 특정 구성 요소에 서명하는 데 사용되는 액세스 토큰과 함께 메시지 인증 코드\(MAC\) 키를 발급하여 활용됩니다.
```text
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
```
위의 예는 설명 목적으로만 제공됩니다. 개발자는 사용하기 전에 \[RFC6750\] 및 \[OAuth-HTTP-MAC\] 사양을 참조하는 것이 좋습니다.
각 액세스 토큰 유형 정의는 "access\_token" 응답 매개변수와 함께 클라이언트에 전송되는 추가 속성\(있는 경우\)을 지정합니다. 또한 보호된 리소스를 요청할 때 액세스 토큰을 포함하는 데 사용되는 HTTP 인증 방법을 정의합니다.
---
### **7.2. Error Response**
리소스 액세스 요청이 실패하면 리소스 서버는 클라이언트에게 오류를 알려야 합니다. 이러한 오류 응답의 구체적인 내용은 이 사양의 범위를 벗어나지만 이 문서는 OAuth 토큰 인증 체계 간에 공유할 오류 값에 대해 섹션 11.4에 공통 레지스트리를 설정합니다.\(SHOULD\)
주로 OAuth 토큰 인증을 위해 설계된 새로운 인증 체계는 허용되는 오류 값이 이 사양에 의해 설정된 오류 레지스트리에 등록되는 오류 상태 코드를 클라이언트에 제공하기 위한 메커니즘을 정의해야 합니다.\(SHOULD\)
이러한 체계는 유효한 오류 코드 집합을 등록된 값의 하위 집합으로 제한할 수 있습니다. 명명된 매개변수를 사용하여 오류 코드가 반환되면 매개변수 이름은 "error"여야 합니다.\(MAY, SHOULD\)
OAuth 토큰 인증에 사용될 수 있지만 기본적으로 해당 목적으로 설계되지 않은 다른 체계는 동일한 방식으로 오류 값을 레지스트리에 바인딩할 수 있습니다.\(MAY\)
새로운 인증 체계는 이 사양의 사용법과 유사한 방식으로 오류 정보를 반환하기 위해 "error\_description" 및 "error\_uri" 매개변수의 사용을 지정하도록 선택할 수도 있습니다.\(MAY\)
---
## **8. Extensibility**
---
### **8.1. Defining Access Token Types**
액세스 토큰 유형은 액세스 토큰 유형 레지스트리에 등록하거나\(섹션 11.1의 절차에 따라\) 고유한 절대 URI를 이름으로 사용하는 두 가지 방법 중 하나로 정의할 수 있습니다.
URI 이름을 활용하는 유형은 일반적으로 적용할 수 없는 공급업체별 구현으로 제한되어야 하며, 사용되는 리소스 서버의 구현 세부 사항에 따라 달라집니다.\(SHOULD\)
다른 모든 유형은 반드시 등록되어야 합니다. 유형 이름은 유형 이름 ABNF를 준수해야 합니다. 유형 정의에 새로운 HTTP 인증 체계가 포함된 경우 유형 이름은 HTTP 인증 체계 이름\(\[RFC2617\]에 정의된 대로\)과 동일해야 합니다. 토큰 유형 "example"은 예제에 사용하도록 예약되어 있습니다.\(MUST, MUST, SHOULD\)
```text
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
```
---
### **8.2. Defining New Endpoint Parameters**
인증 엔드포인트 또는 토큰 엔드포인트와 함께 사용할 새로운 요청 또는 응답 매개변수는 섹션 11.2의 절차에 따라 OAuth 매개변수 레지스트리에 정의되고 등록됩니다.
매개변수 이름은 param-name ABNF를 준수해야 하며 매개변수 값 구문은 잘 정의되어야 합니다\(예: ABNF 또는 기존 매개변수 구문에 대한 참조 사용\).\(MUST\)
```text
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
```
일반적으로 적용할 수 없고 사용되는 인증 서버의 구현 세부 사항에 특정한 등록되지 않은 공급업체별 매개변수 확장은 등록된 다른 값과 충돌할 가능성이 없는 공급업체별 접두사를 활용해야 합니다\(예: ' 회사 이름\_'\).\(SHOULD\)
---
### **8.3. Defining New Authorization Grant Types**
새로운 권한 부여 유형은 "grant\_type" 매개변수와 함께 사용할 고유한 절대 URI를 할당하여 정의할 수 있습니다. 확장 권한 부여 유형에 추가 토큰 엔드포인트 매개변수가 필요한 경우 섹션 11.2에 설명된 대로 OAuth 매개변수 레지스트리에 등록해야 합니다.\(MUST\)
---
### **8.4. Defining New Authorization Endpoint Response Types**
권한 부여 끝점과 함께 사용할 새로운 응답 유형은 섹션 11.3의 절차에 따라 권한 부여 끝점 응답 유형 레지스트리에 정의되고 등록됩니다. 응답 유형 이름은 응답 유형 ABNF를 준수해야 합니다.\(MUST\)
```text
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
```
응답 유형에 하나 이상의 공백 문자\(%x20\)가 포함된 경우 값의 순서가 중요하지 않은 공백으로 구분된 값 목록으로 비교됩니다. 동일한 값 세트의 다른 모든 배열을 포함하는 하나의 값 순서만 등록할 수 있습니다.
예를 들어, 응답 유형 "토큰 코드"는 이 사양에서 정의되지 않은 상태로 남아 있습니다. 그러나 확장은 "토큰 코드" 응답 유형을 정의하고 등록할 수 있습니다. 한번 등록되면 동일한 조합은 "코드 토큰"으로 등록할 수 없지만, 두 값을 모두 사용하여 동일한 응답 유형을 나타낼 수 있습니다.
---
### **8.5. Defining Additional Error Codes**
프로토콜 확장\(예: 액세스 토큰 유형, 확장 매개변수 또는 확장 권한 부여 유형\)에서 인증 코드 부여 오류 응답\(섹션 4.1.2.1\)과 함께 사용할 추가 오류 코드가 필요한 경우 암시적 권한 부여 오류 응답\(섹션 4.2. 2.1\), 토큰 오류 응답\(5.2절\) 또는 리소스 액세스 오류 응답\(7.2절\)과 같은 오류 코드가 정의될 수 있습니다.\(MAY\)
확장 오류 코드는 함께 사용되는 확장이 등록된 액세스 토큰 유형, 등록된 엔드포인트 매개변수 또는 확장 승인 유형인 경우 등록되어야 합니다\(섹션 11.4의 절차에 따라\). 등록되지 않은 확장과 함께 사용되는 오류 코드는 등록될 수 있습니다.\(MUST, MAY\)
오류 코드는 오류 ABNF를 준수해야 하며 가능하면 식별 이름이 앞에 붙어야 합니다\(SHOULD\). 예를 들어, 확장 매개변수 "example"에 설정된 유효하지 않은 값을 식별하는 오류는 "example\_invalid"로 이름을 지정해야 합니다.\(MUST, SHOULD\)
```text
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
```
---
## **9. Native Applications**
네이티브 애플리케이션은 리소스 소유자가 사용하는 장치\(예: 데스크톱 애플리케이션, 네이티브 모바일 애플리케이션\)에 설치되고 실행되는 클라이언트입니다. 기본 애플리케이션에는 보안, 플랫폼 기능 및 전반적인 최종 사용자 경험과 관련된 특별한 고려 사항이 필요합니다.
권한 부여 끝점에는 클라이언트와 리소스 소유자의 사용자 에이전트 간의 상호 작용이 필요합니다. 기본 애플리케이션은 외부 사용자 에이전트를 호출하거나 애플리케이션 내에 사용자 에이전트를 내장할 수 있습니다. 예를 들어:
o 외부 사용자 에이전트 - 네이티브 애플리케이션은 클라이언트를 핸들러로 호출하기 위해 운영 체제에 등록된 구성표와 함께 리디렉션 URI를 사용하여 인증 서버로부터 응답을 캡처할 수 있으며 자격 증명을 수동으로 복사하여 붙여넣고 로컬 웹 서버, 사용자 에이전트 확장 설치 또는 클라이언트 제어 하에 서버 호스팅 리소스를 식별하는 리디렉션 URI를 제공하여 기본 애플리케이션에서 응답을 사용할 수 있게 합니다.
o 임베디드 사용자 에이전트 - 네이티브 애플리케이션은 리소스 로드 중에 발생한 상태 변경을 모니터링하거나 사용자 에이전트의 쿠키 저장소에 액세스하여 임베디드 사용자 에이전트와 직접 통신하여 응답을 얻습니다.
외부 또는 내장된 사용자 에이전트 중에서 선택할 때 개발자는 다음을 고려해야 합니다.
o 외부 사용자 에이전트는 리소스 소유자가 이미 인증 서버와의 활성 세션을 갖고 있어 재인증이 필요하지 않으므로 완료율을 향상시킬 수 있습니다. 이는 친숙한 최종 사용자 경험과 기능을 제공합니다. 그만큼
- 리소스 소유자는 인증을 지원하기 위해 사용자 에이전트 기능이나 확장에 의존할 수도 있습니다\(예: 비밀번호 관리자, 2단계 장치 리더기\).
o 내장된 사용자 에이전트는 컨텍스트를 전환하고 새 창을 열 필요가 없으므로 향상된 유용성을 제공할 수 있습니다.
o 내장된 사용자 에이전트는 리소스 소유자가 대부분의 외부 사용자 에이전트에 있는 시각적 보호에 액세스하지 않고 식별되지 않은 창에서 인증하기 때문에 보안 문제를 제기합니다. 내장된 사용자 에이전트는 최종 사용자가 식별되지 않은 인증 요청을 신뢰하도록 교육합니다\(피싱 공격 실행을 더 쉽게 만듭니다\).
암시적 부여 유형과 인증 코드 부여 유형 중에서 선택할 때 다음 사항을 고려해야 합니다.
o 인증 코드 부여 유형을 사용하는 네이티브 애플리케이션은 클라이언트 자격 증명을 기밀로 유지할 수 없기 때문에 클라이언트 자격 증명을 사용하지 않고 이를 수행해야 합니다.\(SHOULD\)
o 암시적 부여 유형 흐름을 사용하는 경우 새로 고침 토큰이 반환되지 않으므로 액세스 토큰이 만료되면 인증 프로세스를 반복해야 합니다.
---
## **10. Security Considerations**
유연하고 확장 가능한 프레임워크인 OAuth의 보안 고려 사항은 여러 요소에 따라 달라집니다. 다음 섹션에서는 구현자에게 섹션 2.1에 설명된 세 가지 클라이언트 프로필\(웹 애플리케이션, 사용자 에이전트 기반 애플리케이션, 기본 애플리케이션\)에 초점을 맞춘 보안 지침을 제공합니다.
\[OAuth-THREATMODEL\]은 포괄적인 OAuth 보안 모델 및 분석, 프로토콜 설계 배경을 제공합니다.
---
### **10.1. Client Authentication**
권한 부여 서버는 클라이언트 인증을 위해 웹 애플리케이션 클라이언트와 함께 클라이언트 자격 증명을 설정합니다. 인증 서버는 클라이언트 비밀번호보다 더 강력한 클라이언트 인증 수단을 고려하는 것이 좋습니다. 웹 애플리케이션 클라이언트는 클라이언트 비밀번호 및 기타 클라이언트 자격 증명의 기밀성을 보장해야 합니다.\(MUST\)
인증 서버는 클라이언트 인증을 위해 기본 애플리케이션이나 사용자 에이전트 기반 애플리케이션 클라이언트에 클라이언트 비밀번호나 기타 클라이언트 자격 증명을 발급해서는 안 됩니다. 인증 서버는 특정 장치에 기본 애플리케이션 클라이언트를 설치하기 위해 클라이언트 비밀번호 또는 기타 자격 증명을 발급할 수 있습니다.\(MUST NOT, MAY\)
클라이언트 인증이 가능하지 않은 경우 권한 부여 서버는 클라이언트의 신원을 확인하기 위해 다른 수단을 사용해야 합니다. 예를 들어 클라이언트 리디렉션 URI 등록을 요구하거나 신원 확인을 위해 자원 소유자를 모집하는 등의 방법이 있습니다. 유효한 리디렉션 URI는 리소스 소유자 권한 부여를 요청할 때 클라이언트의 신원을 확인하는 데 충분하지 않지만 리소스 소유자 권한을 얻은 후 위조 클라이언트에 자격 증명을 전달하는 것을 방지하는 데 사용할 수 있습니다.\(SHOULD\)
권한 부여 서버는 인증되지 않은 클라이언트와의 상호 작용이 보안에 미치는 영향을 고려하고 해당 클라이언트에 발행된 다른 자격 증명\(예: 새로 고침 토큰\)의 잠재적 노출을 제한하기 위한 조치를 취해야 합니다.
---
### **10.2. Client Impersonation**
악의적인 클라이언트는 가장된 클라이언트가 클라이언트 자격 증명을 기밀로 유지하지 못하거나 유지할 수 없는 경우 다른 클라이언트를 가장하여 보호된 리소스에 액세스할 수 있습니다.
인증 서버는 가능할 때마다 클라이언트를 인증해야 합니다. 인증 서버가 클라이언트의 특성으로 인해 클라이언트를 인증할 수 없는 경우 인증 서버는 인증 응답을 수신하는 데 사용되는 리디렉션 URI의 등록을 요구해야 하며 잠재적으로 악의적인 클라이언트로부터 리소스 소유자를 보호하기 위해 다른 수단을 활용해야 합니다. 예를 들어, 권한 부여 서버는 리소스 소유자를 참여시켜 클라이언트와 클라이언트의 출처를 식별하는 데 도움을 줄 수 있습니다.\(MUST, MUST\)
인증 서버는 명시적인 리소스 소유자 인증을 시행하고 리소스 소유자에게 클라이언트와 요청된 인증 범위 및 수명에 대한 정보를 제공해야 합니다. 현재 클라이언트의 컨텍스트에서 정보를 검토하고 요청을 승인하거나 거부하는 것은 리소스 소유자의 몫입니다.\(SHOULD\)
인증 서버는 클라이언트를 인증하거나 반복된 요청이 가장자가 아닌 원래 클라이언트에서 오는지 확인하기 위한 다른 조치에 의존하지 않고 자동으로\(활성 리소스 소유자 상호 작용 없이\) 반복된 인증 요청을 처리해서는 안 됩니다.\(SHOULD NOT\)
---
### **10.3. Access Tokens**
액세스 토큰 자격 증명\(기밀 액세스 토큰 속성 포함\)은 전송 및 저장 시 기밀로 유지되어야 하며, 인증 서버, 액세스 토큰이 유효한 리소스 서버, 액세스 토큰이 발급된 클라이언트 간에만 공유되어야 합니다. . 액세스 토큰 자격 증명은 \[RFC2818\]에 정의된 서버 인증과 함께 섹션 1.6에 설명된 TLS를 통해서만 전송되어야 합니다.\(MUST, MUST\)
암시적 승인 유형을 사용하는 경우 액세스 토큰은 URI 조각으로 전송되므로 승인되지 않은 당사자에게 노출될 수 있습니다.
인증 서버는 인증되지 않은 당사자가 유효한 액세스 토큰을 생성하기 위해 액세스 토큰을 생성, 수정 또는 추측할 수 없도록 해야 합니다.\(MUST\)
클라이언트는 필요한 최소 범위로 액세스 토큰을 요청해야 합니다\(SHOULD\). 인증 서버는 요청된 범위를 존중하는 방법을 선택할 때 클라이언트 신원을 고려해야 하며 요청된 것보다 적은 권한으로 액세스 토큰을 발행할 수 있습니다.\(SHOULD, SHOULD\)
이 사양은 리소스 서버가 특정 클라이언트가 제공한 액세스 토큰이 인증 서버에 의해 해당 클라이언트에 발급되었는지 확인하는 방법을 제공하지 않습니다.
---
### **10.4. Refresh Tokens**
인증 서버는 웹 애플리케이션 클라이언트와 기본 애플리케이션 클라이언트에 새로 고침 토큰을 발행할 수 있습니다.\(MAY\)
새로 고침 토큰은 전송 및 저장 시 기밀로 유지되어야 하며, 새로 고침 토큰이 발급된 클라이언트와 인증 서버 간에만 공유되어야 합니다. 인증 서버는 새로 고침 토큰과 해당 토큰이 발급된 클라이언트 간의 바인딩을 유지해야 합니다. 새로 고침 토큰은 \[RFC2818\]에 정의된 서버 인증과 함께 섹션 1.6에 설명된 TLS를 통해서만 전송되어야 합니다.\(MUST, MUST, MUST\)
인증 서버는 클라이언트 ID가 인증될 수 있을 때마다 새로 고침 토큰과 클라이언트 ID 간의 바인딩을 확인해야 합니다. 클라이언트 인증이 가능하지 않은 경우 인증 서버는 새로 고침 토큰 남용을 감지하기 위한 다른 수단을 배포해야 합니다.\(MUST, SHOULD\)
예를 들어 권한 부여 서버는 모든 액세스 토큰 새로 고침 응답과 함께 새 새로 고침 토큰이 발급되는 새로 고침 토큰 순환을 사용할 수 있습니다. 이전 새로 고침 토큰이 무효화되었습니다.
그러나 인증 서버에 의해 유지됩니다. 새로 고침 토큰이 손상되어 공격자와 합법적인 클라이언트 모두에 의해 사용되는 경우, 그 중 하나는 무효화된 새로 고침 토큰을 제공하여 인증 서버에 위반 사실을 알립니다.
인증 서버는 인증되지 않은 당사자가 유효한 새로 고침 토큰을 생성하기 위해 새로 고침 토큰을 생성, 수정 또는 추측할 수 없도록 해야 합니다.\(MUST\)
---
### **10.5. Authorization Codes**
인증 코드의 전송은 보안 채널을 통해 이루어져야 하며, 클라이언트는 URI가 네트워크 리소스를 식별하는 경우 리디렉션 URI와 함께 TLS를 사용하도록 요구해야 합니다\(SHOULD\). 인증 코드는 사용자 에이전트 리디렉션을 통해 전송되므로 잠재적으로 사용자 에이전트 기록 및 HTTP 리퍼러 헤더를 통해 공개될 수 있습니다.\(SHOULD\)
인증 코드는 일반 텍스트 전달자 자격 증명으로 작동하며, 인증 서버에서 인증을 부여한 리소스 소유자가 프로세스를 완료하기 위해 클라이언트로 반환되는 리소스 소유자와 동일한지 확인하는 데 사용됩니다. 따라서 클라이언트가 자체 리소스 소유자 인증을 위해 인증 코드를 사용하는 경우 클라이언트 리디렉션 끝점에서는 TLS를 사용해야 합니다.\(MUST\)
승인 코드는 수명이 짧고 일회용이어야 합니다. 인증 서버가 인증 코드를 액세스 토큰으로 교환하려는 여러 시도를 관찰하는 경우, 인증 서버는 손상된 인증 코드를 기반으로 이미 부여된 모든 액세스 토큰을 취소하려고 시도해야 합니다\(SHOULD\).\(MUST, SHOULD\)
클라이언트가 인증될 수 있는 경우 인증 서버는 클라이언트를 인증해야 하며 인증 코드가 동일한 클라이언트에 발행되었는지 확인해야 합니다.\(MUST\)
---
### **10.6. Authorization Code Redirection URI Manipulation**
인증 코드 부여 유형을 사용하여 인증을 요청할 때 클라이언트는 "redirect\_uri" 매개변수를 통해 리디렉션 URI를 지정할 수 있습니다. 공격자가 리디렉션 URI의 값을 조작할 수 있는 경우, 인증 서버는 인증 코드를 사용하여 공격자가 제어하는 URI로 리소스 소유자 사용자 에이전트를 리디렉션할 수 있습니다.
공격자는 합법적인 클라이언트에서 계정을 만들고 인증 흐름을 시작할 수 있습니다. 액세스 권한을 부여하기 위해 공격자의 사용자 에이전트가 인증 서버로 전송되면 공격자는 합법적인 클라이언트가 제공한 인증 URI를 가져와서
클라이언트의 리디렉션 URI를 공격자가 제어하는 URI로 만듭니다. 그런 다음 공격자는 합법적인 클라이언트에 대한 액세스 권한을 부여하기 위해 조작된 링크를 따라가도록 피해자를 속입니다.
인증 서버에 도달하면 피해자는 합법적이고 신뢰할 수 있는 클라이언트를 대신하여 정상적이고 유효한 요청을 메시지로 받고 해당 요청을 인증합니다. 그런 다음 피해자는 인증 코드를 사용하여 공격자가 제어하는 엔드포인트로 리디렉션됩니다. 공격자는 클라이언트가 제공한 원래 리디렉션 URI를 사용하여 클라이언트에 인증 코드를 보내 인증 흐름을 완료합니다. 클라이언트는 인증 코드를 액세스 토큰과 교환하고 이를 공격자의 클라이언트 계정에 연결합니다. 그러면 이제 클라이언트를 통해 피해자가 인증한 보호 리소스에 액세스할 수 있습니다.
이러한 공격을 방지하기 위해 인증 서버는 인증 코드를 얻기 위해 사용된 리디렉션 URI가 액세스 토큰에 대한 인증 코드를 교환할 때 제공되는 리디렉션 URI와 동일한지 확인해야 합니다. 인증 서버는 공개 클라이언트를 요구해야 하며\(MUST\) 기밀 클라이언트가 리디렉션 URI를 등록하도록 요구해야 합니다\(SHOULD\). 요청에 리디렉션 URI가 제공되면 인증 서버는 등록된 값에 대해 이를 검증해야 합니다.\(MUST, MUST, MUST\)
---
### **10.7. Resource Owner Password Credentials**
리소스 소유자 비밀번호 자격 증명 부여 유형은 레거시 또는 마이그레이션 이유로 자주 사용됩니다. 클라이언트가 사용자 이름과 비밀번호를 저장하는 데 따른 전반적인 위험은 줄어들지만 높은 권한의 자격 증명을 클라이언트에 노출할 필요가 없어지지는 않습니다.
이 부여 유형은 이 프로토콜이 피하고자 하는 비밀번호 안티 패턴을 유지하기 때문에 다른 부여 유형보다 더 높은 위험을 수반합니다. 클라이언트가 비밀번호를 남용할 수도 있고, 비밀번호가 의도치 않게 공격자에게 공개될 수도 있습니다\(예: 클라이언트가 보관하는 로그 파일이나 기타 기록을 통해\).
또한 리소스 소유자는 권한 부여 프로세스를 제어할 수 없기 때문에\(리소스 소유자의 참여는 자격 증명을 클라이언트에 전달하면 종료됨\) 클라이언트는 리소스 소유자가 원하는 것보다 더 넓은 범위의 액세스 토큰을 얻을 수 있습니다. 인증 서버는 이 부여 유형을 통해 발급된 액세스 토큰의 범위와 수명을 고려해야 합니다.
인증 서버와 클라이언트는 이 승인 유형의 사용을 최소화해야 하며 가능할 때마다 다른 승인 유형을 활용해야 합니다.\(SHOULD\)
---
### **10.8. Request Confidentiality**
액세스 토큰, 새로 고침 토큰, 리소스 소유자 비밀번호 및 클라이언트 자격 증명은 일반 형식으로 전송되어서는 안 됩니다. 인증 코드는 일반 텍스트로 전송되어서는 안 됩니다.\(MUST NOT, SHOULD NOT\)
"상태" 및 "범위" 매개변수는 민감한 클라이언트 또는 리소스 소유자 정보를 일반 텍스트로 포함해서는 안 됩니다. 이러한 정보는 안전하지 않은 채널을 통해 전송되거나 안전하지 않게 저장될 수 있기 때문입니다.\(SHOULD NOT\)
---
### **10.9. Ensuring Endpoint Authenticity**
메시지 가로채기\(man-in-the-middle\) 공격을 방지하기 위해 인증 서버는 인증 및 토큰 엔드포인트로 전송되는 모든 요청에 대해 \[RFC2818\]에 정의된 대로 서버 인증과 함께 TLS를 사용해야 합니다. 클라이언트는 \[RFC6125\]에 정의된 대로 서버 신원 인증에 대한 요구 사항에 따라 인증 서버의 TLS 인증서를 검증해야 합니다.\(MUST, MUST\)
---
### **10.10. Credentials-Guessing Attacks**
인증 서버는 공격자가 액세스 토큰, 인증 코드, 새로 고침 토큰, 리소스 소유자 비밀번호 및 클라이언트 자격 증명을 추측하는 것을 방지해야 합니다.\(MUST\)
공격자가 생성된 토큰\(및 최종 사용자가 처리할 의도가 없는 기타 자격 증명\)을 추측할 확률은 2^\(-128\)보다 작거나 같아야 하며 2^\(-160\)보다 작거나 같아야 합니다\(SHOULD\).\(MUST\)
인증 서버는 최종 사용자 사용을 위한 자격 증명을 보호하기 위해 다른 수단을 활용해야 합니다.\(MUST\)
---
### **10.11. Phishing Attacks**
이 프로토콜과 유사한 프로토콜을 광범위하게 배포하면 최종 사용자가 비밀번호를 입력하라는 요청을 받는 웹 사이트로 리디렉션되는 관행에 익숙해질 수 있습니다. 최종 사용자가 자격 증명을 입력하기 전에 이러한 웹 사이트의 신뢰성을 주의 깊게 확인하지 않으면 공격자가 이 방법을 악용하여 리소스 소유자의 비밀번호를 훔칠 수 있습니다.
서비스 제공업체는 피싱 공격이 제기하는 위험에 대해 최종 사용자에게 교육을 시도해야 하며 최종 사용자가 사이트의 신뢰성을 쉽게 확인할 수 있는 메커니즘을 제공해야 합니다. 클라이언트 개발자는 사용자 에이전트\(예: 외부, 내장\)와 상호 작용하는 방식의 보안 영향과 최종 사용자가 인증 서버의 신뢰성을 확인할 수 있는 능력을 고려해야 합니다.
피싱 공격의 위험을 줄이기 위해 인증 서버는 최종 사용자 상호 작용에 사용되는 모든 엔드포인트에서 TLS를 사용하도록 요구해야 합니다.\(MUST\)
---
### **10.12. Cross-Site Request Forgery**
CSRF\(교차 사이트 요청 위조\)는 공격자가 피해자 최종 사용자의 사용자 에이전트가 악의적인 URI\(예: 오해의 소지가 있는 링크, 이미지 또는 리디렉션으로 사용자 에이전트에 제공됨\)를 따르도록 하는 악용입니다. 신뢰하는 서버에\(보통 유효한 세션 쿠키의 존재를 통해 설정됨\)
클라이언트의 리디렉션 URI에 대한 CSRF 공격을 통해 공격자는 자신의 인증 코드나 액세스 토큰을 주입할 수 있으며, 이로 인해 클라이언트는 피해자의 리소스가 아닌 공격자의 보호되는 리소스와 연결된 액세스 토큰을 사용하게 될 수 있습니다\(예: 피해자의 은행 계좌 정보 저장\). 공격자가 제어하는 보호된 리소스로\).
클라이언트는 리디렉션 URI에 대한 CSRF 보호를 구현해야 합니다. 이는 일반적으로 요청을 사용자 에이전트의 인증 상태\(예: 사용자 에이전트를 인증하는 데 사용되는 세션 쿠키의 해시\)에 바인딩하는 값을 포함하도록 리디렉션 URI 끝점으로 전송된 모든 요청에 의해 수행됩니다. 클라이언트는 인증 요청을 할 때 "state" 요청 매개변수를 활용하여 이 값을 인증 서버에 전달해야 합니다.\(MUST, SHOULD\)
최종 사용자로부터 인증을 받으면 인증 서버는 "state" 매개변수에 포함된 필수 바인딩 값을 사용하여 최종 사용자의 사용자 에이전트를 클라이언트로 다시 리디렉션합니다. 바인딩 값을 사용하면 클라이언트는 바인딩 값을 사용자 에이전트의 인증 상태와 일치시켜 요청의 유효성을 확인할 수 있습니다. CSRF 보호에 사용되는 바인딩 값은 추측할 수 없는 값\(섹션 10.10에 설명됨\)을 포함해야 하며 사용자 에이전트의 인증된 상태\(예: 세션 쿠키, HTML5 로컬 저장소\)는 클라이언트만 액세스할 수 있는 위치에 보관되어야 합니다. 및 사용자 에이전트\(즉, 동일 출처 정책으로 보호됨\).\(MUST\)
인증 서버의 인증 엔드포인트에 대한 CSRF 공격으로 인해 공격자는 최종 사용자를 개입시키거나 경고하지 않고 악의적인 클라이언트에 대한 최종 사용자 인증을 얻을 수 있습니다.
권한 부여 서버는 권한 부여 끝점에 대한 CSRF 보호를 구현해야 하며 악의적인 클라이언트가 리소스 소유자의 인식 및 명시적인 동의 없이 권한을 얻을 수 없도록 해야 합니다.\(MUST\)
---
### **10.13. Clickjacking**
클릭재킹 공격에서 공격자는 합법적인 클라이언트를 등록한 다음 더미 버튼 세트 위에 오버레이된 투명한 iframe에 인증 서버의 인증 엔드포인트 웹 페이지를 로드하는 악성 사이트를 구성합니다. 이 더미 버튼은 직접 배치되도록 신중하게 구성됩니다. 인증 페이지의 중요한 버튼 아래에 있습니다. 최종 사용자가 오해의 소지가 있는 표시 버튼을 클릭하면 실제로 최종 사용자는 인증 페이지에서 보이지 않는 버튼\(예: "인증" 버튼\)을 클릭하는 것입니다. 이를 통해 공격자는 최종 사용자가 모르는 사이에 리소스 소유자를 속여 클라이언트 액세스 권한을 부여할 수 있습니다.
이러한 형태의 공격을 방지하려면 기본 애플리케이션은 최종 사용자 인증을 요청할 때 애플리케이션 내에 브라우저를 내장하는 대신 외부 브라우저를 사용해야 합니다. 대부분의 최신 브라우저의 경우 \(비표준\) "x-frame-options" 헤더를 사용하여 인증 서버에서 iframe 방지를 시행할 수 있습니다. 이 헤더에는 "deny"와 "sameorigin"이라는 두 가지 값이 있을 수 있으며, 이는 각각 프레이밍 또는 원본이 다른 사이트의 프레이밍을 차단합니다. 이전 브라우저의 경우 JavaScript 프레임 버스팅 기술을 사용할 수 있지만 일부 브라우저에서는 효과적이지 않을 수 있습니다.\(SHOULD\)
---
### **10.14. Code Injection and Input Validation**
코드 주입 공격은 입력 또는 외부 변수가 삭제되지 않은 애플리케이션에서 사용되어 애플리케이션 로직이 수정될 때 발생합니다. 이를 통해 공격자는 응용 프로그램 장치나 해당 데이터에 액세스할 수 있고, 서비스 거부를 유발하거나 광범위한 악의적인 부작용을 일으킬 수 있습니다.
인증 서버와 클라이언트는 수신된 모든 값, 특히 "state" 및 "redirect\_uri" 매개변수의 값을 삭제하고 가능한 경우 유효성을 검사해야 합니다.\(MUST\)
---
### **10.15. Open Redirectors**
인증 서버, 인증 엔드포인트, 클라이언트 리디렉션 엔드포인트가 잘못 구성되어 오픈 리디렉터로 작동할 수 있습니다. 개방형 리디렉터는 매개변수를 사용하여 유효성 검사 없이 매개변수 값으로 지정된 위치로 사용자 에이전트를 자동으로 리디렉션하는 엔드포인트입니다.
개방형 리디렉터는 피싱 공격에 사용되거나 공격자가 친숙하고 신뢰할 수 있는 대상의 URI 기관 구성 요소를 사용하여 최종 사용자가 악성 사이트를 방문하도록 유도할 수 있습니다. 또한 인증 서버가 클라이언트가 리디렉션 URI의 일부만 등록하도록 허용하는 경우 공격자는 다음과 같이 운영되는 오픈 리디렉터를 사용할 수 있습니다.
클라이언트는 인증 서버 유효성 검사를 통과하지만 인증 코드나 액세스 토큰을 공격자의 제어 하에 있는 엔드포인트로 보내는 리디렉션 URI를 구성합니다.
10.16. 암시적 흐름에서 리소스 소유자를 가장하기 위해 액세스 토큰을 오용함
암시적 흐름을 사용하는 공용 클라이언트의 경우 이 사양은 클라이언트가 액세스 토큰이 발급된 클라이언트를 확인할 수 있는 방법을 제공하지 않습니다.
리소스 소유자는 공격자의 악의적인 클라이언트에 액세스 토큰을 부여하여 리소스에 대한 액세스를 기꺼이 위임할 수 있습니다. 이는 피싱이나 기타 구실로 인한 것일 수 있습니다. 공격자는 다른 메커니즘을 통해 토큰을 훔칠 수도 있습니다. 그런 다음 공격자는 합법적인 공개 클라이언트에 액세스 토큰을 제공하여 리소스 소유자를 가장하려고 시도할 수 있습니다.
암시적 흐름\(response\_type=token\)에서 공격자는 승인 서버의 응답에서 토큰을 쉽게 전환하여 실제 액세스 토큰을 이전에 공격자에게 발급된 토큰으로 바꿀 수 있습니다.
클라이언트의 사용자를 식별하기 위해 백 채널의 액세스 토큰 전달에 의존하는 기본 애플리케이션과 통신하는 서버는 도난당한 임의의 액세스 토큰을 주입할 수 있는 손상된 애플리케이션을 만드는 공격자에 의해 유사하게 손상될 수 있습니다.
리소스 소유자만이 리소스에 대한 유효한 액세스 토큰을 제공할 수 있다고 가정하는 모든 공용 클라이언트는 이러한 유형의 공격에 취약합니다.
이러한 유형의 공격은 합법적인 클라이언트의 리소스 소유자에 대한 정보를 공격자\(악의적인 클라이언트\)에게 노출시킬 수 있습니다. 또한 이를 통해 공격자는 원래 액세스 토큰이나 인증 코드를 부여한 리소스 소유자와 동일한 권한을 사용하여 합법적인 클라이언트에서 작업을 수행할 수 있습니다.
클라이언트에 대한 리소스 소유자 인증은 이 사양의 범위를 벗어납니다. 클라이언트에 위임된 최종 사용자 인증의 형태로 권한 부여 프로세스를 사용하는 모든 사양\(예: 제3자 로그인 서비스\)은 클라이언트가 액세스 여부를 확인할 수 있도록 하는 추가 보안 메커니즘 없이 암시적 흐름을 사용해서는 안 됩니다. 토큰은 사용을 위해 발행되었습니다\(예: 청중-액세스 토큰 제한\).\(MUST NOT\)
---
## **11. IANA Considerations**
---
### **11.1. OAuth Access Token Types Registry**
이 사양은 OAuth 액세스 토큰 유형 레지스트리를 설정합니다.
액세스 토큰 유형은 한 명 이상의 지정 전문가의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주간의 검토 기간을 거친 후 필수 사양\(\[RFC5226\]\)에 등록됩니다. 그러나 출판 전에 가치를 할당할 수 있도록 지정 전문가는 해당 사양이 출판될 것이라는 확신이 들면 등록을 승인할 수 있습니다.
등록 요청은 검토 및 의견을 위해 적절한 제목\(예: "액세스 토큰 유형 요청: 예"\)과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 합니다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고 이 결정을 검토 목록과 IANA에 전달합니다. 거부에는 요청을 성공적으로 수행하는 방법에 대한 설명과 제안\(해당되는 경우\)이 포함되어야 합니다.
IANA는 지정 전문가의 레지스트리 업데이트만 수락해야 하며 모든 등록 요청을 검토 메일링 목록으로 보내야 합니다.
---
#### **11.1.1. Registration Template**
유형 이름:
- 요청된 이름\(예: "예"\)
추가 토큰 엔드포인트 응답 매개변수:
- "access\_token" 매개변수와 함께 반환되는 추가 응답 매개변수입니다. 새로운 매개변수는 섹션 11.2에 설명된 대로 OAuth 매개변수 레지스트리에 별도로 등록되어야 합니다.\(MUST\)
HTTP 인증 체계:
- 이 유형의 액세스 토큰을 사용하여 보호된 리소스 요청을 인증하는 데 사용되는 HTTP 인증 체계 이름\(들\)입니다.
컨트롤러 변경:
- 표준 추적 RFC의 경우 "IETF"라고 명시합니다. 그 외의 경우에는 책임 있는 당사자의 이름을 기재해 주십시오. 기타 세부정보\(예: 우편 주소, 이메일 주소, 홈페이지 URI\)도 포함될 수 있습니다.
사양 문서:
- 문서의 복사본을 검색하는 데 사용할 수 있는 URI를 포함하는 매개변수를 지정하는 문서에 대한 참조입니다. 관련 섹션의 표시도 포함될 수 있지만 필수는 아닙니다.
---
### **11.2. OAuth Parameters Registry**
이 사양은 OAuth 매개변수 레지스트리를 설정합니다.
권한 부여 끝점 요청, 권한 부여 끝점 응답, 토큰 끝점 요청 또는 토큰 끝점 응답에 포함하기 위한 추가 매개 변수는 oauth-ext-review에서 2주간의 검토 기간 후에 사양 필수\(\[RFC5226\]\)에 등록됩니다. @ietf.org 메일링 리스트, 한 명 이상의 지정 전문가의 조언. 그러나 출판 전에 가치를 할당할 수 있도록 지정 전문가는 해당 사양이 출판될 것이라는 확신이 들면 등록을 승인할 수 있습니다.
등록 요청은 검토 및 의견을 위해 적절한 제목\(예: "매개변수 요청: 예"\)과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 합니다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고 이 결정을 검토 목록과 IANA에 전달합니다. 거부에는 요청을 성공적으로 수행하는 방법에 대한 설명과 제안\(해당되는 경우\)이 포함되어야 합니다.
IANA는 지정 전문가의 레지스트리 업데이트만 수락해야 하며 모든 등록 요청을 검토 메일링 목록으로 보내야 합니다.
---
#### **11.2.1. Registration Template**
매개변수 이름:
- 요청된 이름\(예: "예"\)
매개변수 사용 위치:
- 매개변수를 사용할 수 있는 위치입니다. 가능한 위치는 권한 부여 요청, 권한 부여 응답, 토큰 요청 또는 토큰 응답입니다.
컨트롤러 변경:
- 표준 추적 RFC의 경우 "IETF"라고 명시합니다. 그 외의 경우에는 책임 있는 당사자의 이름을 기재해 주십시오. 기타 세부정보\(예: 우편 주소, 이메일 주소, 홈페이지 URI\)도 포함될 수 있습니다.
사양 문서:
- 문서의 복사본을 검색하는 데 사용할 수 있는 URI를 포함하는 매개변수를 지정하는 문서에 대한 참조입니다. 관련 섹션의 표시도 포함될 수 있지만 필수는 아닙니다.
---
#### **11.2.2. Initial Registry Contents**
OAuth 매개변수 레지스트리의 초기 내용은 다음과 같습니다.
```text
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
```
---
### **11.3. OAuth Authorization Endpoint Response Types Registry**
이 사양은 OAuth 인증 끝점 응답 유형 레지스트리를 설정합니다.
인증 엔드포인트와 함께 사용할 추가 응답 유형은 한 명 이상의 지정 전문가의 조언에 따라 oauth-ext-review@ietf.org 메일링 리스트에서 2주간의 검토 기간을 거친 후 필수 사양\(\[RFC5226\]\)에 등록됩니다. . 그러나 출판 전에 가치를 할당할 수 있도록 지정 전문가는 해당 사양이 출판될 것이라는 확신이 들면 등록을 승인할 수 있습니다.
등록 요청은 검토 및 의견을 위해 적절한 제목\(예: "응답 유형 요청: 예"\)과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 합니다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고 이 결정을 검토 목록과 IANA에 전달합니다. 거부에는 요청을 성공적으로 수행하는 방법에 대한 설명과 제안\(해당되는 경우\)이 포함되어야 합니다.
IANA는 지정 전문가의 레지스트리 업데이트만 수락해야 하며 모든 등록 요청을 검토 메일링 목록으로 보내야 합니다.
---
#### **11.3.1. Registration Template**
응답 유형 이름:
- 요청된 이름\(예: "예"\)
컨트롤러 변경:
- 표준 추적 RFC의 경우 "IETF"라고 명시합니다. 그 외의 경우에는 책임 있는 당사자의 이름을 기재해 주십시오. 기타 세부정보\(예: 우편 주소, 이메일 주소, 홈페이지 URI\)도 포함될 수 있습니다.
사양 문서:
- 문서의 복사본을 검색하는 데 사용할 수 있는 URI를 포함하여 유형을 지정하는 문서에 대한 참조입니다. 관련 섹션의 표시도 포함될 수 있지만 필수는 아닙니다.
---
#### **11.3.2. Initial Registry Contents**
OAuth 권한 부여 끝점 응답 유형 레지스트리의 초기 콘텐츠는 다음과 같습니다.
```text
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
```
---
### **11.4. OAuth Extensions Error Registry**
이 사양은 OAuth 확장 오류 레지스트리를 설정합니다.
다른 프로토콜 확장\(예: 확장 허용 유형, 액세스 토큰 유형 또는 확장 매개변수\)과 함께 사용되는 추가 오류 코드는 oauth-ext-review@에서 2주간의 검토 기간 후에 사양 필수\(\[RFC5226\]\)에 등록됩니다. ietf.org 메일링 리스트, 한 명 이상의 지정 전문가의 조언에 따라. 그러나 출판 전에 가치를 할당할 수 있도록 지정 전문가는 해당 사양이 출판될 것이라는 확신이 들면 등록을 승인할 수 있습니다.
등록 요청은 검토 및 의견을 위해 적절한 제목\(예: "오류 코드 요청: 예"\)과 함께 oauth-ext-review@ietf.org 메일링 리스트로 보내야 합니다.
검토 기간 내에 지정 전문가는 등록 요청을 승인하거나 거부하고 이 결정을 검토 목록과 IANA에 전달합니다. 거부에는 요청을 성공적으로 수행하는 방법에 대한 설명과 제안\(해당되는 경우\)이 포함되어야 합니다.
IANA는 지정 전문가의 레지스트리 업데이트만 수락해야 하며 모든 등록 요청을 검토 메일링 목록으로 보내야 합니다.
---
#### **11.4.1. Registration Template**
오류 이름:
- 요청된 이름\(예: "예"\) 오류 이름의 값은 %x20-21 / %x23-5B / %x5D-7E 세트 외부의 문자를 포함해서는 안 됩니다.\(MUST NOT\)
오류 사용 위치:
- 오류가 사용될 수 있는 위치. 가능한 위치는 인증 코드 부여 오류 응답\(섹션 4.1.2.1\), 암시적 부여 오류 응답\(섹션 4.2.2.1\), 토큰 오류 응답\(섹션 5.2\) 또는 리소스 액세스 오류 응답\(섹션 7.2\)입니다.
관련 프로토콜 확장:
- 오류 코드가 함께 사용되는 확장 권한 부여 유형, 액세스 토큰 유형 또는 확장 매개변수의 이름입니다.
컨트롤러 변경:
- 표준 추적 RFC의 경우 "IETF"라고 명시합니다. 그 외의 경우에는 책임 있는 당사자의 이름을 기재해 주십시오. 기타 세부정보\(예: 우편 주소, 이메일 주소, 홈페이지 URI\)도 포함될 수 있습니다.
사양 문서:
- 오류 코드를 지정하는 문서에 대한 참조\(문서 사본을 검색하는 데 사용할 수 있는 URI를 포함하는 것이 바람직함\) 관련 섹션의 표시도 포함될 수 있지만 필수는 아닙니다.
---
## **12. References**
---
### **12.1. Normative References**
\[RFC2119\] Bradner, S., "요구 사항 수준을 나타내기 위해 RFC에서 사용할 핵심 단어", BCP 14, RFC 2119, 1997년 3월.
\[RFC2246\] Dierks, T. 및 C. Allen, "TLS 프로토콜 버전 1.0", RFC 2246, 1999년 1월.
\[RFC2616\] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P. 및 T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, 1999년 6월.
\[RFC2617\] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. 및 L. Stewart, "HTTP 인증: 기본 및 다이제스트 액세스 인증" , RFC 2617, 1999년 6월.
\[RFC2818\] Rescorla, E., "HTTP Over TLS", RFC 2818, 2000년 5월.
\[RFC3629\] Yergeau, F., "UTF-8, 변환 형식
- ISO 10646", STD 63, RFC 3629, 2003년 11월.
\[RFC3986\] Berners-Lee, T., Fielding, R. 및 L. Masinter, "Uniform Resource Identifier\(URI\): 일반 구문", STD 66, RFC 3986, 2005년 1월.
\[RFC4627\] Crockford, D., "JSON\(JavaScript Object Notation\)을 위한 application/json 미디어 유형", RFC 4627, 2006년 7월.
```text
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
```
\[RFC5226\] Narten, T. 및 H. Alvestrand, "RFC에서 IANA 고려 사항 섹션 작성 지침", BCP 26, RFC 5226, 2008년 5월.
\[RFC5234\] Crocker, D. 및 P. Overell, "구문 사양을 위한 증강 BNF: ABNF", STD 68, RFC 5234, 2008년 1월.
\[RFC5246\] Dierks, T. 및 E. Rescorla, "TLS\(전송 계층 보안\) 프로토콜 버전 1.2", RFC 5246, 2008년 8월.
\[RFC6125\] Saint-Andre, P. 및 J. Hodges, "TLS\(전송 계층 보안\) 컨텍스트에서 X.509\(PKIX\) 인증서를 사용하여 인터넷 공개 키 인프라 내 도메인 기반 애플리케이션 서비스 ID의 표현 및 확인", RFC 6125, 2011년 3월.
\[USASCII\] 미국 국립 표준 협회\(American National Standards Institute\), "코드화된 문자 집합 - 정보 교환을 위한 7비트 미국 표준 코드", ANSI X3.4, 1986.
```text
[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>.
```
---
### **12.2. Informative References**
\[OAuth-HTTP-MAC\]
- Hammer-Lahav, E., Ed., "HTTP 인증: MAC 액세스 인증", 진행 중인 작업, 2012년 2월.
\[OAuth-SAML2\]
- Campbell, B. 및 C. Mortimore, "OAuth 2.0용 SAML 2.0 전달자 어설션 프로필", 진행 중인 작업, 2012년 9월.
\[OAuth-위협모델\]
- Lodderstedt, T., Ed., McGloin, M. 및 P. Hunt, "OAuth 2.0 위협 모델 및 보안 고려 사항", 진행 중인 작업, 2012년 10월.
\[OAuth-랩\]
- Hardt, D., Ed., Tom, A., Eaton, B., Y. Goland, "OAuth 웹 리소스 인증 프로필", 진행 중인 작업, 2010년 1월.
```text
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
```
\[RFC6750\] Jones, M. 및 D. Hardt, "OAuth 2.0 인증 프레임워크: 전달자 토큰 사용", RFC 6750, 2012년 10월.
---
# **Appendix A. Augmented Backus-Naur Form (ABNF) Syntax**
이 섹션에서는 \[RFC5234\] 표기법을 사용하여 본 사양에 정의된 요소에 대한 ABNF\(Augmented Backus-Naur Form\) 구문 설명을 제공합니다. 아래 ABNF는 유니코드 코드 포인트 \[W3C.REC-xml-20081126\]로 정의됩니다. 이러한 문자는 일반적으로 UTF-8로 인코딩됩니다. 요소는 처음 정의된 순서대로 표시됩니다.
다음 정의 중 일부는 \[RFC3986\]의 "URI 참조" 정의를 사용합니다.
다음 정의 중 일부는 다음과 같은 일반적인 정의를 사용합니다.
```text
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
```
\(UNICODECHARNOCRLF 정의는 \[W3C.REC-xml-20081126\] 섹션 2.2의 Char 정의를 기반으로 하지만 캐리지 리턴 및 줄 바꿈 문자는 생략됩니다.\)
---
### **A.1. "client_id" Syntax**
"client\_id" 요소는 섹션 2.3.1에 정의되어 있습니다.
```text
client-id = *VSCHAR
```
---
### **A.2. "client_secret" Syntax**
"client\_secret" 요소는 섹션 2.3.1에 정의되어 있습니다.
```text
client-secret = *VSCHAR
```
---
### **A.3. "response_type" Syntax**
"response\_type" 요소는 섹션 3.1.1 및 8.4에 정의되어 있습니다.
```text
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
```
---
### **A.4. "scope" Syntax**
"범위" 요소는 섹션 3.3에 정의되어 있습니다.
```text
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
```
---
### **A.5. "state" Syntax**
"상태" 요소는 섹션 4.1.1, 4.1.2, 4.1.2.1, 4.2.1, 4.2.2 및 4.2.2.1에 정의되어 있습니다.
```text
state = 1*VSCHAR
```
---
### **A.6. "redirect_uri" Syntax**
"redirect\_uri" 요소는 섹션 4.1.1, 4.1.3 및 4.2.1에 정의되어 있습니다.
```text
redirect-uri = URI-reference
```
---
### **A.7. "error" Syntax**
"오류" 요소는 섹션 4.1.2.1, 4.2.2.1, 5.2, 7.2 및 8.5에 정의되어 있습니다.
```text
error = 1*NQSCHAR
```
---
### **A.8. "error_description" Syntax**
"error\_description" 요소는 섹션 4.1.2.1, 4.2.2.1, 5.2 및 7.2에 정의되어 있습니다.
```text
error-description = 1*NQSCHAR
```
---
### **A.9. "error_uri" Syntax**
"error\_uri" 요소는 섹션 4.1.2.1, 4.2.2.1, 5.2 및 7.2에 정의되어 있습니다.
```text
error-uri = URI-reference
```
---
### **A.10. "grant_type" Syntax**
"grant\_type" 요소는 섹션 4.1.3, 4.3.2, 4.4.2, 4.5 및 6에 정의되어 있습니다.
```text
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
```
---
### **A.11. "code" Syntax**
"코드" 요소는 섹션 4.1.3에 정의되어 있습니다.
```text
code = 1*VSCHAR
```
---
### **A.12. "access_token" Syntax**
"access\_token" 요소는 섹션 4.2.2 및 5.1에 정의되어 있습니다.
```text
access-token = 1*VSCHAR
```
---
### **A.13. "token_type" Syntax**
"token\_type" 요소는 섹션 4.2.2, 5.1 및 8.1에 정의되어 있습니다.
```text
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
```
---
### **A.14. "expires_in" Syntax**
"expires\_in" 요소는 섹션 4.2.2 및 5.1에 정의되어 있습니다.
```text
expires-in = 1*DIGIT
```
---
### **A.15. "username" Syntax**
"사용자 이름" 요소는 섹션 4.3.2에 정의되어 있습니다.
```text
username = *UNICODECHARNOCRLF
```
---
### **A.16. "password" Syntax**
"password" 요소는 섹션 4.3.2에 정의되어 있습니다.
```text
password = *UNICODECHARNOCRLF
```
---
### **A.17. "refresh_token" Syntax**
"refresh\_token" 요소는 섹션 5.1 및 6에 정의되어 있습니다.
```text
refresh-token = 1*VSCHAR
```
---
### **A.18. Endpoint Parameter Syntax**
새로운 엔드포인트 매개변수의 구문은 섹션 8.2에 정의되어 있습니다.
```text
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
```
---
# **Appendix B. Use of application/x-www-form-urlencoded Media Type**
이 사양이 발행될 당시 "application/x-www-form-urlencoded" 미디어 유형은 \[W3C.REC-html401-19991224\]의 섹션 17.13.4에 정의되었지만 IANA MIME 미디어 유형 레지스트리에는 등록되지 않았습니다. \(<http://www.iana.org/Assignments/media-types\>\). 게다가 이 정의는 US-ASCII가 아닌 문자를 고려하지 않기 때문에 불완전합니다.
이 미디어 유형을 사용하여 페이로드를 생성할 때 이러한 단점을 해결하려면 먼저 UTF-8 문자 인코딩 체계 \[RFC3629\]를 사용하여 이름과 값을 인코딩해야 합니다. 그런 다음 결과 옥텟 시퀀스는 \[W3C.REC-html401-19991224\]에 정의된 이스케이프 규칙을 사용하여 추가로 인코딩되어야 합니다.\(MUST\)
이 미디어 유형을 사용하여 페이로드에서 데이터를 구문 분석할 때 이름/값 인코딩을 반전하여 생성된 이름과 값은 결과적으로 UTF-8 문자 인코딩 체계를 사용하여 디코딩되도록 옥텟 시퀀스로 처리되어야 합니다.
예를 들어 6개의 유니코드 코드 포인트로 구성된 값 \(1\) U+0020\(SPACE\), \(2\) U+0025\(PERCENT SIGN\), \(3\) U+0026\(AMPERSAND\), \(4\) U+002B\( PLUS SIGN\), \(5\) U+00A3\(POUND SIGN\) 및 \(6\) U+20AC\(EURO SIGN\)은 아래의 옥텟 시퀀스로 인코딩됩니다\(16진수 표기법 사용\).
```text
20 25 26 2B C2 A3 E2 82 AC
```
그런 다음 페이로드에 다음과 같이 표시됩니다.
```text
+%25%26%2B%C2%A3%E2%82%AC
```
---
# **Appendix C. Acknowledgements**
초기 OAuth 2.0 프로토콜 사양은 OAuth 1.0 커뮤니티 사양 \[RFC5849\] 및 OAuth WRAP\(OAuth Web Resource Authorization Profiles\) \[OAuth-WRAP\]이라는 두 가지 이전 출판물을 기반으로 David Recordon에 의해 편집되었습니다. 그런 다음 Eran Hammer는 이 RFC로 발전된 많은 중간 초안을 편집했습니다. 보안 고려 사항 섹션의 초안은 Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin 및 John Bradley가 작성했습니다. "application/x-www-form-urlencoded" 미디어 유형 사용에 관한 섹션은 Julian Reschke가 초안을 작성했습니다. ABNF 섹션의 초안은 Michael B. Jones가 작성했습니다.
OAuth 1.0 커뮤니티 사양은 Eran Hammer가 편집하고 Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer가 작성했습니다. , Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky 및 Andy Smith.
OAuth WRAP 사양은 Dick Hardt가 편집했으며 Brian Eaton, Yaron Y. Goland, Dick Hardt 및 Allen Tom이 작성했습니다.
이 사양은 수십 명의 적극적이고 헌신적인 참가자로 구성된 OAuth 실무 그룹의 작업입니다. 특히 다음 개인은 최종 사양을 형성하고 형성하는 아이디어, 피드백 및 문구에 기여했습니다.
마이클 아담스, 아만다 앙가네스, 앤드류 아노트, 더크 발판즈, 에이든 벨, 존 브래들리, 마르코스 카세레스, 브라이언 캠벨, 스콧 캔터, 블레인 쿡, 로저 크루, 레아 컬버, 빌 드 호라, 안드레 드마레, 브라이언 이튼, 웨슬리 에디, 월터 Eldering, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones , Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William 밀스, 척 모티모어, 앤서니 나달린, 줄리안 레슈케, 저스틴 리처, 피터 세인트 안드레, 냇 사키무라, 롭 세이어, 마리우스 스커테스쿠, 나이틱 샤, 루크 셰퍼드, 블라드 Skvortsov, 저스틴 스미스, 하이빈 송, 니브 스테인가르텐, 크리스티안 스튜에브너, 제레미 수리엘, 폴 타잔, 크리스토퍼 토마스, 헨리 S. 톰슨, 앨런 톰, 프랭클린 체, 닉 워커, 셰인 위든, 스카일라 우드워드.
이 문서는 Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba 및 Derek Atkins의 의장으로 작성되었습니다. 지역 책임자로는 Lisa Dusseault, Peter Saint-Andre 및 Stephen Farrell이 있습니다.
---
# **Author's Address**
```text
Dick Hardt (editor)
Microsoft
EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/
```
original document link : https://www.ietf.org/rfc/rfc6749.txt
Disclaimer of Accuracy for Translation:
This document is a translation of the original (RFC 6749). While every effort has been made to ensure the accuracy of this translation, it may contain errors or discrepancies. For verification of the content and to ensure consistency with the original document, please refer to the original version.
Non-Commercial Use and Educational Purpose Statement:
This translated document is intended solely for educational purposes and is not to be used for any commercial purposes. The content of this translation is provided to facilitate learning and understanding of the original (RFC 6749) and should not be utilized in any commercial context.
translator : yevgeny hong, used google translator api
contact : hongyevgeny@gmail.com