draft-ietf-oauth-v2-1-00.txt   draft-ietf-oauth-v2-1-01.txt 
OAuth Working Group D. Hardt OAuth Working Group D. Hardt
Internet-Draft SignIn.Org Internet-Draft SignIn.Org
Intended status: Standards Track A. Parecki Intended status: Standards Track A. Parecki
Expires: 31 January 2021 Okta Expires: 5 August 2021 Okta
T. Lodderstedt T. Lodderstedt
yes.com yes.com
30 July 2020 1 February 2021
The OAuth 2.1 Authorization Framework The OAuth 2.1 Authorization Framework
draft-ietf-oauth-v2-1-00 draft-ietf-oauth-v2-1-01
Abstract Abstract
The OAuth 2.1 authorization framework enables a third-party The OAuth 2.1 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the between the resource owner and an authorization service, or by
third-party application to obtain access on its own behalf. This allowing the third-party application to obtain access on its own
specification replaces and obsoletes the OAuth 2.0 Authorization behalf. This specification replaces and obsoletes the OAuth 2.0
Framework described in RFC 6749. Authorization Framework described in RFC 6749.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 31 January 2021. This Internet-Draft will expire on 5 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 8 1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 8
1.3.1. Authorization Code . . . . . . . . . . . . . . . . . 8 1.3.1. Authorization Code . . . . . . . . . . . . . . . . . 8
1.3.2. Client Credentials . . . . . . . . . . . . . . . . . 8 1.3.2. Client Credentials . . . . . . . . . . . . . . . . . 9
1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9 1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 10
1.6. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 11 1.6. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 12
1.7. HTTP Redirections . . . . . . . . . . . . . . . . . . . . 11 1.7. HTTP Redirections . . . . . . . . . . . . . . . . . . . . 12
1.8. Interoperability . . . . . . . . . . . . . . . . . . . . 11 1.8. Interoperability . . . . . . . . . . . . . . . . . . . . 12
1.9. Notational Conventions . . . . . . . . . . . . . . . . . 12 1.9. Compatibility with OAuth 2.0 . . . . . . . . . . . . . . 13
2. Client Registration . . . . . . . . . . . . . . . . . . . . . 12 1.10. Notational Conventions . . . . . . . . . . . . . . . . . 13
2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 13 2. Client Registration . . . . . . . . . . . . . . . . . . . . . 14
2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 14 2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Client Authentication . . . . . . . . . . . . . . . . . . 15 2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 16
2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 15 2.3. Client Authentication . . . . . . . . . . . . . . . . . . 16
2.3.2. Other Authentication Methods . . . . . . . . . . . . 16 2.3.1. Client Password . . . . . . . . . . . . . . . . . . . 17
2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 17 2.3.2. Other Authentication Methods . . . . . . . . . . . . 18
3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . 17 2.4. Unregistered Clients . . . . . . . . . . . . . . . . . . 18
3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 17 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . 18
3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 18 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 19
3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . 18 3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 19
3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . 20
3.2.1. Client Authentication . . . . . . . . . . . . . . . . 21 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 22
3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 21 3.2.1. Client Authentication . . . . . . . . . . . . . . . . 22
4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 22 3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 23
4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 22 4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 23
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24 4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 23
4.1.2. Authorization Response . . . . . . . . . . . . . . . 27 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 25
4.1.3. Access Token Request . . . . . . . . . . . . . . . . 30 4.1.2. Authorization Response . . . . . . . . . . . . . . . 28
4.1.4. Access Token Response . . . . . . . . . . . . . . . . 31 4.1.3. Access Token Request . . . . . . . . . . . . . . . . 31
4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 31 4.1.4. Access Token Response . . . . . . . . . . . . . . . . 32
4.2.1. Authorization Request and Response . . . . . . . . . 32 4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 33
4.2.2. Access Token Request . . . . . . . . . . . . . . . . 32 4.2.1. Authorization Request and Response . . . . . . . . . 33
4.2.3. Access Token Response . . . . . . . . . . . . . . . . 33 4.2.2. Access Token Request . . . . . . . . . . . . . . . . 33
4.3. Extension Grants . . . . . . . . . . . . . . . . . . . . 33 4.2.3. Access Token Response . . . . . . . . . . . . . . . . 34
5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 34 4.3. Extension Grants . . . . . . . . . . . . . . . . . . . . 34
5.1. Successful Response . . . . . . . . . . . . . . . . . . . 34 5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 35
5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 35 5.1. Successful Response . . . . . . . . . . . . . . . . . . . 35
6. Refreshing an Access Token . . . . . . . . . . . . . . . . . 37 5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 36
6.1. Refresh Token Protection . . . . . . . . . . . . . . . . 38
7. Accessing Protected Resources . . . . . . . . . . . . . . . . 40
7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 40
7.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 41
7.2.1. Authenticated Requests . . . . . . . . . . . . . . . 41
7.2.2. The WWW-Authenticate Response Header Field . . . . . 43
7.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 44
7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 45
7.3.1. Extension Token Types . . . . . . . . . . . . . . . . 45
7.4. Access Token Security Considerations . . . . . . . . . . 45
7.4.1. Security Threats . . . . . . . . . . . . . . . . . . 46
7.4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 46
7.4.3. Summary of Recommendations . . . . . . . . . . . . . 48
7.4.4. Token Replay Prevention . . . . . . . . . . . . . . . 49
7.4.5. Access Token Privilege Restriction . . . . . . . . . 50
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 50
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 50
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 51
8.3. Defining New Authorization Grant Types . . . . . . . . . 51
8.4. Defining New Authorization Endpoint Response Types . . . 51
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 52
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9.1. Client Authentication . . . . . . . . . . . . . . . . . . 53
9.1.1. Client Authentication of Native Apps . . . . . . . . 53
9.2. Registration of Native App Clients . . . . . . . . . . . 54
9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 54
9.3.1. Impersonation of Native Apps . . . . . . . . . . . . 55
9.4. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 55
9.4.1. Access Token Privilege Restriction . . . . . . . . . 56
9.4.2. Access Token Replay Prevention . . . . . . . . . . . 56
9.5. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 57
9.6. Client Impersonating Resource Owner . . . . . . . . . . . 57
9.7. Protecting Redirect-Based Flows . . . . . . . . . . . . . 58
9.7.1. Loopback Redirect Considerations in Native Apps . . . 58
9.7.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 59
9.8. Authorization Codes . . . . . . . . . . . . . . . . . . . 60
9.9. Request Confidentiality . . . . . . . . . . . . . . . . . 61
9.10. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 61
9.11. Credentials-Guessing Attacks . . . . . . . . . . . . . . 62
9.12. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 62
9.13. Fake External User-Agents in Native Apps . . . . . . . . 62
9.14. Malicious External User-Agents in Native Apps . . . . . . 63
9.15. Cross-Site Request Forgery . . . . . . . . . . . . . . . 63
9.16. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 64
9.17. Code Injection and Input Validation . . . . . . . . . . . 65
9.18. Open Redirectors . . . . . . . . . . . . . . . . . . . . 65
9.18.1. Client as Open Redirector . . . . . . . . . . . . . 65
9.18.2. Authorization Server as Open Redirector . . . . . . 65
9.19. Authorization Server Mix-Up Mitigation in Native Apps . . 66 6. Refreshing an Access Token . . . . . . . . . . . . . . . . . 38
9.20. Embedded User Agents in Native Apps . . . . . . . . . . . 66 6.1. Refresh Token Protection . . . . . . . . . . . . . . . . 39
9.21. Other Recommendations . . . . . . . . . . . . . . . . . . 67 7. Accessing Protected Resources . . . . . . . . . . . . . . . . 41
10. Native Applications . . . . . . . . . . . . . . . . . . . . . 67 7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 41
7.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 42
7.2.1. Authenticated Requests . . . . . . . . . . . . . . . 42
7.2.2. The WWW-Authenticate Response Header Field . . . . . 44
7.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 45
7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 46
7.3.1. Extension Token Types . . . . . . . . . . . . . . . . 46
7.4. Access Token Security Considerations . . . . . . . . . . 46
7.4.1. Security Threats . . . . . . . . . . . . . . . . . . 47
7.4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 47
7.4.3. Summary of Recommendations . . . . . . . . . . . . . 49
7.4.4. Token Replay Prevention . . . . . . . . . . . . . . . 50
7.4.5. Access Token Privilege Restriction . . . . . . . . . 51
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 51
8.1. Defining Access Token Types . . . . . . . . . . . . . . . 51
8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 52
8.3. Defining New Authorization Grant Types . . . . . . . . . 52
8.4. Defining New Authorization Endpoint Response Types . . . 52
8.5. Defining Additional Error Codes . . . . . . . . . . . . . 53
9. Security Considerations . . . . . . . . . . . . . . . . . . . 53
9.1. Client Authentication . . . . . . . . . . . . . . . . . . 54
9.1.1. Client Authentication of Native Apps . . . . . . . . 54
9.2. Registration of Native App Clients . . . . . . . . . . . 55
9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 55
9.3.1. Impersonation of Native Apps . . . . . . . . . . . . 56
9.4. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 56
9.4.1. Access Token Privilege Restriction . . . . . . . . . 57
9.4.2. Access Token Replay Prevention . . . . . . . . . . . 57
9.5. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 58
9.6. Client Impersonating Resource Owner . . . . . . . . . . . 58
9.7. Protecting Redirect-Based Flows . . . . . . . . . . . . . 59
9.7.1. Loopback Redirect Considerations in Native Apps . . . 59
9.7.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 60
9.8. Authorization Codes . . . . . . . . . . . . . . . . . . . 61
9.9. Request Confidentiality . . . . . . . . . . . . . . . . . 62
9.10. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 62
9.11. Credentials-Guessing Attacks . . . . . . . . . . . . . . 63
9.12. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 63
9.13. Fake External User-Agents in Native Apps . . . . . . . . 63
9.14. Malicious External User-Agents in Native Apps . . . . . . 64
9.15. Cross-Site Request Forgery . . . . . . . . . . . . . . . 64
9.16. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 65
9.17. Code Injection and Input Validation . . . . . . . . . . . 66
9.18. Open Redirectors . . . . . . . . . . . . . . . . . . . . 66
9.18.1. Client as Open Redirector . . . . . . . . . . . . . 66
9.18.2. Authorization Server as Open Redirector . . . . . . 66
9.19. Authorization Server Mix-Up Mitigation in Native Apps . . 67
9.20. Embedded User Agents in Native Apps . . . . . . . . . . . 67
9.21. Other Recommendations . . . . . . . . . . . . . . . . . . 68
10. Native Applications . . . . . . . . . . . . . . . . . . . . . 68
10.1. Using Inter-App URI Communication for OAuth in Native 10.1. Using Inter-App URI Communication for OAuth in Native
Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 69
10.2. Initiating the Authorization Request from a Native 10.2. Initiating the Authorization Request from a Native
App . . . . . . . . . . . . . . . . . . . . . . . . . . 69 App . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.3. Receiving the Authorization Response in a Native App . . 70 10.3. Receiving the Authorization Response in a Native App . . 71
10.3.1. Private-Use URI Scheme Redirection . . . . . . . . . 70 10.3.1. Private-Use URI Scheme Redirection . . . . . . . . . 71
10.3.2. Claimed "https" Scheme URI Redirection . . . . . . . 71 10.3.2. Claimed "https" Scheme URI Redirection . . . . . . . 72
10.3.3. Loopback Interface Redirection . . . . . . . . . . . 71 10.3.3. Loopback Interface Redirection . . . . . . . . . . . 72
11. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 72 11. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 73
12. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 72 12. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 73
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.1. Normative References . . . . . . . . . . . . . . . . . . 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 74
14.2. Informative References . . . . . . . . . . . . . . . . . 76 14.2. Informative References . . . . . . . . . . . . . . . . . 77
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 79 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 80
A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 79 A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 81
A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 79 A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 81
A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 80 A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 81
A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 80 A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 81
A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 80 A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 81
A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 80 A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 81
A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 80 A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 81
A.8. "error_description" Syntax . . . . . . . . . . . . . . . 80 A.8. "error_description" Syntax . . . . . . . . . . . . . . . 82
A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 81 A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 82
A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 81 A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 82
A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 81 A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 82
A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 81 A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 82
A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 81 A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 82
A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 81 A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 82
A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 81 A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 83
A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 82 A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 83
A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 82 A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 83
A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 82 A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 83
Appendix B. Use of application/x-www-form-urlencoded Media Appendix B. Use of application/x-www-form-urlencoded Media
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Appendix C. Extensions . . . . . . . . . . . . . . . . . . . . . 83 Appendix C. Extensions . . . . . . . . . . . . . . . . . . . . . 84
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 84 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
In the traditional client-server authentication model, the client In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with restricted resources, the resource owner shares its credentials with
the third party. This creates several problems and limitations: the third party. This creates several problems and limitations:
skipping to change at page 5, line 26 skipping to change at page 5, line 26
text. text.
* Servers are required to support password authentication, despite * Servers are required to support password authentication, despite
the security weaknesses inherent in passwords. the security weaknesses inherent in passwords.
* Third-party applications gain overly broad access to the resource * Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of ability to restrict duration or access to a limited subset of
resources. resources.
* Resource owners often reuse passwords with other unrelated
services, despite best security practices. This password reuse
means a vulnerability or exposure in one service may have security
implications in completely unrelated services.
* Resource owners cannot revoke access to an individual third party * Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by without revoking access to all third parties, and must do so by
changing the third party's password. changing the third party's password.
* Compromise of any third-party application results in compromise of * Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that the end-user's password and all of the data protected by that
password. password.
OAuth addresses these issues by introducing an authorization layer OAuth addresses these issues by introducing an authorization layer
and separating the role of the client from that of the resource and separating the role of the client from that of the resource
owner. In OAuth, the client requests access to resources controlled owner. In OAuth, the client requests access to resources controlled
by the resource owner and hosted by the resource server, and is by the resource owner and hosted by the resource server. Instead of
issued a different set of credentials than those of the resource using the resource owner's credentials to access protected resources,
owner. the client obtains an access token - a credential representing a
specific set of access attributes such as scope and lifetime. Access
Instead of using the resource owner's credentials to access protected tokens are issued to clients by an authorization server with the
resources, the client obtains an access token - a string denoting a
specific scope, lifetime, and other access attributes. Access tokens
are issued to third-party clients by an authorization server with the
approval of the resource owner. The client uses the access token to approval of the resource owner. The client uses the access token to
access the protected resources hosted by the resource server. access the protected resources hosted by the resource server.
For example, an end-user (resource owner) can grant a printing For example, an end-user (resource owner) can grant a printing
service (client) access to her protected photos stored at a photo- service (client) access to their protected photos stored at a photo-
sharing service (resource server), without sharing her username and sharing service (resource server), without sharing their username and
password with the printing service. Instead, she authenticates password with the printing service. Instead, they authenticates
directly with a server trusted by the photo-sharing service directly with a server trusted by the photo-sharing service
(authorization server), which issues the printing service delegation- (authorization server), which issues the printing service delegation-
specific credentials (access token). specific credentials (access token).
This specification is designed for use with HTTP ([RFC7230]). The This specification is designed for use with HTTP ([RFC7230]). The
use of OAuth over any protocol other than HTTP is out of scope. use of OAuth over any protocol other than HTTP is out of scope.
Since the publication of the OAuth 2.0 Authorization Framework Since the publication of the OAuth 2.0 Authorization Framework
([RFC6749]) in October 2012, it has been updated by OAuth 2.0 for ([RFC6749]) in October 2012, it has been updated by OAuth 2.0 for
Native Apps ([RFC8252]), OAuth Security Best Current Practice Native Apps ([RFC8252]), OAuth Security Best Current Practice
skipping to change at page 6, line 38 skipping to change at page 6, line 34
OAuth defines four roles: OAuth defines four roles:
"resource owner": An entity capable of granting access to a "resource owner": An entity capable of granting access to a
protected resource. When the resource owner is a person, it is protected resource. When the resource owner is a person, it is
referred to as an end-user. This is sometimes abbreviated as referred to as an end-user. This is sometimes abbreviated as
"RO". "RO".
"resource server": The server hosting the protected resources, "resource server": The server hosting the protected resources,
capable of accepting and responding to protected resource requests capable of accepting and responding to protected resource requests
using access tokens. This is sometimes abbreviated as "RS". using access tokens. The resource server is often accessible via
an API. This is sometimes abbreviated as "RS".
"client": An application making protected resource requests on "client": An application making protected resource requests on
behalf of the resource owner and with its authorization. The term behalf of the resource owner and with its authorization. The term
"client" does not imply any particular implementation "client" does not imply any particular implementation
characteristics (e.g., whether the application executes on a characteristics (e.g., whether the application executes on a
server, a desktop, or other devices). server, a desktop, or other devices).
"authorization server": The server issuing access tokens to the "authorization server": The server issuing access tokens to the
client after successfully authenticating the resource owner and client after successfully authenticating the resource owner and
obtaining authorization. This is sometimes abbreviated as "AS". obtaining authorization. This is sometimes abbreviated as "AS".
skipping to change at page 7, line 41 skipping to change at page 7, line 45
The abstract OAuth 2.1 flow illustrated in Figure 1 describes the The abstract OAuth 2.1 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps: interaction between the four roles and includes the following steps:
1. The client requests authorization from the resource owner. The 1. The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via the authorization server (as shown), or preferably indirectly via the authorization server
as an intermediary. as an intermediary.
2. The client receives an authorization grant, which is a credential 2. The client receives an authorization grant, which is a credential
representing the resource owner's authorization, expressed using representing the resource owner's authorization, expressed using
one of two grant types defined in this specification or using an one of two authorization grant types defined in this
extension grant type. The authorization grant type depends on specification or using an extension grant type. The
the method used by the client to request authorization and the authorization grant type depends on the method used by the client
types supported by the authorization server. to request authorization and the types supported by the
authorization server.
3. The client requests an access token by authenticating with the 3. The client requests an access token by authenticating with the
authorization server and presenting the authorization grant. authorization server and presenting the authorization grant.
4. The authorization server authenticates the client and validates 4. The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token. the authorization grant, and if valid, issues an access token.
5. The client requests the protected resource from the resource 5. The client requests the protected resource from the resource
server and authenticates by presenting the access token. server and authenticates by presenting the access token.
skipping to change at page 8, line 26 skipping to change at page 8, line 29
1.3. Authorization Grant 1.3. Authorization Grant
An authorization grant is a credential representing the resource An authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the owner's authorization (to access its protected resources) used by the
client to obtain an access token. This specification defines two client to obtain an access token. This specification defines two
grant types - authorization code and client credentials - as well as grant types - authorization code and client credentials - as well as
an extensibility mechanism for defining additional types. an extensibility mechanism for defining additional types.
1.3.1. Authorization Code 1.3.1. Authorization Code
The authorization code is obtained by using an authorization server An authorization code is a temporary credential used to obtain an
as an intermediary between the client and resource owner. Instead of access token. Instead of the client requesting authorization
requesting authorization directly from the resource owner, the client directly from the resource owner, the client directs the resource
directs the resource owner to an authorization server (via its user- owner to an authorization server (via its user-agent as defined in
agent as defined in [RFC7231]), which in turn directs the resource [RFC7231]), which in turn directs the resource owner back to the
owner back to the client with the authorization code. client with the authorization code. The client can then exchange the
authorization code for an access token.
Before directing the resource owner back to the client with the Before directing the resource owner back to the client with the
authorization code, the authorization server authenticates the authorization code, the authorization server authenticates the
resource owner and obtains authorization. Because the resource owner resource owner, and may request the resource owner's consent or
only authenticates with the authorization server, the resource otherwise inform them of the client's request. Because the resource
owner's credentials are never shared with the client. owner only authenticates with the authorization server, the resource
owner's credentials are never shared with the client, and the client
does not need to have knowledge of any additional authentication
steps such as multi-factor authentication or delegated accounts.
The authorization code provides a few important security benefits, The authorization code provides a few important security benefits,
such as the ability to authenticate the client, as well as the such as the ability to authenticate the client, as well as the
transmission of the access token directly to the client without transmission of the access token directly to the client without
passing it through the resource owner's user-agent and potentially passing it through the resource owner's user-agent and potentially
exposing it to others, including the resource owner. exposing it to others, including the resource owner.
1.3.2. Client Credentials 1.3.2. Client Credentials
The client credentials (or other forms of client authentication) can The client credentials or other forms of client authentication (e.g.
be used as an authorization grant when the authorization scope is a "client_secret" or a private key used to sign a JWT) can be used as
limited to the protected resources under the control of the client, an authorization grant when the authorization scope is limited to the
or to protected resources previously arranged with the authorization protected resources under the control of the client, or to protected
server. Client credentials are used as an authorization grant resources previously arranged with the authorization server. Client
typically when the client is acting on its own behalf (the client is credentials are used as an authorization grant typically when the
also the resource owner) or is requesting access to protected client is acting on its own behalf (the client is also the resource
resources based on an authorization previously arranged with the owner) or is requesting access to protected resources based on an
authorization server. authorization previously arranged with the authorization server.
1.4. Access Token 1.4. Access Token
Access tokens are credentials used to access protected resources. An Access tokens are credentials used to access protected resources. An
access token is a string representing an authorization issued to the access token is a string representing an authorization issued to the
client. The string is opaque to the client, but depending on the client. The string is considered opaque to the client, even if it
authorization server, may be parseable by the resource server. has a structure. Depending on the authorization server, the access
token string may be parseable by the resource server.
Tokens represent specific scopes and durations of access, granted by Access tokens represent specific scopes and durations of access,
the resource owner, and enforced by the resource server and granted by the resource owner, and enforced by the resource server
authorization server. and authorization server.
The token may denote an identifier used to retrieve the authorization The token may be used by the RS to retrieve the authorization
information or may self-contain the authorization information in a information, or the token may self-contain the authorization
verifiable manner (i.e., a token string consisting of some data and a information in a verifiable manner (i.e., a token string consisting
signature). One example of a structured token format is of a signed data payload). One example of a token retrieval
mechanism is Token Introspection [RFC7662], in which the RS calls an
endpoint on the AS to validate the token presented by the client.
One example of a structured token format is
[I-D.ietf-oauth-access-token-jwt], a method of encoding access token [I-D.ietf-oauth-access-token-jwt], a method of encoding access token
data as a JSON Web Token [RFC7519]. data as a JSON Web Token [RFC7519].
Additional authentication credentials, which are beyond the scope of Additional authentication credentials, which are beyond the scope of
this specification, may be required in order for the client to use a this specification, may be required in order for the client to use an
token. This is typically referred to as a sender-constrained access access token. This is typically referred to as a sender-constrained
token, such as Mutual TLS Access Tokens [RFC8705]. access token, such as Mutual TLS Access Tokens [RFC8705].
The access token provides an abstraction layer, replacing different The access token provides an abstraction layer, replacing different
authorization constructs (e.g., username and password) with a single authorization constructs (e.g., username and password) with a single
token understood by the resource server. This abstraction enables token understood by the resource server. This abstraction enables
issuing access tokens more restrictive than the authorization grant issuing access tokens more restrictive than the authorization grant
used to obtain them, as well as removing the resource server's need used to obtain them, as well as removing the resource server's need
to understand a wide range of authentication methods. to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of Access tokens can have different formats, structures, and methods of
utilization (e.g., cryptographic properties) based on the resource utilization (e.g., cryptographic properties) based on the resource
skipping to change at page 10, line 5 skipping to change at page 10, line 20
1.5. Refresh Token 1.5. Refresh Token
Refresh tokens are credentials used to obtain access tokens. Refresh Refresh tokens are credentials used to obtain access tokens. Refresh
tokens are issued to the client by the authorization server and are tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope (access tokens may have a shorter with identical or narrower scope (access tokens may have a shorter
lifetime and fewer permissions than authorized by the resource lifetime and fewer permissions than authorized by the resource
owner). Issuing a refresh token is optional at the discretion of the owner). Issuing a refresh token is optional at the discretion of the
authorization server. If the authorization server issues a refresh authorization server, and may be issued based on properties of the
token, it is included when issuing an access token (i.e., step (4) in client, properties of the request, policies within the authorization
Figure 2). server, or any other criteria. If the authorization server issues a
refresh token, it is included when issuing an access token (i.e.,
step (2) in Figure 2).
A refresh token is a string representing the authorization granted to A refresh token is a string representing the authorization granted to
the client by the resource owner. The string is usually opaque to the client by the resource owner. The string is considered opaque to
the client. The token denotes an identifier used to retrieve the the client. The refresh token may be an identifier used to retrieve
authorization information. Unlike access tokens, refresh tokens are the authorization information or may encode this information into the
intended for use only with authorization servers and are never sent string itself. Unlike access tokens, refresh tokens are intended for
to resource servers. use only with authorization servers and are never sent to resource
servers.
+--------+ +---------------+ +--------+ +---------------+
| |--(1)------- Authorization Grant --------->| | | |--(1)------- Authorization Grant --------->| |
| | | | | | | |
| |<-(2)----------- Access Token -------------| | | |<-(2)----------- Access Token -------------| |
| | & Refresh Token | | | | & Refresh Token | |
| | | | | | | |
| | +----------+ | | | | +----------+ | |
| |--(3)---- Access Token ---->| | | | | |--(3)---- Access Token ---->| | | |
| | | | | | | | | | | |
| |<-(4)- Protected Resource --| Resource | | Authorization | | |<-(4)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server | | Client | | Server | | Server |
| |--(5)---- Access Token ---->| | | | | |--(5)---- Access Token ---->| | | |
| | | | | | | | | | | |
| |<-(6)- Invalid Token Error -| | | | | |<-(6)- Invalid Token Error -| | | |
| | +----------+ | | | | +----------+ | |
| | | | | | | |
| |--(7)----------- Refresh Token ----------->| | | |--(7)----------- Refresh Token ----------->| |
| | | | | | | |
| |<-(8)----------- Access Token -------------| | | |<-(8)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+ +--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token Figure 2: Refreshing an Expired Access Token
The flow illustrated in Figure 2 includes the following steps: The flow illustrated in Figure 2 includes the following steps:
1. The client requests an access token by authenticating with the 1. The client requests an access token by authenticating with the
authorization server and presenting an authorization grant. authorization server and presenting an authorization grant.
2. The authorization server authenticates the client and validates 2. The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token and the authorization grant, and if valid, issues an access token and
optionally a refresh token. optionally a refresh token.
skipping to change at page 11, line 29 skipping to change at page 12, line 19
8. The authorization server authenticates the client and validates 8. The authorization server authenticates the client and validates
the refresh token, and if valid, issues a new access token (and, the refresh token, and if valid, issues a new access token (and,
optionally, a new refresh token). optionally, a new refresh token).
1.6. TLS Version 1.6. TLS Version
Whenever Transport Layer Security (TLS) is used by this Whenever Transport Layer Security (TLS) is used by this
specification, the appropriate version (or versions) of TLS will vary specification, the appropriate version (or versions) of TLS will vary
over time, based on the widespread deployment and known security over time, based on the widespread deployment and known security
vulnerabilities. At the time of this writing, TLS version 1.3 vulnerabilities. Refer to [BCP195] for up to date recommendations on
[RFC8446] is the most recent version. transport layer security.
Implementations MAY also support additional transport-layer security Implementations MAY also support additional transport-layer security
mechanisms that meet their security requirements. mechanisms that meet their security requirements.
1.7. HTTP Redirections 1.7. HTTP Redirections
This specification makes extensive use of HTTP redirections, in which This specification makes extensive use of HTTP redirections, in which
the client or the authorization server directs the resource owner's the client or the authorization server directs the resource owner's
user-agent to another destination. While the examples in this user-agent to another destination. While the examples in this
specification show the use of the HTTP 302 status code, any other specification show the use of the HTTP 302 status code, any other
skipping to change at page 12, line 9 skipping to change at page 12, line 44
1.8. Interoperability 1.8. Interoperability
OAuth 2.1 provides a rich authorization framework with well-defined OAuth 2.1 provides a rich authorization framework with well-defined
security properties. security properties.
This specification leaves a few required components partially or This specification leaves a few required components partially or
fully undefined (e.g., client registration, authorization server fully undefined (e.g., client registration, authorization server
capabilities, endpoint discovery). Some of these behaviors are capabilities, endpoint discovery). Some of these behaviors are
defined in optional extensions which implementations can choose to defined in optional extensions which implementations can choose to
use. use, such as:
* [RFC8414]: Authorization Server Metadata, defining an endpoint
clients can use to look up the information needed to interact with
a particular OAuth server
* [RFC7591]: Dynamic Client Registration, providing a mechanism for
programmatically registering clients with an authorization server
* [RFC7592]: Dynamic Client Management, providing a mechanism for
updating dynamically registered client information
* [RFC7662]: Token Introspection, defining a mechanism for resource
servers to obtain information about access tokens
Please refer to Appendix C for a list of current known extensions at Please refer to Appendix C for a list of current known extensions at
the time of this publication. the time of this publication.
1.9. Notational Conventions 1.9. Compatibility with OAuth 2.0
OAuth 2.1 is compatible with OAuth 2.0 with the extensions and
restrictions from known best current practices applied.
Specifically, features not specified in OAuth 2.0 core, such as PKCE,
are required in OAuth 2.1. Additionally, some features available in
OAuth 2.0, such as the Implicit or Resource Owner Credentials grant
types, are not specified in OAuth 2.1. Furthermore, some behaviors
allowed in OAuth 2.0 are restricted in OAuth 2.1, such as the strict
string matching of redirect URIs required by OAuth 2.1.
See Section 12 for more details on the differences from OAuth 2.0.
1.10. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. Additionally, the rule URI-reference is notation of [RFC5234]. Additionally, the rule URI-reference is
included from "Uniform Resource Identifier (URI): Generic Syntax" included from "Uniform Resource Identifier (URI): Generic Syntax"
[RFC3986]. [RFC3986].
Certain security-related terms are to be understood in the sense Certain security-related terms are to be understood in the sense
defined in [RFC4949]. These terms include, but are not limited to, defined in [RFC4949]. These terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate", "attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity", "sign", "confidentiality", "credential", "encryption", "identity", "sign",
"signature", "trust", "validate", and "verify". "signature", "trust", "validate", and "verify".
The term "payload" is to be interpreted as described in Section 3.3
of [RFC7231].
Unless otherwise noted, all the protocol parameter names and values Unless otherwise noted, all the protocol parameter names and values
are case sensitive. are case sensitive.
2. Client Registration 2. Client Registration
Before initiating the protocol, the client registers with the Before initiating the protocol, the client must establish its
authorization server. The means through which the client registers registration with the authorization server. The means through which
with the authorization server are beyond the scope of this the client registers with the authorization server are beyond the
specification but typically involve end-user interaction with an HTML scope of this specification but typically involve the client
registration form, or by using Dynamic Client Registration developer manually registering the client at the authorization
server's website after creating an account and agreeing to the
service's Terms of Service, or by using Dynamic Client Registration
([RFC7591]). ([RFC7591]).
Client registration does not require a direct interaction between the Client registration does not require a direct interaction between the
client and the authorization server. When supported by the client and the authorization server. When supported by the
authorization server, registration can rely on other means for authorization server, registration can rely on other means for
establishing trust and obtaining the required client properties establishing trust and obtaining the required client properties
(e.g., redirect URI, client type). For example, registration can be (e.g., redirect URI, client type). For example, registration can be
accomplished using a self-issued or third-party-issued assertion, or accomplished using a self-issued or third-party-issued assertion, or
by the authorization server performing client discovery using a by the authorization server performing client discovery using a
trusted channel. trusted channel.
skipping to change at page 15, line 7 skipping to change at page 16, line 34
The client identifier string size is left undefined by this The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size identifier size. The authorization server SHOULD document the size
of any identifier it issues. of any identifier it issues.
Authorization servers SHOULD NOT allow clients to choose or influence Authorization servers SHOULD NOT allow clients to choose or influence
their "client_id" value. See Section 9.6 for details. their "client_id" value. See Section 9.6 for details.
2.3. Client Authentication 2.3. Client Authentication
If the client has credentials, (is a confidential or credentialed If the client type is confidential, the client and authorization
client), the client and authorization server establish a client server establish a client authentication method suitable for the
authentication method suitable for the security requirements of the security requirements of the authorization server. The authorization
authorization server. The authorization server MAY accept any form server MAY accept any form of client authentication meeting its
of client authentication meeting its security requirements. security requirements.
Confidential and credentialed clients are typically issued (or Confidential clients are typically issued (or establish) a set of
establish) a set of client credentials used for authenticating with client credentials used for authenticating with the authorization
the authorization server (e.g., password, public/private key pair). server (e.g., password, public/private key pair).
Authorization servers SHOULD use client authentication if possible. Authorization servers SHOULD use client authentication if possible.
It is RECOMMENDED to use asymmetric (public-key based) methods for It is RECOMMENDED to use asymmetric (public-key based) methods for
client authentication such as mTLS [RFC8705] or "private_key_jwt" client authentication such as mTLS [RFC8705] or "private_key_jwt"
[OpenID]. When asymmetric methods for client authentication are [OpenID]. When asymmetric methods for client authentication are
used, authorization servers do not need to store sensitive symmetric used, authorization servers do not need to store sensitive symmetric
keys, making these methods more robust against a number of attacks. keys, making these methods more robust against a number of attacks.
The authorization server MAY establish a client authentication method The authorization server MAY establish a client authentication method
skipping to change at page 21, line 7 skipping to change at page 22, line 35
The client MUST use the HTTP "POST" method when making access token The client MUST use the HTTP "POST" method when making access token
requests. requests.
Parameters sent without a value MUST be treated as if they were Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore omitted from the request. The authorization server MUST ignore
unrecognized request parameters. Request and response parameters unrecognized request parameters. Request and response parameters
defined by this specification MUST NOT be included more than once. defined by this specification MUST NOT be included more than once.
3.2.1. Client Authentication 3.2.1. Client Authentication
Confidential or credentialed clients client MUST authenticate with Confidential clients or other clients issued client credentials MUST
the authorization server as described in Section 2.3 when making authenticate with the authorization server as described in
requests to the token endpoint. Client authentication is used for: Section 2.3 when making requests to the token endpoint. Client
authentication is used for:
* Enforcing the binding of refresh tokens and authorization codes to * Enforcing the binding of refresh tokens and authorization codes to
the client they were issued to. Client authentication is critical the client they were issued to. Client authentication is critical
when an authorization code is transmitted to the redirection when an authorization code is transmitted to the redirection
endpoint over an insecure channel. endpoint over an insecure channel.
* Recovering from a compromised client by disabling the client or * Recovering from a compromised client by disabling the client or
changing its credentials, thus preventing an attacker from abusing changing its credentials, thus preventing an attacker from abusing
stolen refresh tokens. Changing a single set of client stolen refresh tokens. Changing a single set of client
credentials is significantly faster than revoking an entire set of credentials is significantly faster than revoking an entire set of
skipping to change at page 22, line 16 skipping to change at page 23, line 44
authorization, the authorization server MUST either process the authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined). document its scope requirements and default value (if defined).
4. Obtaining Authorization 4. Obtaining Authorization
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner. The authorization is expressed in the form of an resource owner. The authorization is expressed in the form of an
authorization grant, which the client uses to request the access authorization grant, which the client uses to request the access
token. OAuth defines two grant types: authorization code and client token. OAuth defines two authorization grant types: authorization
credentials. It also provides an extension mechanism for defining code and client credentials. It also provides an extension mechanism
additional grant types. for defining additional grant types.
4.1. Authorization Code Grant 4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access The authorization code grant type is used to obtain both access
tokens and refresh tokens. tokens and refresh tokens.
Since this is a redirect-based flow, the client must be capable of Since this is a redirect-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection) browser) and capable of receiving incoming requests (via redirection)
from the authorization server. from the authorization server.
skipping to change at page 27, line 25 skipping to change at page 28, line 25
redirect URI using the "application/x-www-form-urlencoded" format, redirect URI using the "application/x-www-form-urlencoded" format,
per Appendix B: per Appendix B:
"code": REQUIRED. The authorization code generated by the "code": REQUIRED. The authorization code generated by the
authorization server. The authorization code MUST expire shortly authorization server. The authorization code MUST expire shortly
after it is issued to mitigate the risk of leaks. A maximum after it is issued to mitigate the risk of leaks. A maximum
authorization code lifetime of 10 minutes is RECOMMENDED. The authorization code lifetime of 10 minutes is RECOMMENDED. The
client MUST NOT use the authorization code more than once. If an client MUST NOT use the authorization code more than once. If an
authorization code is used more than once, the authorization authorization code is used more than once, the authorization
server MUST deny the request and SHOULD revoke (when possible) all server MUST deny the request and SHOULD revoke (when possible) all
tokens previously issued based on that authorization code. The access tokens and refresh tokens previously issued based on that
authorization code is bound to the client identifier and redirect authorization code. The authorization code is bound to the client
URI. identifier and redirect URI.
"state": REQUIRED if the "state" parameter was present in the client "state": REQUIRED if the "state" parameter was present in the client
authorization request. The exact value received from the client. authorization request. The exact value received from the client.
For example, the authorization server redirects the user-agent by For example, the authorization server redirects the user-agent by
sending the following HTTP response: sending the following HTTP response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz &state=xyz
skipping to change at page 30, line 10 skipping to change at page 31, line 10
sending the following HTTP response: sending the following HTTP response:
HTTP/1.1 302 Found HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz Location: https://client.example.com/cb?error=access_denied&state=xyz
4.1.3. Access Token Request 4.1.3. Access Token Request
The client makes a request to the token endpoint by sending the The client makes a request to the token endpoint by sending the
following parameters using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body: request payload:
"grant_type": REQUIRED. Value MUST be set to "authorization_code". "grant_type": REQUIRED. Value MUST be set to "authorization_code".
"code": REQUIRED. The authorization code received from the "code": REQUIRED. The authorization code received from the
authorization server. authorization server.
"redirect_uri": REQUIRED, if the "redirect_uri" parameter was "redirect_uri": REQUIRED, if the "redirect_uri" parameter was
included in the authorization request as described in included in the authorization request as described in
Section 4.1.1, and their values MUST be identical. Section 4.1.1, and their values MUST be identical.
"client_id": REQUIRED, if the client is not authenticating with the "client_id": REQUIRED, if the client is not authenticating with the
authorization server as described in Section 3.2.1. authorization server as described in Section 3.2.1.
"code_verifier": REQUIRED, if the "code_challenge" parameter was "code_verifier": REQUIRED, if the "code_challenge" parameter was
included in the authorization request. MUST NOT be used included in the authorization request. MUST NOT be used
otherwise. The original code verifier string. otherwise. The original code verifier string.
Confidential or credentialed clients MUST authenticate with the If the client type is confidential or the client was issued client
authorization server as described in Section 3.2.1. credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
For example, the client makes the following HTTP request using TLS For example, the client makes the following HTTP request using TLS
(with extra line breaks for display purposes only): (with extra line breaks for display purposes only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed &code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed
The authorization server MUST: The authorization server MUST:
* require client authentication for confidential and credentialed * require client authentication for confidential clients or for any
clients (or clients with other authentication requirements), client that was issued client credentials (or with other
authentication requirements),
* authenticate the client if client authentication is included, * authenticate the client if client authentication is included,
* ensure that the authorization code was issued to the authenticated * ensure that the authorization code was issued to the authenticated
confidential or credentialed client, or if the client is public, confidential client, or if the client is public, ensure that the
ensure that the code was issued to "client_id" in the request, code was issued to "client_id" in the request,
* verify that the authorization code is valid, * verify that the authorization code is valid,
* verify that the "code_verifier" parameter is present if and only * verify that the "code_verifier" parameter is present if and only
if a "code_challenge" parameter was present in the authorization if a "code_challenge" parameter was present in the authorization
request, request,
* if a "code_verifier" is present, verify the "code_verifier" by * if a "code_verifier" is present, verify the "code_verifier" by
calculating the code challenge from the received "code_verifier" calculating the code challenge from the received "code_verifier"
and comparing it with the previously associated "code_challenge", and comparing it with the previously associated "code_challenge",
skipping to change at page 32, line 6 skipping to change at page 33, line 15
4.2. Client Credentials Grant 4.2. Client Credentials Grant
The client can request an access token using only its client The client can request an access token using only its client
credentials (or other supported means of authentication) when the credentials (or other supported means of authentication) when the
client is requesting access to the protected resources under its client is requesting access to the protected resources under its
control, or those of another resource owner that have been previously control, or those of another resource owner that have been previously
arranged with the authorization server (the method of which is beyond arranged with the authorization server (the method of which is beyond
the scope of this specification). the scope of this specification).
The client credentials grant type MUST only be used by confidential The client credentials grant type MUST only be used by confidential
or credentialed clients. clients.
+---------+ +---------------+ +---------+ +---------------+
| | | | | | | |
| |>--(1)- Client Authentication --->| Authorization | | |>--(1)- Client Authentication --->| Authorization |
| Client | | Server | | Client | | Server |
| |<--(2)---- Access Token ---------<| | | |<--(2)---- Access Token ---------<| |
| | | | | | | |
+---------+ +---------------+ +---------+ +---------------+
Figure 4: Client Credentials Flow Figure 4: Client Credentials Flow
skipping to change at page 32, line 36 skipping to change at page 33, line 45
4.2.1. Authorization Request and Response 4.2.1. Authorization Request and Response
Since the client authentication is used as the authorization grant, Since the client authentication is used as the authorization grant,
no additional authorization request is needed. no additional authorization request is needed.
4.2.2. Access Token Request 4.2.2. Access Token Request
The client makes a request to the token endpoint by adding the The client makes a request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body: request payload:
"grant_type": REQUIRED. Value MUST be set to "client_credentials". "grant_type": REQUIRED. Value MUST be set to "client_credentials".
"scope": OPTIONAL. The scope of the access request as described by "scope": OPTIONAL. The scope of the access request as described by
Section 3.3. Section 3.3.
The client MUST authenticate with the authorization server as The client MUST authenticate with the authorization server as
described in Section 3.2.1. described in Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
skipping to change at page 34, line 31 skipping to change at page 35, line 37
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optional refresh authorization server issues an access token and optional refresh
token as described in Section 5.1. If the request failed client token as described in Section 5.1. If the request failed client
authentication or is invalid, the authorization server returns an authentication or is invalid, the authorization server returns an
error response as described in Section 5.2. error response as described in Section 5.2.
5.1. Successful Response 5.1. Successful Response
The authorization server issues an access token and optional refresh The authorization server issues an access token and optional refresh
token, and constructs the response by adding the following parameters token, and constructs the response by adding the following parameters
to the entity-body of the HTTP response with a 200 (OK) status code: to the payload of the HTTP response with a 200 (OK) status code:
"access_token": REQUIRED. The access token issued by the "access_token": REQUIRED. The access token issued by the
authorization server. authorization server.
"token_type": REQUIRED. The type of the token issued as described "token_type": REQUIRED. The type of the access token issued as
in Section 7.1. Value is case insensitive. described in Section 7.1. Value is case insensitive.
"expires_in": RECOMMENDED. The lifetime in seconds of the access "expires_in": RECOMMENDED. The lifetime in seconds of the access
token. For example, the value "3600" denotes that the access token. For example, the value "3600" denotes that the access
token will expire in one hour from the time the response was token will expire in one hour from the time the response was
generated. If omitted, the authorization server SHOULD provide generated. If omitted, the authorization server SHOULD provide
the expiration time via other means or document the default value. the expiration time via other means or document the default value.
"refresh_token": OPTIONAL. The refresh token, which can be used to "refresh_token": OPTIONAL. The refresh token, which can be used to
obtain new access tokens using the same authorization grant as obtain new access tokens using the same authorization grant as
described in Section 6. described in Section 6.
"scope": OPTIONAL, if identical to the scope requested by the "scope": OPTIONAL, if identical to the scope requested by the
client; otherwise, REQUIRED. The scope of the access token as client; otherwise, REQUIRED. The scope of the access token as
described by Section 3.3. described by Section 3.3.
The parameters are included in the entity-body of the HTTP response The parameters are included in the payload of the HTTP response using
using the "application/json" media type as defined by [RFC7159]. The the "application/json" media type as defined by [RFC7159]. The
parameters are serialized into a JavaScript Object Notation (JSON) parameters are serialized into a JavaScript Object Notation (JSON)
structure by adding each parameter at the highest structure level. structure by adding each parameter at the highest structure level.
Parameter names and string values are included as JSON strings. Parameter names and string values are included as JSON strings.
Numerical values are included as JSON numbers. The order of Numerical values are included as JSON numbers. The order of
parameters does not matter and can vary. parameters does not matter and can vary.
The authorization server MUST include the HTTP "Cache-Control" The authorization server MUST include the HTTP "Cache-Control"
response header field [RFC7234] with a value of "no-store" in any response header field [RFC7234] with a value of "no-store" in any
response containing tokens, credentials, or other sensitive response containing tokens, credentials, or other sensitive
information, as well as the "Pragma" response header field [RFC7234] information, as well as the "Pragma" response header field [RFC7234]
skipping to change at page 37, line 5 skipping to change at page 38, line 10
the "error_description" parameter MUST NOT include characters the "error_description" parameter MUST NOT include characters
outside the set %x20-21 / %x23-5B / %x5D-7E. outside the set %x20-21 / %x23-5B / %x5D-7E.
"error_uri": OPTIONAL. A URI identifying a human-readable web page "error_uri": OPTIONAL. A URI identifying a human-readable web page
with information about the error, used to provide the client with information about the error, used to provide the client
developer with additional information about the error. Values for developer with additional information about the error. Values for
the "error_uri" parameter MUST conform to the URI-reference syntax the "error_uri" parameter MUST conform to the URI-reference syntax
and thus MUST NOT include characters outside the set %x21 / and thus MUST NOT include characters outside the set %x21 /
%x23-5B / %x5D-7E. %x23-5B / %x5D-7E.
The parameters are included in the entity-body of the HTTP response The parameters are included in the payload of the HTTP response using
using the "application/json" media type as defined by [RFC7159]. The the "application/json" media type as defined by [RFC7159]. The
parameters are serialized into a JSON structure by adding each parameters are serialized into a JSON structure by adding each
parameter at the highest structure level. Parameter names and string parameter at the highest structure level. Parameter names and string
values are included as JSON strings. Numerical values are included values are included as JSON strings. Numerical values are included
as JSON numbers. The order of parameters does not matter and can as JSON numbers. The order of parameters does not matter and can
vary. vary.
For example: For example:
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Type: application/json Content-Type: application/json
skipping to change at page 37, line 43 skipping to change at page 38, line 48
If refresh tokens are issued, those refresh tokens MUST be bound to If refresh tokens are issued, those refresh tokens MUST be bound to
the scope and resource servers as consented by the resource owner. the scope and resource servers as consented by the resource owner.
This is to prevent privilege escalation by the legitimate client and This is to prevent privilege escalation by the legitimate client and
reduce the impact of refresh token leakage. reduce the impact of refresh token leakage.
If the authorization server issued a refresh token to the client, the If the authorization server issued a refresh token to the client, the
client makes a refresh request to the token endpoint by adding the client makes a refresh request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded" following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body: request payload:
"grant_type": REQUIRED. Value MUST be set to "refresh_token". "grant_type": REQUIRED. Value MUST be set to "refresh_token".
"refresh_token": REQUIRED. The refresh token issued to the client. "refresh_token": REQUIRED. The refresh token issued to the client.
"scope": OPTIONAL. The scope of the access request as described by "scope": OPTIONAL. The scope of the access request as described by
Section 3.3. The requested scope MUST NOT include any scope not Section 3.3. The requested scope MUST NOT include any scope not
originally granted by the resource owner, and if omitted is originally granted by the resource owner, and if omitted is
treated as equal to the scope originally granted by the resource treated as equal to the scope originally granted by the resource
owner. owner.
Because refresh tokens are typically long-lasting credentials used to Because refresh tokens are typically long-lasting credentials used to
request additional access tokens, the refresh token is bound to the request additional access tokens, the refresh token is bound to the
client to which it was issued. Confidential or credentialed clients client to which it was issued. If the client type is confidential or
MUST authenticate with the authorization server as described in the client was issued client credentials (or assigned other
Section 3.2.1. authentication requirements), the client MUST authenticate with the
authorization server as described in Section 3.2.1.
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
transport-layer security (with extra line breaks for display purposes transport-layer security (with extra line breaks for display purposes
only): only):
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
The authorization server MUST: The authorization server MUST:
* require client authentication for confidential or credentialed * require client authentication for confidential clients or for any
clients client that was issued client credentials (or with other
authentication requirements),
* authenticate the client if client authentication is included and * authenticate the client if client authentication is included and
ensure that the refresh token was issued to the authenticated ensure that the refresh token was issued to the authenticated
client, and client, and
* validate the refresh token. * validate the refresh token.
6.1. Refresh Token Protection 6.1. Refresh Token Protection
Authorization servers SHOULD utilize one of these methods to detect Authorization servers SHOULD utilize one of these methods to detect
skipping to change at page 42, line 7 skipping to change at page 43, line 7
b64token = 1*( ALPHA / DIGIT / b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"=" "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token credentials = "Bearer" 1*SP b64token
Clients SHOULD make authenticated requests with a bearer token using Clients SHOULD make authenticated requests with a bearer token using
the "Authorization" request header field with the "Bearer" HTTP the "Authorization" request header field with the "Bearer" HTTP
authorization scheme. Resource servers MUST support this method. authorization scheme. Resource servers MUST support this method.
7.2.1.2. Form-Encoded Body Parameter 7.2.1.2. Form-Encoded Body Parameter
When sending the access token in the HTTP request entity-body, the When sending the access token in the HTTP request payload, the client
client adds the access token to the request-body using the adds the access token to the request-body using the "access_token"
"access_token" parameter. The client MUST NOT use this method unless parameter. The client MUST NOT use this method unless all of the
all of the following conditions are met: following conditions are met:
* The HTTP request entity-header includes the "Content-Type" header * The HTTP request entity-header includes the "Content-Type" header
field set to "application/x-www-form-urlencoded". field set to "application/x-www-form-urlencoded".
* The entity-body follows the encoding requirements of the * The payload follows the encoding requirements of the "application/
"application/x-www-form-urlencoded" content-type as defined by x-www-form-urlencoded" content-type as defined by HTML 4.01
HTML 4.01 [W3C.REC-html401-19991224]. [W3C.REC-html401-19991224].
* The HTTP request entity-body is single-part. * The HTTP request payload is single-part.
* The content to be encoded in the entity-body MUST consist entirely * The content to be encoded in the payload MUST consist entirely of
of ASCII [USASCII] characters. ASCII [USASCII] characters.
* The HTTP request method is one for which the request-body has * The HTTP request method is one for which the request-body has
defined semantics. In particular, this means that the "GET" defined semantics. In particular, this means that the "GET"
method MUST NOT be used. method MUST NOT be used.
The entity-body MAY include other request-specific parameters, in The payload MAY include other request-specific parameters, in which
which case the "access_token" parameter MUST be properly separated case the "access_token" parameter MUST be properly separated from the
from the request-specific parameters using "&" character(s) (ASCII request-specific parameters using "&" character(s) (ASCII code 38).
code 38).
For example, the client makes the following HTTP request using For example, the client makes the following HTTP request using
transport-layer security: transport-layer security:
POST /resource HTTP/1.1 POST /resource HTTP/1.1
Host: server.example.com Host: server.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
access_token=mF_9.B5f-4.1JqM access_token=mF_9.B5f-4.1JqM
skipping to change at page 49, line 7 skipping to change at page 50, line 7
7.4.3.4. Don't store bearer tokens in HTTP cookies 7.4.3.4. Don't store bearer tokens in HTTP cookies
Implementations MUST NOT store bearer tokens within cookies that can Implementations MUST NOT store bearer tokens within cookies that can
be sent in the clear (which is the default transmission mode for be sent in the clear (which is the default transmission mode for
cookies). Implementations that do store bearer tokens in cookies cookies). Implementations that do store bearer tokens in cookies
MUST take precautions against cross-site request forgery. MUST take precautions against cross-site request forgery.
7.4.3.5. Issue short-lived bearer tokens 7.4.3.5. Issue short-lived bearer tokens
Token servers SHOULD issue short-lived (one hour or less) bearer Authorization servers SHOULD issue short-lived (one hour or less)
tokens, particularly when issuing tokens to clients that run within a bearer tokens, particularly when issuing tokens to clients that run
web browser or other environments where information leakage may within a web browser or other environments where information leakage
occur. Using short-lived bearer tokens can reduce the impact of them may occur. Using short-lived bearer tokens can reduce the impact of
being leaked. them being leaked.
7.4.3.6. Issue scoped bearer tokens 7.4.3.6. Issue scoped bearer tokens
Token servers SHOULD issue bearer tokens that contain an audience Authorization servers SHOULD issue bearer tokens that contain an
restriction, scoping their use to the intended relying party or set audience restriction, scoping their use to the intended relying party
of relying parties. or set of relying parties.
7.4.3.7. Don't pass bearer tokens in page URLs 7.4.3.7. Don't pass bearer tokens in page URLs
Bearer tokens MUST NOT be passed in page URLs (for example, as query Bearer tokens MUST NOT be passed in page URLs (for example, as query
string parameters). Instead, bearer tokens SHOULD be passed in HTTP string parameters). Instead, bearer tokens SHOULD be passed in HTTP
message headers or message bodies for which confidentiality measures message headers or message bodies for which confidentiality measures
are taken. Browsers, web servers, and other software may not are taken. Browsers, web servers, and other software may not
adequately secure URLs in the browser history, web server logs, and adequately secure URLs in the browser history, web server logs, and
other data structures. If bearer tokens are passed in page URLs, other data structures. If bearer tokens are passed in page URLs,
attackers might be able to steal them from the history data, logs, or attackers might be able to steal them from the history data, logs, or
other unsecured locations. other unsecured locations.
7.4.4. Token Replay Prevention 7.4.4. Token Replay Prevention
A sender-constrained access token scopes the applicability of an A sender-constrained access token scopes the applicability of an
access token to a certain sender. This sender is obliged to access token to a certain sender. This sender is obliged to
demonstrate knowledge of a certain secret as prerequisite for the demonstrate knowledge of a certain secret as prerequisite for the
acceptance of that token at the recipient (e.g., a resource server). acceptance of that access token at the recipient (e.g., a resource
server).
Authorization and resource servers SHOULD use mechanisms for sender- Authorization and resource servers SHOULD use mechanisms for sender-
constrained access tokens to prevent token replay as described in constrained access tokens to prevent token replay as described in
Section 4.8.1.1.2 of [I-D.ietf-oauth-security-topics]. The use of Section 4.8.1.1.2 of [I-D.ietf-oauth-security-topics]. The use of
Mutual TLS for OAuth 2.0 [RFC8705] is RECOMMENDED. Mutual TLS for OAuth 2.0 [RFC8705] is RECOMMENDED.
It is RECOMMENDED to use end-to-end TLS. If TLS traffic needs to be It is RECOMMENDED to use end-to-end TLS. If TLS traffic needs to be
terminated at an intermediary, refer to Section 4.11 of terminated at an intermediary, refer to Section 4.11 of
[I-D.ietf-oauth-security-topics] for further security advice. [I-D.ietf-oauth-security-topics] for further security advice.
skipping to change at page 57, line 5 skipping to change at page 58, line 5
serve the respective request. Clients and authorization servers MAY serve the respective request. Clients and authorization servers MAY
utilize the parameter "scope" and "authorization_details" as utilize the parameter "scope" and "authorization_details" as
specified in [I-D.ietf-oauth-rar] to determine those resources and/or specified in [I-D.ietf-oauth-rar] to determine those resources and/or
actions. actions.
Authorization and resource servers SHOULD use mechanisms for sender- Authorization and resource servers SHOULD use mechanisms for sender-
constrained access tokens to prevent token replay as described in constrained access tokens to prevent token replay as described in
(#pop_tokens). A sender-constrained access token scopes the (#pop_tokens). A sender-constrained access token scopes the
applicability of an access token to a certain sender. This sender is applicability of an access token to a certain sender. This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite obliged to demonstrate knowledge of a certain secret as prerequisite
for the acceptance of that token at the recipient (e.g., a resource for the acceptance of that access token at the recipient (e.g., a
server). The use of Mutual TLS for OAuth 2.0 [RFC8705] is resource server). The use of Mutual TLS for OAuth 2.0 [RFC8705] is
RECOMMENDED. RECOMMENDED.
9.5. Refresh Tokens 9.5. Refresh Tokens
Authorization servers MAY issue refresh tokens to clients. Authorization servers MAY issue refresh tokens to clients.
Refresh tokens MUST be kept confidential in transit and storage, and Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was the binding between a refresh token and the client to whom it was
skipping to change at page 58, line 36 skipping to change at page 59, line 36
carried in the "state" parameter that are securely bound to the user carried in the "state" parameter that are securely bound to the user
agent MUST be used for CSRF protection (see (#csrf_countermeasures)). agent MUST be used for CSRF protection (see (#csrf_countermeasures)).
In order to prevent mix-up attacks (see (#mix_up)), clients MUST only In order to prevent mix-up attacks (see (#mix_up)), clients MUST only
process redirect responses of the authorization server they sent the process redirect responses of the authorization server they sent the
respective request to and from the same user agent this authorization respective request to and from the same user agent this authorization
request was initiated with. Clients MUST store the authorization request was initiated with. Clients MUST store the authorization
server they sent an authorization request to and bind this server they sent an authorization request to and bind this
information to the user agent and check that the authorization information to the user agent and check that the authorization
request was received from the correct authorization server. Clients request was received from the correct authorization server. Clients
MUST ensure that the subsequent token request, if applicable, is sent MUST ensure that the subsequent access token request, if applicable,
to the same authorization server. Clients SHOULD use distinct is sent to the same authorization server. Clients SHOULD use
redirect URIs for each authorization server as a means to identify distinct redirect URIs for each authorization server as a means to
the authorization server a particular response came from. identify the authorization server a particular response came from.
An AS that redirects a request potentially containing user An AS that redirects a request potentially containing user
credentials MUST avoid forwarding these user credentials accidentally credentials MUST avoid forwarding these user credentials accidentally
(see Section 9.7.2 for details). (see Section 9.7.2 for details).
9.7.1. Loopback Redirect Considerations in Native Apps 9.7.1. Loopback Redirect Considerations in Native Apps
Loopback interface redirect URIs use the "http" scheme (i.e., without Loopback interface redirect URIs use the "http" scheme (i.e., without
Transport Layer Security (TLS)). This is acceptable for loopback Transport Layer Security (TLS)). This is acceptable for loopback
interface redirect URIs as the HTTP request never leaves the device. interface redirect URIs as the HTTP request never leaves the device.
skipping to change at page 59, line 25 skipping to change at page 60, line 25
resolution on the user's device. resolution on the user's device.
9.7.2. HTTP 307 Redirect 9.7.2. HTTP 307 Redirect
An AS which redirects a request that potentially contains user An AS which redirects a request that potentially contains user
credentials MUST NOT use the HTTP 307 status code for redirection. credentials MUST NOT use the HTTP 307 status code for redirection.
If an HTTP redirection (and not, for example, JavaScript) is used for If an HTTP redirection (and not, for example, JavaScript) is used for
such a request, AS SHOULD use HTTP status code 303 "See Other". such a request, AS SHOULD use HTTP status code 303 "See Other".
At the authorization endpoint, a typical protocol flow is that the AS At the authorization endpoint, a typical protocol flow is that the AS
prompts the user to enter her credentials in a form that is then prompts the user to enter their credentials in a form that is then
submitted (using the HTTP POST method) back to the authorization submitted (using the HTTP POST method) back to the authorization
server. The AS checks the credentials and, if successful, redirects server. The AS checks the credentials and, if successful, redirects
the user agent to the client's redirect URI. the user agent to the client's redirect URI.
If the status code 307 were used for redirection, the user agent If the status code 307 were used for redirection, the user agent
would send the user credentials via HTTP POST to the client. would send the user credentials via HTTP POST to the client.
This discloses the sensitive credentials to the client. If the This discloses the sensitive credentials to the client. If the
relying party is malicious, it can use the credentials to impersonate relying party is malicious, it can use the credentials to impersonate
the user at the AS. the user at the AS.
skipping to change at page 60, line 30 skipping to change at page 61, line 30
If the client can be authenticated, the authorization servers MUST If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was authenticate the client and ensure that the authorization code was
issued to the same client. issued to the same client.
Clients MUST prevent injection (replay) of authorization codes into Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. To this end, using the authorization response by attackers. To this end, using
"code_challenge" and "code_verifier" is REQUIRED for clients and "code_challenge" and "code_verifier" is REQUIRED for clients and
authorization servers MUST enforce their use, unless both of the authorization servers MUST enforce their use, unless both of the
following criteria are met: following criteria are met:
* The client is a confidential or credentialed client. * The client is a confidential client.
* In the specific deployment and the specific request, there is * In the specific deployment and the specific request, there is
reasonable assurance for authorization server that the client reasonable assurance for authorization server that the client
implements the OpenID Connect "nonce" mechanism properly. implements the OpenID Connect "nonce" mechanism properly.
In this case, using and enforcing "code_challenge" and In this case, using and enforcing "code_challenge" and
"code_verifier" is still RECOMMENDED. "code_verifier" is still RECOMMENDED.
The "code_challenge" or OpenID Connect "nonce" value MUST be The "code_challenge" or OpenID Connect "nonce" value MUST be
transaction-specific and securely bound to the client and the user transaction-specific and securely bound to the client and the user
skipping to change at page 73, line 40 skipping to change at page 74, line 40
This document does not require any IANA actions. This document does not require any IANA actions.
All referenced registries are defined by RFC6749 and related All referenced registries are defined by RFC6749 and related
documents that this work is based upon. No changes to those documents that this work is based upon. No changes to those
registries are required by this specification. registries are required by this specification.
14. References 14. References
14.1. Normative References 14.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS)", n.d..
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in "OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security- Progress, Internet-Draft, draft-ietf-oauth-security-
topics-15, 5 April 2020, <http://www.ietf.org/internet- topics-16, 5 October 2020, <http://www.ietf.org/internet-
drafts/draft-ietf-oauth-security-topics-15.txt>. drafts/draft-ietf-oauth-security-topics-16.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999, RFC 2617, DOI 10.17487/RFC2617, June 1999,
skipping to change at page 75, line 49 skipping to change at page 77, line 9
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[USASCII] Institute, A.N.S., "Coded Character Set -- 7-bit American [USASCII] Institute, A.N.S., "Coded Character Set -- 7-bit American
Standard Code for Information Interchange, ANSI X3.4", Standard Code for Information Interchange, ANSI X3.4",
1986. 1986.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, 24 December 1999, REC-html401-19991224, 24 December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <https://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, 26 November 2008, xml-20081126, 26 November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <https://www.w3.org/TR/2008/REC-xml-20081126>.
14.2. Informative References 14.2. Informative References
[CSP-2] "Content Security Policy Level 2", December 2016, [CSP-2] "Content Security Policy Level 2", December 2016,
<https://www.w3.org/TR/CSP2>. <https://www.w3.org/TR/CSP2>.
[I-D.bradley-oauth-jwt-encoded-state] [I-D.bradley-oauth-jwt-encoded-state]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT", Work claims in the OAuth 2 state parameter using a JWT", Work
in Progress, Internet-Draft, draft-bradley-oauth-jwt- in Progress, Internet-Draft, draft-bradley-oauth-jwt-
encoded-state-09, 4 November 2018, <http://www.ietf.org/ encoded-state-09, 4 November 2018, <http://www.ietf.org/
internet-drafts/draft-bradley-oauth-jwt-encoded-state- internet-drafts/draft-bradley-oauth-jwt-encoded-state-
09.txt>. 09.txt>.
[I-D.ietf-oauth-access-token-jwt] [I-D.ietf-oauth-access-token-jwt]
Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", Work in Progress, Internet-Draft, draft- Access Tokens", Work in Progress, Internet-Draft, draft-
ietf-oauth-access-token-jwt-07, 27 April 2020, ietf-oauth-access-token-jwt-11, 22 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-oauth- <http://www.ietf.org/internet-drafts/draft-ietf-oauth-
access-token-jwt-07.txt>. access-token-jwt-11.txt>.
[I-D.ietf-oauth-browser-based-apps] [I-D.ietf-oauth-browser-based-apps]
Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based
Apps", Work in Progress, Internet-Draft, draft-ietf-oauth- Apps", Work in Progress, Internet-Draft, draft-ietf-oauth-
browser-based-apps-06, 5 April 2020, <http://www.ietf.org/ browser-based-apps-07, 2 October 2020,
internet-drafts/draft-ietf-oauth-browser-based-apps- <http://www.ietf.org/internet-drafts/draft-ietf-oauth-
06.txt>. browser-based-apps-07.txt>.
[I-D.ietf-oauth-dpop] [I-D.ietf-oauth-dpop]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstration of Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof-
Proof-of-Possession at the Application Layer (DPoP)", Work of-Possession at the Application Layer (DPoP)", Work in
in Progress, Internet-Draft, draft-ietf-oauth-dpop-01, 1 Progress, Internet-Draft, draft-ietf-oauth-dpop-02, 18
May 2020, <http://www.ietf.org/internet-drafts/draft-ietf- November 2020, <http://www.ietf.org/internet-drafts/draft-
oauth-dpop-01.txt>. ietf-oauth-dpop-02.txt>.
[I-D.ietf-oauth-par] [I-D.ietf-oauth-par]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
Work in Progress, Internet-Draft, draft-ietf-oauth-par-02, Work in Progress, Internet-Draft, draft-ietf-oauth-par-05,
10 July 2020, <http://www.ietf.org/internet-drafts/draft- 14 December 2020, <http://www.ietf.org/internet-drafts/
ietf-oauth-par-02.txt>. draft-ietf-oauth-par-05.txt>.
[I-D.ietf-oauth-rar] [I-D.ietf-oauth-rar]
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", Work in Progress, Internet- Rich Authorization Requests", Work in Progress, Internet-
Draft, draft-ietf-oauth-rar-01, 19 February 2020, Draft, draft-ietf-oauth-rar-03, 18 October 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-oauth-rar- <http://www.ietf.org/internet-drafts/draft-ietf-oauth-rar-
01.txt>. 03.txt>.
[I-D.ietf-oauth-token-binding] [I-D.ietf-oauth-token-binding]
Jones, M., Campbell, B., Bradley, J., and W. Denniss, Jones, M., Campbell, B., Bradley, J., and W. Denniss,
"OAuth 2.0 Token Binding", Work in Progress, Internet- "OAuth 2.0 Token Binding", Work in Progress, Internet-
Draft, draft-ietf-oauth-token-binding-08, 19 October 2018, Draft, draft-ietf-oauth-token-binding-08, 19 October 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-oauth- <http://www.ietf.org/internet-drafts/draft-ietf-oauth-
token-binding-08.txt>. token-binding-08.txt>.
[NIST800-63] [NIST800-63]
Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T., Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T.,
skipping to change at page 83, line 45 skipping to change at page 85, line 4
location of the authorization and token endpoints and the location of the authorization and token endpoints and the
supported grant types. supported grant types.
* [RFC8707]: Resource Indicators * [RFC8707]: Resource Indicators
- Provides a way for the client to explicitly signal to the - Provides a way for the client to explicitly signal to the
authorization server where it intends to use the access token authorization server where it intends to use the access token
it is requesting. it is requesting.
* [RFC7591]: Dynamic Client Registration * [RFC7591]: Dynamic Client Registration
- Dynamic Client Registration provides a mechanism for - Dynamic Client Registration provides a mechanism for
programmatically registering clients with an authorization programmatically registering clients with an authorization
server. server.
* [RFC7592]: Dynamic Client Management * [RFC7592]: Dynamic Client Management
- Dynamic Client Management provides a mechanism for updating - Dynamic Client Management provides a mechanism for updating
dynamically registered client information. dynamically registered client information.
* [I-D.ietf-oauth-access-token-jwt]: JSON Web Token (JWT) Profile * [I-D.ietf-oauth-access-token-jwt]: JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens for OAuth 2.0 Access Tokens
- This specification defines a profile for issuing OAuth access - This specification defines a profile for issuing OAuth access
tokens in JSON web token (JWT) format. tokens in JSON Web Token (JWT) format.
* [RFC8705]: Mutual TLS * [RFC8705]: Mutual TLS
- Mutual TLS describes a mechanism of binding access tokens and - Mutual TLS describes a mechanism of binding access tokens and
refresh tokens to the clients they were issued to, as well as a refresh tokens to the clients they were issued to, as well as a
client authentication mechanism, via TLS certificate client authentication mechanism, via TLS certificate
authentication. authentication.
* [RFC7662]: Token Introspection * [RFC7662]: Token Introspection
 End of changes. 78 change blocks. 
307 lines changed or deleted 363 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/