draft-ietf-oauth-v2-1-04.txt   draft-ietf-oauth-v2-1-05.txt 
OAuth Working Group D. Hardt OAuth Working Group D. Hardt
Internet-Draft Hellō Internet-Draft Hellō
Intended status: Standards Track A. Parecki Intended status: Standards Track A. Parecki
Expires: 8 April 2022 Okta Expires: 8 September 2022 Okta
T. Lodderstedt T. Lodderstedt
yes.com yes.com
5 October 2021 7 March 2022
The OAuth 2.1 Authorization Framework The OAuth 2.1 Authorization Framework
draft-ietf-oauth-v2-1-04 draft-ietf-oauth-v2-1-05
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 a protected resource, either
behalf of a resource owner by orchestrating an approval interaction on behalf of a resource owner by orchestrating an approval
between the resource owner and an authorization service, or by interaction between the resource owner and an authorization service,
allowing the third-party application to obtain access on its own or by allowing the third-party application to obtain access on its
behalf. This specification replaces and obsoletes the OAuth 2.0 own behalf. This specification replaces and obsoletes the OAuth 2.0
Authorization 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 8 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are 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 Revised 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. Refresh Token . . . . . . . . . . . . . . . . . . . . 9 1.3.2. Refresh Token . . . . . . . . . . . . . . . . . . . . 9
1.3.3. Client Credentials . . . . . . . . . . . . . . . . . 10 1.3.3. Client Credentials . . . . . . . . . . . . . . . . . 10
1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Access Token . . . . . . . . . . . . . . . . . . . . . . 11
1.5. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 12 1.5. Communication security . . . . . . . . . . . . . . . . . 12
1.6. HTTP Redirections . . . . . . . . . . . . . . . . . . . . 12 1.6. HTTP Redirections . . . . . . . . . . . . . . . . . . . . 12
1.7. Interoperability . . . . . . . . . . . . . . . . . . . . 12 1.7. Interoperability . . . . . . . . . . . . . . . . . . . . 12
1.8. Compatibility with OAuth 2.0 . . . . . . . . . . . . . . 13 1.8. Compatibility with OAuth 2.0 . . . . . . . . . . . . . . 13
1.9. Notational Conventions . . . . . . . . . . . . . . . . . 13 1.9. Notational Conventions . . . . . . . . . . . . . . . . . 13
2. Client Registration . . . . . . . . . . . . . . . . . . . . . 14 2. Client Registration . . . . . . . . . . . . . . . . . . . . . 14
2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 14 2.1. Client Types . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 16 2.2. Client Identifier . . . . . . . . . . . . . . . . . . . . 16
2.3. Client Redirection Endpoint . . . . . . . . . . . . . . . 16 2.3. Client Redirection Endpoint . . . . . . . . . . . . . . . 16
2.3.1. Endpoint Request Confidentiality . . . . . . . . . . 17 2.3.1. Registration Requirements . . . . . . . . . . . . . . 17
2.3.2. Registration Requirements . . . . . . . . . . . . . . 17 2.3.2. Multiple Redirect URIs . . . . . . . . . . . . . . . 17
2.3.3. Multiple Redirect URIs . . . . . . . . . . . . . . . 17 2.3.3. Preventing CSRF Attacks . . . . . . . . . . . . . . . 18
2.3.4. Invalid Endpoint . . . . . . . . . . . . . . . . . . 17 2.3.4. Preventing Mix-Up Attacks . . . . . . . . . . . . . . 18
2.3.5. Endpoint Content . . . . . . . . . . . . . . . . . . 18 2.3.5. Invalid Endpoint . . . . . . . . . . . . . . . . . . 18
2.4. Client Authentication . . . . . . . . . . . . . . . . . . 18 2.3.6. Endpoint Content . . . . . . . . . . . . . . . . . . 18
2.4.1. Client Secret . . . . . . . . . . . . . . . . . . . . 19 2.4. Client Authentication . . . . . . . . . . . . . . . . . . 19
2.4.2. Other Authentication Methods . . . . . . . . . . . . 20 2.4.1. Client Secret . . . . . . . . . . . . . . . . . . . . 20
2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 20 2.4.2. Other Authentication Methods . . . . . . . . . . . . 21
3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . 20 2.5. Unregistered Clients . . . . . . . . . . . . . . . . . . 21
3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 21 3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . 21
3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 21 3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 22
3.2.1. Client Authentication . . . . . . . . . . . . . . . . 22 3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 22
3.2.2. Token Request . . . . . . . . . . . . . . . . . . . . 22 3.2.1. Client Authentication . . . . . . . . . . . . . . . . 23
3.2.3. Token Response . . . . . . . . . . . . . . . . . . . 24 3.2.2. Token Request . . . . . . . . . . . . . . . . . . . . 23
4. Grant Types . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.3. Token Response . . . . . . . . . . . . . . . . . . . 25
4. Grant Types . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 28 4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 28
4.1.1. Authorization Request . . . . . . . . . . . . . . . . 29 4.1.1. Authorization Request . . . . . . . . . . . . . . . . 30
4.1.2. Authorization Response . . . . . . . . . . . . . . . 32 4.1.2. Authorization Response . . . . . . . . . . . . . . . 33
4.1.3. Token Endpoint Extension . . . . . . . . . . . . . . 35 4.1.3. Token Endpoint Extension . . . . . . . . . . . . . . 36
4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 36 4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 37
4.2.1. Token Endpoint Extension . . . . . . . . . . . . . . 37 4.2.1. Token Endpoint Extension . . . . . . . . . . . . . . 38
4.3. Refresh Token Grant . . . . . . . . . . . . . . . . . . . 37 4.3. Refresh Token Grant . . . . . . . . . . . . . . . . . . . 38
4.3.1. Token Endpoint Extension . . . . . . . . . . . . . . 37 4.3.1. Token Endpoint Extension . . . . . . . . . . . . . . 39
4.3.2. Refresh Token Response . . . . . . . . . . . . . . . 39 4.3.2. Refresh Token Response . . . . . . . . . . . . . . . 40
4.4. Extension Grants . . . . . . . . . . . . . . . . . . . . 39 4.4. Extension Grants . . . . . . . . . . . . . . . . . . . . 41
5. Accessing Protected Resources . . . . . . . . . . . . . . . . 40 5. Accessing Protected Resources . . . . . . . . . . . . . . . . 41
5.1. Access Token Types . . . . . . . . . . . . . . . . . . . 40 5.1. Access Token Types . . . . . . . . . . . . . . . . . . . 42
5.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 41 5.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 42
5.2.1. Authenticated Requests . . . . . . . . . . . . . . . 41 5.2.1. Authenticated Requests . . . . . . . . . . . . . . . 43
5.2.2. The WWW-Authenticate Response Header Field . . . . . 43 5.2.2. The WWW-Authenticate Response Header Field . . . . . 45
5.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 44 5.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 46
5.3. Error Response . . . . . . . . . . . . . . . . . . . . . 45 5.3. Error Response . . . . . . . . . . . . . . . . . . . . . 47
5.3.1. Extension Token Types . . . . . . . . . . . . . . . . 45 5.3.1. Extension Token Types . . . . . . . . . . . . . . . . 47
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 46 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1. Defining Access Token Types . . . . . . . . . . . . . . . 46 6.1. Defining Access Token Types . . . . . . . . . . . . . . . 48
6.2. Defining New Endpoint Parameters . . . . . . . . . . . . 46 6.2. Defining New Endpoint Parameters . . . . . . . . . . . . 48
6.3. Defining New Authorization Grant Types . . . . . . . . . 47 6.3. Defining New Authorization Grant Types . . . . . . . . . 49
6.4. Defining New Authorization Endpoint Response Types . . . 47 6.4. Defining New Authorization Endpoint Response Types . . . 49
6.5. Defining Additional Error Codes . . . . . . . . . . . . . 47 6.5. Defining Additional Error Codes . . . . . . . . . . . . . 49
7. Security Considerations . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
7.1. Access Token Security Considerations . . . . . . . . . . 48 7.1. Access Token Security Considerations . . . . . . . . . . 50
7.1.1. Security Threats . . . . . . . . . . . . . . . . . . 48 7.1.1. Security Threats . . . . . . . . . . . . . . . . . . 50
7.1.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 49 7.1.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 51
7.1.3. Summary of Recommendations . . . . . . . . . . . . . 51 7.1.3. Summary of Recommendations . . . . . . . . . . . . . 51
7.1.4. Token Replay Prevention . . . . . . . . . . . . . . . 52 7.1.4. Token Replay Prevention . . . . . . . . . . . . . . . 53
7.1.5. Access Token Privilege Restriction . . . . . . . . . 52 7.1.5. Access Token Privilege Restriction . . . . . . . . . 53
7.2. Client Authentication . . . . . . . . . . . . . . . . . . 53 7.2. Client Authentication . . . . . . . . . . . . . . . . . . 54
7.2.1. Client Authentication of Native Apps . . . . . . . . 54 7.3. Client Impersonation . . . . . . . . . . . . . . . . . . 54
7.3. Registration of Native App Clients . . . . . . . . . . . 54 7.3.1. Impersonation of Native Apps . . . . . . . . . . . . 55
7.4. Client Impersonation . . . . . . . . . . . . . . . . . . 54 7.3.2. Access Token Privilege Restriction . . . . . . . . . 55
7.4.1. Impersonation of Native Apps . . . . . . . . . . . . 55 7.3.3. Access Token Replay Prevention . . . . . . . . . . . 55
7.4.2. Access Token Privilege Restriction . . . . . . . . . 55 7.4. Client Impersonating Resource Owner . . . . . . . . . . . 56
7.4.3. Access Token Replay Prevention . . . . . . . . . . . 56 7.5. Protecting the Authorization Code Flow . . . . . . . . . 56
7.5. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 56 7.5.1. Loopback Redirect Considerations in Native Apps . . . 56
7.6. Client Impersonating Resource Owner . . . . . . . . . . . 57 7.5.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 57
7.7. Protecting the Authorization Code Flow . . . . . . . . . 57 7.6. Authorization Codes . . . . . . . . . . . . . . . . . . . 57
7.7.1. Loopback Redirect Considerations in Native Apps . . . 58 7.7. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 59
7.7.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 58 7.8. Credentials-Guessing Attacks . . . . . . . . . . . . . . 59
7.8. Authorization Codes . . . . . . . . . . . . . . . . . . . 59 7.9. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 59
7.9. Request Confidentiality . . . . . . . . . . . . . . . . . 60 7.10. Cross-Site Request Forgery . . . . . . . . . . . . . . . 59
7.10. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 61 7.11. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 60
7.11. Credentials-Guessing Attacks . . . . . . . . . . . . . . 61 7.12. Code Injection and Input Validation . . . . . . . . . . . 61
7.12. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 61 7.13. Open Redirectors . . . . . . . . . . . . . . . . . . . . 61
7.13. Fake External User-Agents in Native Apps . . . . . . . . 62 7.13.1. Client as Open Redirector . . . . . . . . . . . . . 61
7.14. Malicious External User-Agents in Native Apps . . . . . . 62 7.13.2. Authorization Server as Open Redirector . . . . . . 62
7.15. Cross-Site Request Forgery . . . . . . . . . . . . . . . 62 7.14. Authorization Server Mix-Up Mitigation in Native Apps . . 62
7.16. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 63 7.15. Other Recommendations . . . . . . . . . . . . . . . . . . 63
7.17. Code Injection and Input Validation . . . . . . . . . . . 64 8. Native Applications . . . . . . . . . . . . . . . . . . . . . 63
7.18. Open Redirectors . . . . . . . . . . . . . . . . . . . . 64 8.1. Registration of Native App Clients . . . . . . . . . . . 64
7.18.1. Client as Open Redirector . . . . . . . . . . . . . 64 8.1.1. Client Authentication of Native Apps . . . . . . . . 64
7.18.2. Authorization Server as Open Redirector . . . . . . 65
7.19. Authorization Server Mix-Up Mitigation in Native Apps . . 65 8.2. Using Inter-App URI Communication for OAuth in Native
7.20. Embedded User Agents in Native Apps . . . . . . . . . . . 66 Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.21. Other Recommendations . . . . . . . . . . . . . . . . . . 66 8.3. Initiating the Authorization Request from a Native App . 65
8. Native Applications . . . . . . . . . . . . . . . . . . . . . 67 8.4. Receiving the Authorization Response in a Native App . . 66
8.1. Using Inter-App URI Communication for OAuth in Native 8.4.1. Private-Use URI Scheme Redirection . . . . . . . . . 66
Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8.4.2. Claimed "https" Scheme URI Redirection . . . . . . . 67
8.2. Initiating the Authorization Request from a Native App . 68 8.4.3. Loopback Interface Redirection . . . . . . . . . . . 68
8.3. Receiving the Authorization Response in a Native App . . 69 8.5. Security Considerations in Native Apps . . . . . . . . . 68
8.3.1. Private-Use URI Scheme Redirection . . . . . . . . . 69 8.5.1. Embedded User Agents in Native Apps . . . . . . . . . 69
8.3.2. Claimed "https" Scheme URI Redirection . . . . . . . 70 8.5.2. Fake External User-Agents in Native Apps . . . . . . 69
8.3.3. Loopback Interface Redirection . . . . . . . . . . . 71 8.5.3. Malicious External User-Agents in Native Apps . . . . 70
9. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 72 9. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 70
10. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 72 10. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 71
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 10.1. Removal of the OAuth 2.0 Implicit grant . . . . . . . . 71
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
12.1. Normative References . . . . . . . . . . . . . . . . . . 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
12.1. Normative References . . . . . . . . . . . . . . . . . . 72
12.2. Informative References . . . . . . . . . . . . . . . . . 75 12.2. Informative References . . . . . . . . . . . . . . . . . 75
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 79 Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 78
A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 79 A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 78
A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 79 A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 78
A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 79 A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 78
A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 79 A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 78
A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 80 A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 79
A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 80 A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 79
A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 80 A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 79
A.8. "error_description" Syntax . . . . . . . . . . . . . . . 80 A.8. "error_description" Syntax . . . . . . . . . . . . . . . 79
A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 80 A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 79
A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 80 A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 79
A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 81 A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 80
A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 81 A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 80
A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 81 A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 80
A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 81 A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 80
A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 81 A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 80
A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 81 A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 80
A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 81 A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 80
A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 82 A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 81
Appendix B. Use of application/x-www-form-urlencoded Media Appendix B. Use of application/x-www-form-urlencoded Media
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Appendix C. Extensions . . . . . . . . . . . . . . . . . . . . . 82 Appendix C. Extensions . . . . . . . . . . . . . . . . . . . . . 81
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 84 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 83
Appendix E. Document History . . . . . . . . . . . . . . . . . . 84 Appendix E. Document History . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
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 11, line 12 skipping to change at page 11, line 12
owner) or is requesting access to protected resources based on an owner) or is requesting access to protected resources based on an
authorization previously arranged with the 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 considered opaque to the client, even if it client. The string is considered opaque to the client, even if it
has a structure. Depending on the authorization server, the access has a structure. Depending on the authorization server, the access
token string may be parseable by the resource server, such as when token string may be parseable by the resource server, such as when
using the JSON Web Token Profile for Access Tokens using the JSON Web Token Profile for Access Tokens ([RFC9068]).
([I-D.ietf-oauth-access-token-jwt]).
Access tokens represent specific scopes and durations of access, Access tokens represent specific scopes and durations of access,
granted by the resource owner, and enforced by the resource server granted by the resource owner, and enforced by the resource server
and authorization server. and authorization server.
The token may be used by the RS to retrieve the authorization The token may be used by the RS to retrieve the authorization
information, or the token may self-contain the authorization information, or the token may self-contain the authorization
information in a verifiable manner (i.e., a token string consisting information in a verifiable manner (i.e., a token string consisting
of a signed data payload). One example of a token retrieval of a signed data payload). One example of a token retrieval
mechanism is Token Introspection [RFC7662], in which the RS calls an mechanism is Token Introspection [RFC7662], in which the RS calls an
endpoint on the AS to validate the token presented by the client. endpoint on the AS to validate the token presented by the client.
One example of a structured token format is One example of a structured token format is [RFC9068], a method of
[I-D.ietf-oauth-access-token-jwt], a method of encoding access token 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 an this specification, may be required in order for the client to use an
access token. This is typically referred to as a sender-constrained access token. This is typically referred to as a sender-constrained
access 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
skipping to change at page 12, line 9 skipping to change at page 11, line 49
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
server security requirements. Access token attributes and the server security requirements. Access token attributes and the
methods used to access protected resources may be extended beyond methods used to access protected resources may be extended beyond
what is described in this specification. what is described in this specification.
Access tokens (as well as any confidential access token attributes) Access tokens (as well as any confidential access token attributes)
MUST be kept confidential in transit and storage, and only shared MUST be kept confidential in transit and storage, and only shared
among the authorization server, the resource servers the access token among the authorization server, the resource servers the access token
is valid for, and the client to whom the access token is issued. is valid for, and the client to whom the access token is issued.
Access token credentials MUST only be transmitted using TLS as
described in Section 1.5 with server authentication as defined by
[RFC2818].
The authorization server MUST ensure that access tokens cannot be The authorization server MUST ensure that access tokens cannot be
generated, modified, or guessed to produce valid access tokens by generated, modified, or guessed to produce valid access tokens by
unauthorized parties. unauthorized parties.
1.5. TLS Version 1.5. Communication security
Whenever Transport Layer Security (TLS) is used by this Implementations MUST use a mechanism to provide communication
specification, the appropriate version (or versions) of TLS will vary authentication, integrity and confidentiality such as Transport-Layer
over time, based on the widespread deployment and known security Security [RFC8446], to protect the exchange of clear-text credentials
vulnerabilities. Refer to [BCP195] for up to date recommendations on and tokens either in the payload body or in header fields from
transport layer security. eavesdropping, tampering, and message forgery (eg. see Section 2.4.1,
Section 7.6, Section 3.2, and Section 5.2).
OAuth URLs MUST use the https scheme except for loopback interface
redirect URIs, which MAY use the http scheme. When using https, TLS
certificates MUST be checked according to [RFC2818]. At the time of
this writing, TLS version 1.3 [RFC8446] is the most recent version.
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.
The identification of the TLS versions and algorithms is outside the
scope of this specification. Refer to [BCP195] for up to date
recommendations on transport layer security, and to the relevant
specifications for certificate validation and other security
considerations.
1.6. HTTP Redirections 1.6. 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
method available via the user agent to accomplish this redirection, method available via the user agent to accomplish this redirection,
with the exception of HTTP 307, is allowed and is considered to be an with the exception of HTTP 307, is allowed and is considered to be an
implementation detail. See Section 7.7.2 for details. implementation detail. See Section 7.5.2 for details.
1.7. Interoperability 1.7. 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
skipping to change at page 16, line 26 skipping to change at page 16, line 26
secret; it is exposed to the resource owner and MUST NOT be used secret; it is exposed to the resource owner and MUST NOT be used
alone for client authentication. The client identifier is unique to alone for client authentication. The client identifier is unique to
the authorization server. the authorization server.
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 7.6 for details. their client_id value. See Section 7.4 for details.
2.3. Client Redirection Endpoint 2.3. Client Redirection Endpoint
The client redirection endpoint (also referred to as "redirect The client redirection endpoint (also referred to as "redirect
endpoint") is the URI of the client that the authorization server endpoint") is the URI of the client that the authorization server
redirects the user agent back to after completing its interaction redirects the user agent back to after completing its interaction
with the resource owner. with the resource owner.
The authorization server redirects the user agent to one of the The authorization server redirects the user agent to one of the
client's redirection endpoints previously established with the client's redirection endpoints previously established with the
authorization server during the client registration process. authorization server during the client registration process.
The redirect URI MUST be an absolute URI as defined by [RFC3986] The redirect URI MUST be an absolute URI as defined by [RFC3986]
Section 4.3. The endpoint URI MAY include an "application/x-www- Section 4.3. The endpoint URI MAY include an "application/x-www-
form-urlencoded" formatted (per Appendix B) query component form-urlencoded" formatted (per Appendix B) query component
([RFC3986] Section 3.4), which MUST be retained when adding ([RFC3986] Section 3.4), which MUST be retained when adding
additional query parameters. The endpoint URI MUST NOT include a additional query parameters. The endpoint URI MUST NOT include a
fragment component. fragment component.
2.3.1. Endpoint Request Confidentiality 2.3.1. Registration Requirements
The redirection endpoint SHOULD require the use of TLS as described
in Section 1.5 when the requested response type is code, or when the
redirection request will result in the transmission of sensitive
credentials over an open network. If TLS is not available, the
authorization server SHOULD warn the resource owner about the
insecure endpoint prior to redirection (e.g., display a message
during the authorization request).
2.3.2. Registration Requirements
Authorization servers MUST require clients to register their complete Authorization servers MUST require clients to register their complete
redirect URI (including the path component) and reject authorization redirect URI (including the path component) and reject authorization
requests that specify a redirect URI that doesn't exactly match one requests that specify a redirect URI that doesn't exactly match one
that was registered; the exception is loopback redirects, where an that was registered; the exception is loopback redirects, where an
exact match is required except for the port URI component. exact match is required except for the port URI component.
The authorization server MAY allow the client to register multiple
redirect URIs.
For private-use URI scheme-based redirect URIs, authorization servers For private-use URI scheme-based redirect URIs, authorization servers
SHOULD enforce the requirement in Section 8.3.1 that clients use SHOULD enforce the requirement in Section 8.4.1 that clients use
schemes that are reverse domain name based. At a minimum, any schemes that are reverse domain name based. At a minimum, any
private-use URI scheme that doesn't contain a period character (.) private-use URI scheme that doesn't contain a period character (.)
SHOULD be rejected. SHOULD be rejected.
In addition to the collision-resistant properties, this can help to
prove ownership in the event of a dispute where two apps claim the
same private-use URI scheme (where one app is acting maliciously).
For example, if two apps claimed com.example.app, the owner of
example.com could petition the app store operator to remove the
counterfeit app. Such a petition is harder to prove if a generic URI
scheme was used.
Clients MUST NOT expose URLs that forward the user's browser to
arbitrary URIs obtained from a query parameter ("open redirector").
Open redirectors can enable exfiltration of authorization codes and
access tokens, see (#open_redirector_on_client).
The client MAY use the state request parameter to achieve per-request The client MAY use the state request parameter to achieve per-request
customization if needed rather than varying the redirect URI per customization if needed rather than varying the redirect URI per
request. request.
The authorization server MAY allow the client to register multiple
redirect URIs.
Without requiring registration of redirect URIs, attackers can use Without requiring registration of redirect URIs, attackers can use
the authorization endpoint as an open redirector as described in the authorization endpoint as an open redirector as described in
Section 7.18. Section 7.13.
2.3.3. Multiple Redirect URIs 2.3.2. Multiple Redirect URIs
If multiple redirect URIs have been registered, the client MUST If multiple redirect URIs have been registered, the client MUST
include a redirect URI with the authorization request using the include a redirect URI with the authorization request using the
redirect_uri request parameter. redirect_uri request parameter.
2.3.4. Invalid Endpoint 2.3.3. Preventing CSRF Attacks
Clients MUST prevent Cross-Site Request Forgery (CSRF) attacks. In
this context, CSRF refers to requests to the redirection endpoint
that do not originate at the authorization server, but a malicious
third party (see Section 4.4.1.8. of [RFC6819] for details). Clients
that have ensured that the authorization server supports the
code_challenge parameter MAY rely the CSRF protection provided by
that mechanism. In OpenID Connect flows, validating the nonce
parameter provides CSRF protection. Otherwise, one-time use CSRF
tokens carried in the state parameter that are securely bound to the
user agent MUST be used for CSRF protection (see
(#csrf_countermeasures)).
2.3.4. Preventing Mix-Up Attacks
In order to prevent mix-up attacks (see (#mix_up)), clients MUST only
process redirect responses of the authorization server they sent the
respective request to and from the same user agent this authorization
request was initiated with. Clients MUST store the authorization
server they sent an authorization request to and bind this
information to the user agent and check that the authorization
response was received from the correct authorization server. Clients
MUST ensure that the subsequent access token request, if applicable,
is sent to the same authorization server. Clients SHOULD use
distinct redirect URIs for each authorization server as a means to
identify the authorization server a particular response came from.
2.3.5. Invalid Endpoint
If an authorization request fails validation due to a missing, If an authorization request fails validation due to a missing,
invalid, or mismatching redirect URI, the authorization server SHOULD invalid, or mismatching redirect URI, the authorization server SHOULD
inform the resource owner of the error and MUST NOT automatically inform the resource owner of the error and MUST NOT automatically
redirect the user agent to the invalid redirect URI. redirect the user agent to the invalid redirect URI.
2.3.5. Endpoint Content 2.3.6. Endpoint Content
The redirection request to the client's endpoint typically results in The redirection request to the client's endpoint typically results in
an HTML document response, processed by the user agent. If the HTML an HTML document response, processed by the user agent. If the HTML
response is served directly as the result of the redirection request, response is served directly as the result of the redirection request,
any script included in the HTML document will execute with full any script included in the HTML document will execute with full
access to the redirect URI and the credentials (e.g. authorization access to the redirect URI and the credentials (e.g. authorization
code) it contains. Additionally, the request URL containing the code) it contains. Additionally, the request URL containing the
authorization code may be sent in the HTTP Referer header to any authorization code may be sent in the HTTP Referer header to any
embedded images, stylesheets and other elements loaded in the page. embedded images, stylesheets and other elements loaded in the page.
skipping to change at page 18, line 27 skipping to change at page 19, line 16
party analytics, social plug-ins, ad networks) in the redirection party analytics, social plug-ins, ad networks) in the redirection
endpoint response. Instead, it SHOULD extract the credentials from endpoint response. Instead, it SHOULD extract the credentials from
the URI and redirect the user agent again to another endpoint without the URI and redirect the user agent again to another endpoint without
exposing the credentials (in the URI or elsewhere). If third-party exposing the credentials (in the URI or elsewhere). If third-party
scripts are included, the client MUST ensure that its own scripts scripts are included, the client MUST ensure that its own scripts
(used to extract and remove the credentials from the URI) will (used to extract and remove the credentials from the URI) will
execute first. execute first.
2.4. Client Authentication 2.4. Client Authentication
The authorization server MUST only rely on client authentication if
the process of issuance/registration and distribution of the
underlying credentials ensures their confidentiality.
If the client is confidential or credentialed, the authorization If the client is confidential or credentialed, the authorization
server MAY accept any form of client authentication meeting its server MAY accept any form of client authentication meeting its
security requirements (e.g., password, public/private key pair). security requirements (e.g., password, public/private key pair).
The authorization server MUST authenticate the client whenever
possible. If the authorization server cannot authenticate the client
due to the client's nature, the authorization server SHOULD utilize
other means to protect resource owners from such potentially
malicious clients. For example, the authorization server can engage
the resource owner to assist in identifying the client and its
origin.
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.
When client authentication is not possible, the authorization server
SHOULD employ other means to validate the client's identity - for
example, by requiring the registration of the client redirect URI or
enlisting the resource owner to confirm identity. A valid redirect
URI is not sufficient to verify the client's identity when asking for
resource owner authorization but can be used to prevent delivering
credentials to a counterfeit client after obtaining resource owner
authorization.
The authorization server MAY establish a client authentication method The authorization server MAY establish a client authentication method
with public clients, which converts them to credentialed clients. with public clients, which converts them to credentialed clients.
However, the authorization server MUST NOT rely on credentialed However, the authorization server MUST NOT rely on credentialed
client authentication for the purpose of identifying the client. client authentication for the purpose of identifying the client.
The client MUST NOT use more than one authentication method in each The client MUST NOT use more than one authentication method in each
request to prevent a conflict of which authentication mechanism is request to prevent a conflict of which authentication mechanism is
authoritative for the request. authoritative for the request.
The authorization server MUST consider the security implications of
interacting with unauthenticated clients and take measures to limit
the potential exposure of tokens issued to such clients, (e.g.,
limiting the lifetime of refresh tokens).
The privileges an authorization server associates with a certain
client identity MUST depend on the assessment of the overall process
for client identification and client credential lifecycle management.
See Section 7.2 for additional details.
2.4.1. Client Secret 2.4.1. Client Secret
Clients in possession of a client secret, sometimes known as a client Clients in possession of a client secret, sometimes known as a client
password, MAY use the HTTP Basic authentication scheme as defined in password, MAY use the HTTP Basic authentication scheme as defined in
[RFC7235] to authenticate with the authorization server. The client [RFC7235] to authenticate with the authorization server. The client
identifier is encoded using the application/x-www-form-urlencoded identifier is encoded using the application/x-www-form-urlencoded
encoding algorithm per Appendix B, and the encoded value is used as encoding algorithm per Appendix B, and the encoded value is used as
the username; the client secret is encoded using the same algorithm the username; the client secret is encoded using the same algorithm
and used as the password. The authorization server MUST support the and used as the password. The authorization server MUST support the
HTTP Basic authentication scheme for authenticating clients that were HTTP Basic authentication scheme for authenticating clients that were
skipping to change at page 19, line 47 skipping to change at page 21, line 4
For example, a request to refresh an access token (Section 4.3) using For example, a request to refresh an access token (Section 4.3) using
the body parameters (with extra line breaks for display purposes the body parameters (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
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
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw &client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
The authorization server MUST require the use of TLS as described in
Section 1.5 when sending requests using password authentication.
Since this client authentication method involves a password, the Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against authorization server MUST protect any endpoint utilizing it against
brute force attacks. brute force attacks.
2.4.2. Other Authentication Methods 2.4.2. Other Authentication Methods
The authorization server MAY support any suitable authentication The authorization server MAY support any suitable authentication
scheme matching its security requirements. When using other scheme matching its security requirements. When using other
authentication methods, the authorization server MUST define a authentication methods, the authorization server MUST define a
mapping between the client identifier (registration record) and mapping between the client identifier (registration record) and
skipping to change at page 21, line 24 skipping to change at page 22, line 24
The means through which the client obtains the location of the The means through which the client obtains the location of the
authorization endpoint are beyond the scope of this specification, authorization endpoint are beyond the scope of this specification,
but the location is typically provided in the service documentation, but the location is typically provided in the service documentation,
or in the authorization server's metadata document ([RFC8414]). or in the authorization server's metadata document ([RFC8414]).
The endpoint URI MAY include an "application/x-www-form-urlencoded" The endpoint URI MAY include an "application/x-www-form-urlencoded"
formatted (per Appendix B) query component ([RFC3986] Section 3.4), formatted (per Appendix B) query component ([RFC3986] Section 3.4),
which MUST be retained when adding additional query parameters. The which MUST be retained when adding additional query parameters. The
endpoint URI MUST NOT include a fragment component. endpoint URI MUST NOT include a fragment component.
Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in the
HTTP response), the authorization server MUST require the use of TLS
as described in Section 1.5 when sending requests to the
authorization endpoint.
The authorization server MUST support the use of the HTTP GET method The authorization server MUST support the use of the HTTP GET method
[RFC7231] for the authorization endpoint and MAY support the use of [RFC7231] for the authorization endpoint and MAY support the use of
the POST method as well. the POST method as well.
The authorization server MUST ignore unrecognized request parameters. The authorization server MUST ignore unrecognized request parameters.
Request and response parameters defined by this specification MUST Request and response parameters defined by this specification MUST
NOT be included more than once. Parameters sent without a value MUST NOT be included more than once. Parameters sent without a value MUST
be treated as if they were omitted from the request. be treated as if they were omitted from the request.
An authorization server that redirects a request potentially
containing user credentials MUST avoid forwarding these user
credentials accidentally (see Section 7.5.2 for details).
3.2. Token Endpoint 3.2. Token Endpoint
The token endpoint is used by the client to obtain an access token The token endpoint is used by the client to obtain an access token
using a grant such as those described in Section 4 and Section 4.3. using a grant such as those described in Section 4 and Section 4.3.
The means through which the client obtains the location of the token The means through which the client obtains the location of the token
endpoint are beyond the scope of this specification, but the location endpoint are beyond the scope of this specification, but the location
is typically provided in the service documentation and configured is typically provided in the service documentation and configured
during development of the client, or provided in the authorization during development of the client, or provided in the authorization
server's metadata document ([RFC8414]) and fetched programmatically server's metadata document ([RFC8414]) and fetched programmatically
at runtime. at runtime.
The endpoint URI MAY include an application/x-www-form-urlencoded The endpoint URI MAY include an application/x-www-form-urlencoded
formatted (per Appendix B) query component ([RFC3986] Section 3.4) formatted (per Appendix B) query component ([RFC3986] Section 3.4)
and MUST NOT include a fragment component. and MUST NOT include a fragment component.
Since requests to the token endpoint result in the transmission of
clear-text credentials (in the HTTP request and response), the
authorization server MUST require the use of TLS as described in
Section 1.5 when sending requests to the token endpoint.
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.
The authorization server MUST ignore unrecognized request parameters. The authorization server MUST ignore unrecognized request parameters.
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. Request and response parameters defined by omitted from the request. Request and response parameters defined by
this specification MUST NOT be included more than once. this specification MUST NOT be included more than once.
3.2.1. Client Authentication 3.2.1. Client Authentication
skipping to change at page 23, line 21 skipping to change at page 24, line 13
"grant_type": REQUIRED. Identifier of the grant type the client "grant_type": REQUIRED. Identifier of the grant type the client
uses with the particular token request. This specification uses with the particular token request. This specification
defines the values authorization_code, refresh_token, and defines the values authorization_code, refresh_token, and
client_credentials. The grant type determines the further client_credentials. The grant type determines the further
parameters required or supported by the token request. The parameters required or supported by the token request. The
details of those grant types are defined below. details of those grant types are defined below.
Confidential or credentialed clients MUST authenticate with the Confidential or credentialed clients MUST authenticate with the
authorization server as described in Section 3.2.1. 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 (with extra
(with extra line breaks for display purposes only): 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
skipping to change at page 30, line 24 skipping to change at page 31, line 14
Some extension response types are defined by ([OpenID]). Some extension response types are defined by ([OpenID]).
If an authorization request is missing the response_type parameter, If an authorization request is missing the response_type parameter,
or if the response type is not understood, the authorization server or if the response type is not understood, the authorization server
MUST return an error response as described in Section 4.1.2.1. MUST return an error response as described in Section 4.1.2.1.
"client_id": REQUIRED. The client identifier as described in "client_id": REQUIRED. The client identifier as described in
Section 2.2. Section 2.2.
"code_challenge": REQUIRED or RECOMMENDED (see Section 7.8). Code "code_challenge": REQUIRED or RECOMMENDED (see Section 7.6). Code
challenge. challenge.
"code_challenge_method": OPTIONAL, defaults to plain if not present "code_challenge_method": OPTIONAL, defaults to plain if not present
in the request. Code verifier transformation method is S256 or in the request. Code verifier transformation method is S256 or
plain. plain.
"redirect_uri": OPTIONAL. As described in Section 2.3. "redirect_uri": OPTIONAL. As described in Section 2.3.
"scope": OPTIONAL. The scope of the access request as described by "scope": OPTIONAL. The scope of the access request as described by
Section 3.2.2.1. Section 3.2.2.1.
skipping to change at page 31, line 45 skipping to change at page 32, line 34
code-challenge = 43*128unreserved code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39 DIGIT = %x30-39
The properties code_challenge and code_verifier are adopted from the The properties code_challenge and code_verifier are adopted from the
OAuth 2.0 extension known as "Proof-Key for Code Exchange", or PKCE OAuth 2.0 extension known as "Proof-Key for Code Exchange", or PKCE
([RFC7636]) where this technique was originally developed. ([RFC7636]) where this technique was originally developed.
Authorization servers MUST support the code_challenge and
code_verifier parameters.
Clients MUST use code_challenge and code_verifier and authorization Clients MUST use code_challenge and code_verifier and authorization
servers MUST enforce their use except under the conditions described servers MUST enforce their use except under the conditions described
in Section 7.8. In this case, using and enforcing code_challenge and in Section 7.6. In this case, using and enforcing code_challenge and
code_verifier as described in the following is still RECOMMENDED. code_verifier as described in the following is still RECOMMENDED.
The state and scope parameters SHOULD NOT include sensitive client or
resource owner information in plain text, as they can be transmitted
over insecure channels or stored insecurely.
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection, or by other means available to it via the user HTTP redirection, or by other means available to it via the user
agent. agent.
For example, the client directs the user agent to make the following For example, the client directs the user agent to make the following
HTTP request using TLS (with extra line breaks for display purposes HTTP request (with extra line breaks for display purposes only):
only):
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY &code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY
&code_challenge_method=S256 HTTP/1.1 &code_challenge_method=S256 HTTP/1.1
Host: server.example.com Host: server.example.com
The authorization server validates the request to ensure that all The authorization server validates the request to ensure that all
required parameters are present and valid. required parameters are present and valid.
skipping to change at page 33, line 33 skipping to change at page 34, line 30
the code challenge can be verified later. the code challenge can be verified later.
The exact method that the server uses to associate the code_challenge The exact method that the server uses to associate the code_challenge
with the issued code is out of scope for this specification. The with the issued code is out of scope for this specification. The
code challenge could be stored on the server and associated with the code challenge could be stored on the server and associated with the
code there. The code_challenge and code_challenge_method values may code there. The code_challenge and code_challenge_method values may
be stored in encrypted form in the code itself, but the server MUST be stored in encrypted form in the code itself, but the server MUST
NOT include the code_challenge value in a response parameter in a NOT include the code_challenge value in a response parameter in a
form that entities other than the AS can extract. form that entities other than the AS can extract.
Clients MUST prevent injection (replay) of authorization codes into
the authorization response by attackers. Using code_challenge and
code_verifier prevents injection of authorization codes since the
authorization server will reject a token request with a mismatched
code_verifier. See Section 7.6 for more details.
4.1.2.1. Error Response 4.1.2.1. Error Response
If the request fails due to a missing, invalid, or mismatching If the request fails due to a missing, invalid, or mismatching
redirect URI, or if the client identifier is missing or invalid, the redirect URI, or if the client identifier is missing or invalid, the
authorization server SHOULD inform the resource owner of the error authorization server SHOULD inform the resource owner of the error
and MUST NOT automatically redirect the user agent to the invalid and MUST NOT automatically redirect the user agent to the invalid
redirect URI. redirect URI.
An AS MUST reject requests without a code_challenge from public An AS MUST reject requests without a code_challenge from public
clients, and MUST reject such requests from other clients unless clients, and MUST reject such requests from other clients unless
there is reasonable assurance that the client mitigates authorization there is reasonable assurance that the client mitigates authorization
code injection in other ways. See Section 7.8 for details. code injection in other ways. See Section 7.6 for details.
If the server does not support the requested code_challenge_method If the server does not support the requested code_challenge_method
transformation, the authorization endpoint MUST return the transformation, the authorization endpoint MUST return the
authorization error response with error value set to invalid_request. authorization error response with error value set to invalid_request.
The error_description or the response of error_uri SHOULD explain the The error_description or the response of error_uri SHOULD explain the
nature of error, e.g., transform algorithm not supported. nature of error, e.g., transform algorithm not supported.
If the resource owner denies the access request or if the request If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirect URI, the fails for reasons other than a missing or invalid redirect URI, the
authorization server informs the client by adding the following authorization server informs the client by adding the following
skipping to change at page 35, line 31 skipping to change at page 36, line 37
The authorization grant type is identified at the token endpoint with The authorization grant type is identified at the token endpoint with
the grant_type value of authorization_code. the grant_type value of authorization_code.
If this value is set, the following additional token request If this value is set, the following additional token request
parameters beyond Section 3.2.2 are required: parameters beyond Section 3.2.2 are required:
"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 included "redirect_uri": REQUIRED, if the redirect_uri parameter was included
in the authorization request as described in Section 4.1.1, and in the authorization request as described in Section 4.1.1, in
their values MUST be identical. which case their values MUST be identical. If no redirect_uri was
included in the authorization request, this parameter is OPTIONAL.
"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.
For example, the client makes the following HTTP request using TLS For example, the client makes the following HTTP request (with extra
(with extra line breaks for display purposes only): 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
skipping to change at page 37, line 39 skipping to change at page 39, line 6
4.3. Refresh Token Grant 4.3. Refresh Token Grant
The refresh token is a credential issued by the authorization server The refresh token is a credential issued by the authorization server
to a client, which can be used to obtain new (fresh) access tokens to a client, which can be used to obtain new (fresh) access tokens
based on an existing grant. The client uses this option either based on an existing grant. The client uses this option either
because the previous access token has expired or the client because the previous access token has expired or the client
previously obtained an access token with a scope more narrow than previously obtained an access token with a scope more narrow than
approved by the respective grant and later requires an access token approved by the respective grant and later requires an access token
with a different scope under the same grant. with a different scope under the same grant.
Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was
issued.
The authorization server MUST verify the binding between the refresh
token and client identity whenever the client identity can be
authenticated. When client authentication is not possible, the
authorization server SHOULD issue sender-constrained refresh tokens
or use refresh token rotation as described in (#refreshing-an-access-
token).
The authorization server MUST ensure that refresh tokens cannot be
generated, modified, or guessed to produce valid refresh tokens by
unauthorized parties.
4.3.1. Token Endpoint Extension 4.3.1. Token Endpoint Extension
The authorization grant type is identified at the token endpoint with The authorization grant type is identified at the token endpoint with
the grant_type value of refresh_token. the grant_type value of refresh_token.
If this value is set, the following additional parameters beyond If this value is set, the following additional parameters beyond
Section 3.2.2 are required/supported: Section 3.2.2 are required/supported:
"refresh_token": REQUIRED. The refresh token issued to the client. "refresh_token": REQUIRED. The refresh token issued to the client.
skipping to change at page 39, line 50 skipping to change at page 41, line 23
4.4. Extension Grants 4.4. Extension Grants
The client uses an extension grant type by specifying the grant type The client uses an extension grant type by specifying the grant type
using an absolute URI (defined by the authorization server) as the using an absolute URI (defined by the authorization server) as the
value of the grant_type parameter of the token endpoint, and by value of the grant_type parameter of the token endpoint, and by
adding any additional parameters necessary. adding any additional parameters necessary.
For example, to request an access token using the Device For example, to request an access token using the Device
Authorization Grant as defined by [RFC8628] after the user has Authorization Grant as defined by [RFC8628] after the user has
authorized the client on a separate device, the client makes the authorized the client on a separate device, the client makes the
following HTTP request using TLS (with extra line breaks for display following HTTP request (with extra line breaks for display purposes
purposes only): only):
POST /token HTTP/1.1 POST /token 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
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
&device_code=GmRhmhcxhwEzkoEqiMEg_DnyEysNkuNhszIySk9eS &device_code=GmRhmhcxhwEzkoEqiMEg_DnyEysNkuNhszIySk9eS
&client_id=C409020731 &client_id=C409020731
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
skipping to change at page 40, line 33 skipping to change at page 42, line 6
access token and ensure that it has not expired and that its scope access token and ensure that it has not expired and that its scope
covers the requested resource. The methods used by the resource covers the requested resource. The methods used by the resource
server to validate the access token (as well as any error responses) server to validate the access token (as well as any error responses)
are beyond the scope of this specification, but generally involve an are beyond the scope of this specification, but generally involve an
interaction or coordination between the resource server and the interaction or coordination between the resource server and the
authorization server. For example, when the resource server and authorization server. For example, when the resource server and
authorization server are colocated or are part of the same system, authorization server are colocated or are part of the same system,
they may share a database or other storage; when the two components they may share a database or other storage; when the two components
are operated independently, they may use Token Introspection are operated independently, they may use Token Introspection
[RFC7662] or a structured access token format such as a JWT [RFC7662] or a structured access token format such as a JWT
[I-D.ietf-oauth-access-token-jwt]. [RFC9068].
The method in which the client utilizes the access token to access The method in which the client utilizes the access token to access
protected resources at the resource server depends on the type of protected resources at the resource server depends on the type of
access token issued by the authorization server. Typically, it access token issued by the authorization server. Typically, it
involves using the HTTP Authorization request header field [RFC7235] involves using the HTTP Authorization request header field [RFC7235]
with an authentication scheme defined by the specification of the with an authentication scheme defined by the specification of the
access token type used, such as Bearer, defined below. access token type used, such as Bearer, defined below.
5.1. Access Token Types 5.1. Access Token Types
skipping to change at page 41, line 20 skipping to change at page 42, line 41
Each access token type definition specifies the additional attributes Each access token type definition specifies the additional attributes
(if any) sent to the client together with the access_token response (if any) sent to the client together with the access_token response
parameter. It also defines the HTTP authentication method used to parameter. It also defines the HTTP authentication method used to
include the access token when making a protected resource request. include the access token when making a protected resource request.
5.2. Bearer Tokens 5.2. Bearer Tokens
A Bearer Token is a security token with the property that any party A Bearer Token is a security token with the property that any party
in possession of the token (a "bearer") can use the token in any way in possession of the token (a "bearer") can use the token in any way
that any other party in possession of it can. Using a bearer token that any other party in possession of it can. Using a Bearer Token
does not require a bearer to prove possession of cryptographic key does not require a bearer to prove possession of cryptographic key
material (proof-of-possession). material (proof-of-possession).
Bearer tokens may be enhanced with proof-of-possession specifications Bearer Tokens may be enhanced with proof-of-possession specifications
such as mTLS [RFC8705] to provide proof-of-possession such as mTLS [RFC8705] to provide proof-of-possession
characteristics. characteristics.
To protect against access token disclosure, the communication
interaction between the client and the resource server MUST utilize
confidentiality and integrity protection as described in Section 1.5.
To mitigate the risk of access token capture and replay, the lifetime
of the token MUST be limited. One means of achieving this is by
putting a validity time field inside the protected part of the token.
Note that using short-lived tokens reduces the impact of them being
leaked.
There is no requirement on the particular structure or format of a
bearer token, as described in Section 5. If a bearer token is a
reference to authorization information, such references MUST be
infeasible for an attacker to guess, such as using a sufficiently
long cryptographically random string. If a bearer token uses an
encoding mechanism to contain the authorization information in the
token itself, the access token MUST use integrity protection
sufficient to prevent the token from being modified. One example of
an encoding and signing mechanism for access tokens is described in
JSON Web Token Profile for Access Tokens [RFC9068].
5.2.1. Authenticated Requests 5.2.1. Authenticated Requests
This section defines two methods of sending Bearer tokens in resource This section defines two methods of sending Bearer tokens in resource
requests to resource servers. Clients MUST use one of the two requests to resource servers. Clients MUST use one of the two
methods defined below, and MUST NOT use more than one method to methods defined below, and MUST NOT use more than one method to
transmit the token in each request. transmit the token in each request.
In particular, clients MUST NOT send the access token in a URI query In particular, clients MUST NOT send the access token in a URI query
parameter, and resource servers MUST ignore access tokens in a URI parameter, and resource servers MUST ignore access tokens in a URI
query parameter. query parameter.
skipping to change at page 49, line 23 skipping to change at page 51, line 12
An attacker attempts to use an access token that has already been An attacker attempts to use an access token that has already been
used with that resource server in the past. used with that resource server in the past.
7.1.2. Threat Mitigation 7.1.2. Threat Mitigation
A large range of threats can be mitigated by protecting the contents A large range of threats can be mitigated by protecting the contents
of the access token by using a digital signature. of the access token by using a digital signature.
Alternatively, a bearer token can contain a reference to Alternatively, a bearer token can contain a reference to
authorization information, rather than encoding the information authorization information, rather than encoding the information
directly. Such references MUST be infeasible for an attacker to directly. Using a reference may require an extra interaction between
guess; using a reference may require an extra interaction between a a server and the access token issuer to resolve the reference to the
server and the access token issuer to resolve the reference to the
authorization information. The mechanics of such an interaction are authorization information. The mechanics of such an interaction are
not defined by this specification. not defined by this specification.
This document does not specify the encoding or the contents of the This document does not specify the encoding or the contents of the
access token; hence, detailed recommendations about the means of access token; hence, detailed recommendations about the means of
guaranteeing access token integrity protection are outside the scope guaranteeing access token integrity protection are outside the scope
of this specification. The access token integrity protection MUST be of this specification. One example of an encoding and signing
sufficient to prevent the token from being modified. One example of mechanism for access tokens is described in JSON Web Token Profile
an encoding and signing mechanism for access tokens is described in for Access Tokens [RFC9068].
[I-D.ietf-oauth-access-token-jwt].
To deal with access token redirects, it is important for the To deal with access token redirects, it is important for the
authorization server to include the identity of the intended authorization server to include the identity of the intended
recipients (the audience), typically a single resource server (or a recipients (the audience), typically a single resource server (or a
list of resource servers), in the token. Restricting the use of the list of resource servers), in the token. Restricting the use of the
token to a specific scope is also RECOMMENDED. token to a specific scope is also RECOMMENDED.
The authorization server MUST implement TLS as described in Which
version(s) ought to be implemented will vary over time and will
depend on the widespread deployment and known security
vulnerabilities at the time of implementation. Refer to
Section 1.5.[BCP195] for up to date recommendations on transport
layer security.
To protect against access token disclosure, confidentiality
protection MUST be applied using TLS with a ciphersuite that provides
confidentiality and integrity protection. This requires that the
communication interaction between the client and the authorization
server, as well as the interaction between the client and the
resource server, utilize confidentiality and integrity protection.
Since TLS is mandatory to implement and to use with this
specification, it is the preferred approach for preventing token
disclosure via the communication channel. For those cases where the
client is prevented from observing the contents of the access token,
token encryption MUST be applied in addition to the usage of TLS
protection. As a further defense against token disclosure, the
client MUST validate the TLS certificate chain when making requests
to protected resources, including checking the Certificate Revocation
List (CRL) [RFC5280].
If cookies are transmitted without TLS protection, any information If cookies are transmitted without TLS protection, any information
contained in them is at risk of disclosure. Therefore, Bearer tokens contained in them is at risk of disclosure. Therefore, Bearer tokens
MUST NOT be stored in cookies that can be sent in the clear, as any MUST NOT be stored in cookies that can be sent in the clear, as any
information in them is at risk of disclosure. See "HTTP State information in them is at risk of disclosure. See "HTTP State
Management Mechanism" [RFC6265] for security considerations about Management Mechanism" [RFC6265] for security considerations about
cookies. cookies.
In some deployments, including those utilizing load balancers, the In some deployments, including those utilizing load balancers, the
TLS connection to the resource server terminates prior to the actual TLS connection to the resource server terminates prior to the actual
server that provides the resource. This could leave the token server that provides the resource. This could leave the token
unprotected between the front-end server where the TLS connection unprotected between the front-end server where the TLS connection
terminates and the back-end server that provides the resource. In terminates and the back-end server that provides the resource. In
such deployments, sufficient measures MUST be employed to ensure such deployments, sufficient measures MUST be employed to ensure
confidentiality of the access token between the front-end and back- confidentiality of the access token between the front-end and back-
end servers; encryption of the token is one such possible measure. end servers; encryption of the token is one such possible measure.
To deal with access token capture and replay, the following
recommendations are made: First, the lifetime of the token MUST be
limited; one means of achieving this is by putting a validity time
field inside the protected part of the token. Note that using short-
lived tokens reduces the impact of them being leaked. Second,
confidentiality protection of the exchanges between the client and
the authorization server and between the client and the resource
server MUST be applied. As a consequence, no eavesdropper along the
communication path is able to observe the token exchange.
Consequently, such an on-path adversary cannot replay the token.
Furthermore, when presenting the token to a resource server, the
client MUST verify the identity of that resource server, as per
[BCP195] and Section 3.1 of "HTTP Over TLS" [RFC2818]. Note that the
client MUST validate the TLS certificate chain when making these
requests to protected resources. Presenting the token to an
unauthenticated and unauthorized resource server or failing to
validate the certificate chain will allow adversaries to steal the
token and gain unauthorized access to protected resources.
7.1.3. Summary of Recommendations 7.1.3. Summary of Recommendations
7.1.3.1. Safeguard bearer tokens 7.1.3.1. Safeguard bearer tokens
Client implementations MUST ensure that bearer tokens are not leaked Client implementations MUST ensure that bearer tokens are not leaked
to unintended parties, as they will be able to use them to gain to unintended parties, as they will be able to use them to gain
access to protected resources. This is the primary security access to protected resources. This is the primary security
consideration when using bearer tokens and underlies all the more consideration when using bearer tokens and underlies all the more
specific recommendations that follow. specific recommendations that follow.
7.1.3.2. Validate TLS certificate chains 7.1.3.2. Validate TLS certificate chains
skipping to change at page 53, line 18 skipping to change at page 54, line 18
respective resource and actions and every resource server is obliged respective resource and actions and every resource server is obliged
to verify, for every request, whether the access token sent with that to verify, for every request, whether the access token sent with that
request was meant to be used for that particular action on the request was meant to be used for that particular action on the
particular resource. If not, the resource server must refuse to particular resource. If not, the resource server must refuse to
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 specified in utilize the parameter scope and authorization_details as specified in
[I-D.ietf-oauth-rar] to determine those resources and/or actions. [I-D.ietf-oauth-rar] to determine those resources and/or actions.
7.2. Client Authentication 7.2. Client Authentication
The authorization server MUST only rely on client authentication if Depending on the overall process of client registration and
the process of issuance/registration and distribution of the credential lifecycle management, this may affect the confidence an
underlying credentials ensures their confidentiality. authorization server has in a particular client. For example,
authentication of a dynamically registered client does not prove the
When client authentication is not possible, the authorization server identity of the client, it only ensures that repeated requests to the
SHOULD employ other means to validate the client's identity - for authorization server were made from the same client instance. Such
example, by requiring the registration of the client redirect URI or clients may be limited in terms of which scopes they are allowed to
enlisting the resource owner to confirm identity. A valid redirect request, or may have other limitations such as shorter token
URI is not sufficient to verify the client's identity when asking for lifetimes. In contrast, if there is a registered application whose
resource owner authorization but can be used to prevent delivering developer's identity was verified, who signed a contract and is
credentials to a counterfeit client after obtaining resource owner issued a client secret that is only used in a secure backend service,
authorization. the authorization server might allow this client to request more
sensitive scopes or to be issued longer-lasting tokens.
The authorization server must consider the security implications of
interacting with unauthenticated clients and take measures to limit
the potential exposure of other credentials (e.g., refresh tokens)
issued to such clients.
The privileges an authorization server associates with a certain
client identity MUST depend on the assessment of the overall process
for client identification and client credential lifecycle management.
For example, authentication of a dynamically registered client just
ensures the authorization server it is talking to the same client
again. In contrast, if there is a web application whose developer's
identity was verified, who signed a contract and is issued a client
secret that is only used in a secure backend service, the
authorization server might allow this client to access more sensitive
services or to use the client credentials grant type.
7.2.1. Client Authentication of Native Apps
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret. For this
reason, it is NOT RECOMMENDED for authorization servers to require
client authentication of public native apps clients using a shared
secret, as this serves little value beyond client identification
which is already provided by the client_id request parameter.
Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public
client (as defined in Section 2.1), and not accept the secret as
proof of the client's identity. Without additional measures, such
clients are subject to client impersonation (see Section 7.4.1).
7.3. Registration of Native App Clients
Except when using a mechanism like Dynamic Client Registration
[RFC7591] to provision per-instance secrets, native apps are
classified as public clients, as defined in Section 2.1; they MUST be
registered with the authorization server as such. Authorization
servers MUST record the client type in the client registration
details in order to identify and process requests accordingly.
Authorization servers MAY request the inclusion of other platform-
specific information, such as the app package or bundle name, or
other information that may be useful for verifying the calling app's
identity on operating systems that support such functions.
For private-use URI scheme-based redirect URIs, authorization servers
SHOULD require that the URI scheme be based on a domain name that is
under the control of the app. In addition to the collision-resistant
properties, this can help to prove ownership in the event of a
dispute where two apps claim the same private-use URI scheme (where
one app is acting maliciously). For example, if two apps claimed
com.example.app, the owner of example.com could petition the app
store operator to remove the counterfeit app. Such a petition is
harder to prove if a generic URI scheme was used.
7.4. Client Impersonation 7.3. Client Impersonation
A malicious client can impersonate another client and obtain access A malicious client can impersonate another client and obtain access
to protected resources if the impersonated client fails to, or is to protected resources if the impersonated client fails to, or is
unable to, keep its client credentials confidential. unable to, keep its client credentials confidential.
The authorization server SHOULD enforce explicit resource owner The authorization server SHOULD enforce explicit resource owner
authentication and provide the resource owner with information about authentication and provide the resource owner with information about
the client and the requested authorization scope and lifetime. It is the client and the requested authorization scope and lifetime. It is
up to the resource owner to review the information in the context of up to the resource owner to review the information in the context of
the current client and to authorize or deny the request. the current client and to authorize or deny the request.
The authorization server SHOULD NOT process repeated authorization The authorization server SHOULD NOT process repeated authorization
requests automatically (without active resource owner interaction) requests automatically (without active resource owner interaction)
without authenticating the client or relying on other measures to without authenticating the client or relying on other measures to
ensure that the repeated request comes from the original client and ensure that the repeated request comes from the original client and
not an impersonator. not an impersonator.
7.4.1. Impersonation of Native Apps 7.3.1. Impersonation of Native Apps
As stated above, the authorization server SHOULD NOT process As stated above, the authorization server SHOULD NOT process
authorization requests automatically without user consent or authorization requests automatically without user consent or
interaction, except when the identity of the client can be assured. interaction, except when the identity of the client can be assured.
This includes the case where the user has previously approved an This includes the case where the user has previously approved an
authorization request for a given client ID - unless the identity of authorization request for a given client ID - unless the identity of
the client can be proven, the request SHOULD be processed as if no the client can be proven, the request SHOULD be processed as if no
previous request had been approved. previous request had been approved.
Measures such as claimed https scheme redirects MAY be accepted by Measures such as claimed https scheme redirects MAY be accepted by
authorization servers as identity proof. Some operating systems may authorization servers as identity proof. Some operating systems may
offer alternative platform-specific identity features that MAY be offer alternative platform-specific identity features that MAY be
accepted, as appropriate. accepted, as appropriate.
7.4.2. Access Token Privilege Restriction 7.3.2. Access Token Privilege Restriction
The client SHOULD request access tokens with the minimal scope The client SHOULD request access tokens with the minimal scope
necessary. The authorization server SHOULD take the client identity necessary. The authorization server SHOULD take the client identity
into account when choosing how to honor the requested scope and MAY into account when choosing how to honor the requested scope and MAY
issue an access token with less rights than requested. issue an access token with less rights than requested.
The privileges associated with an access token SHOULD be restricted The privileges associated with an access token SHOULD be restricted
to the minimum required for the particular application or use case. to the minimum required for the particular application or use case.
This prevents clients from exceeding the privileges authorized by the This prevents clients from exceeding the privileges authorized by the
resource owner. It also prevents users from exceeding their resource owner. It also prevents users from exceeding their
skipping to change at page 56, line 8 skipping to change at page 55, line 45
servers (audience restriction), preferably to a single resource servers (audience restriction), preferably to a single resource
server. To put this into effect, the authorization server associates server. To put this into effect, the authorization server associates
the access token with certain resource servers and every resource the access token with certain resource servers and every resource
server is obliged to verify, for every request, whether the access server is obliged to verify, for every request, whether the access
token sent with that request was meant to be used for that particular token sent with that request was meant to be used for that particular
resource server. If not, the resource server MUST refuse to serve resource server. If not, the resource server MUST refuse to serve
the respective request. Clients and authorization servers MAY the respective request. Clients and authorization servers MAY
utilize the parameters scope or resource as specified in [RFC8707], utilize the parameters scope or resource as specified in [RFC8707],
respectively, to determine the resource server they want to access. respectively, to determine the resource server they want to access.
7.4.3. Access Token Replay Prevention 7.3.3. Access Token Replay Prevention
Additionally, access tokens SHOULD be restricted to certain resources Additionally, access tokens SHOULD be restricted to certain resources
and actions on resource servers or resources. To put this into and actions on resource servers or resources. To put this into
effect, the authorization server associates the access token with the effect, the authorization server associates the access token with the
respective resource and actions and every resource server is obliged respective resource and actions and every resource server is obliged
to verify, for every request, whether the access token sent with that to verify, for every request, whether the access token sent with that
request was meant to be used for that particular action on the request was meant to be used for that particular action on the
particular resource. If not, the resource server must refuse to particular resource. If not, the resource server must refuse to
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 specified in utilize the parameter scope and authorization_details as specified in
skipping to change at page 56, line 30 skipping to change at page 56, line 18
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 access token at the recipient (e.g., a for the acceptance of that access token at the recipient (e.g., a
resource 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.
7.5. Refresh Tokens 7.4. Client Impersonating Resource Owner
Authorization servers MAY issue refresh tokens to clients.
Refresh tokens MUST be kept confidential in transit and storage, and
shared only among the authorization server and the client to whom the
refresh tokens were issued. The authorization server MUST maintain
the binding between a refresh token and the client to whom it was
issued. Refresh tokens MUST only be transmitted using TLS as
described in Section 1.5 with server authentication as defined by
[RFC2818].
The authorization server MUST verify the binding between the refresh
token and client identity whenever the client identity can be
authenticated. When client authentication is not possible, the
authorization server SHOULD issue sender-constrained refresh tokens
or use refresh token rotation as described in (#refreshing-an-access-
token).
The authorization server MUST ensure that refresh tokens cannot be
generated, modified, or guessed to produce valid refresh tokens by
unauthorized parties.
7.6. Client Impersonating Resource Owner
Resource servers may make access control decisions based on the Resource servers may make access control decisions based on the
identity of the resource owner as communicated in the sub claim identity of the resource owner as communicated in the sub claim
returned by the authorization server in a token introspection returned by the authorization server in a token introspection
response [RFC7662] or other mechanisms. If a client is able to response [RFC7662] or other mechanisms. If a client is able to
choose its own client_id during registration with the authorization choose its own client_id during registration with the authorization
server, then there is a risk that it can register with the same sub server, then there is a risk that it can register with the same sub
value as a privileged user. A subsequent access token obtained under value as a privileged user. A subsequent access token obtained under
the client credentials grant may be mistaken for an access token the client credentials grant may be mistaken for an access token
authorized by the privileged user if the resource server does not authorized by the privileged user if the resource server does not
perform additional checks. perform additional checks.
Authorization servers SHOULD NOT allow clients to influence their Authorization servers SHOULD NOT allow clients to influence their
client_id or sub value or any other claim if that can cause confusion client_id or sub value or any other claim if that can cause confusion
with a genuine resource owner. Where this cannot be avoided, with a genuine resource owner. Where this cannot be avoided,
authorization servers MUST provide other means for the resource authorization servers MUST provide other means for the resource
server to distinguish between access tokens authorized by a resource server to distinguish between access tokens authorized by a resource
owner from access tokens authorized by the client itself. owner from access tokens authorized by the client itself.
7.7. Protecting the Authorization Code Flow 7.5. Protecting the Authorization Code Flow
When comparing client redirect URIs against pre-registered URIs,
authorization servers MUST utilize exact string matching. This
measure contributes to the prevention of leakage of authorization
codes and access tokens (see (#insufficient_uri_validation)). It can
also help to detect mix-up attacks (see (#mix_up)).
Clients MUST NOT expose URLs that forward the user's browser to
arbitrary URIs obtained from a query parameter ("open redirector").
Open redirectors can enable exfiltration of authorization codes and
access tokens, see (#open_redirector_on_client).
Clients MUST prevent Cross-Site Request Forgery (CSRF). In this
context, CSRF refers to requests to the redirection endpoint that do
not originate at the authorization server, but a malicious third
party (see Section 4.4.1.8. of [RFC6819] for details). Clients that
have ensured that the authorization server supports the
code_challenge parameter MAY rely the CSRF protection provided by
that mechanism. In OpenID Connect flows, the nonce parameter
provides CSRF protection. Otherwise, one-time use CSRF tokens
carried in the state parameter that are securely bound to the user
agent MUST be used for CSRF protection (see (#csrf_countermeasures)).
In order to prevent mix-up attacks (see (#mix_up)), clients MUST only
process redirect responses of the authorization server they sent the
respective request to and from the same user agent this authorization
request was initiated with. Clients MUST store the authorization
server they sent an authorization request to and bind this
information to the user agent and check that the authorization
response was received from the correct authorization server. Clients
MUST ensure that the subsequent access token request, if applicable,
is sent to the same authorization server. Clients SHOULD use
distinct redirect URIs for each authorization server as a means to
identify the authorization server a particular response came from.
An AS that redirects a request potentially containing user
credentials MUST avoid forwarding these user credentials accidentally
(see Section 7.7.2 for details).
7.7.1. Loopback Redirect Considerations in Native Apps 7.5.1. Loopback Redirect Considerations in Native Apps
Loopback interface redirect URIs use the http scheme (i.e., without Loopback interface redirect URIs MAY use the http scheme (i.e.,
Transport Layer Security (TLS)). This is acceptable for loopback without TLS). This is acceptable for loopback interface redirect
interface redirect URIs as the HTTP request never leaves the device. URIs as the HTTP request never leaves the device.
Clients should open the network port only when starting the Clients should open the network port only when starting the
authorization request and close it once the response is returned. authorization request and close it once the response is returned.
Clients should listen on the loopback network interface only, in Clients should listen on the loopback network interface only, in
order to avoid interference by other network actors. order to avoid interference by other network actors.
Clients should use loopback IP literals rather than the string Clients should use loopback IP literals rather than the string
localhost as described in Section 8.3.3. localhost as described in Section 8.4.3.
7.7.2. HTTP 307 Redirect 7.5.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 their 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
skipping to change at page 59, line 19 skipping to change at page 57, line 42
In the HTTP standard [RFC7231], only the status code 303 In the HTTP standard [RFC7231], only the status code 303
unambigiously enforces rewriting the HTTP POST request to an HTTP GET unambigiously enforces rewriting the HTTP POST request to an HTTP GET
request. For all other status codes, including the popular 302, user request. For all other status codes, including the popular 302, user
agents can opt not to rewrite POST to GET requests and therefore to agents can opt not to rewrite POST to GET requests and therefore to
reveal the user credentials to the client. (In practice, however, reveal the user credentials to the client. (In practice, however,
most user agents will only show this behaviour for 307 redirects.) most user agents will only show this behaviour for 307 redirects.)
Therefore, the RECOMMENDED status code for HTTP redirects is 303. Therefore, the RECOMMENDED status code for HTTP redirects is 303.
7.8. Authorization Codes 7.6. Authorization Codes
Authorization codes MUST be short lived and single-use. If the
authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server
SHOULD attempt to revoke all refresh and access tokens already
granted based on the compromised authorization code.
If the client can be authenticated, the authorization servers MUST
authenticate the client and ensure that the authorization code was
issued to the same client.
Clients MUST prevent injection (replay) of authorization codes into To prevent injection of authorization codes into the client, 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 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 by the 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 code_verifier is In this case, using and enforcing code_challenge and code_verifier is
still RECOMMENDED. still RECOMMENDED.
The code_challenge or OpenID Connect nonce value MUST be transaction- The code_challenge or OpenID Connect nonce value MUST be transaction-
specific and securely bound to the client and the user agent in which specific and securely bound to the client and the user agent in which
the transaction was started. If a transaction leads to an error, the transaction was started. If a transaction leads to an error,
fresh values for code_challenge or nonce MUST be chosen. fresh values for code_challenge or nonce MUST be chosen.
Historic note: Although PKCE [RFC7636] was originally designed as a Historic note: Although PKCE [RFC7636] (where the code_challenge and
code_verifier parameters were created) was originally designed as a
mechanism to protect native apps, this advice applies to all kinds of mechanism to protect native apps, this advice applies to all kinds of
OAuth clients, including web applications and other confidential OAuth clients, including web applications and other confidential
clients. clients.
Clients SHOULD use code challenge methods that do not expose the Clients SHOULD use code challenge methods that do not expose the
code_verifier in the authorization request. Otherwise, attackers code_verifier in the authorization request. Otherwise, attackers
that can read the authorization request (cf. Attacker A4 in that can read the authorization request (cf. Attacker A4 in
(#secmodel)) can break the security provided by this mechanism. (#secmodel)) can break the security provided by this mechanism.
Currently, S256 is the only such method. Currently, S256 is the only such method.
skipping to change at page 60, line 29 skipping to change at page 58, line 42
1. If there was a code_challenge in the authorization request for 1. If there was a code_challenge in the authorization request for
which this code was issued, there must be a code_verifier in the which this code was issued, there must be a code_verifier in the
token request, and it MUST be verified according to the steps in token request, and it MUST be verified according to the steps in
Section 3.2.2. (This is no change from the current behavior in Section 3.2.2. (This is no change from the current behavior in
[RFC7636].) [RFC7636].)
2. If there was no code_challenge in the authorization request, any 2. If there was no code_challenge in the authorization request, any
request to the token endpoint containing a code_verifier MUST be request to the token endpoint containing a code_verifier MUST be
rejected. rejected.
Authorization servers MUST support the code_challenge and
code_verifier parameters.
Authorization servers MUST provide a way to detect their support for Authorization servers MUST provide a way to detect their support for
the code_challenge mechanism. To this end, they MUST either (a) the code_challenge mechanism. To this end, they MUST either (a)
publish the element code_challenge_methods_supported in their AS publish the element code_challenge_methods_supported in their AS
metadata ([RFC8414]) containing the supported code_challenge_methods metadata ([RFC8414]) containing the supported code_challenge_methods
(which can be used by the client to detect support) or (b) provide a (which can be used by the client to detect support) or (b) provide a
deployment-specific way to ensure or determine support by the AS. deployment-specific way to ensure or determine support by the AS.
7.9. Request Confidentiality 7.7. Ensuring Endpoint Authenticity
Access tokens, refresh tokens, authorization codes, and client
credentials MUST NOT be transmitted in the clear.
The state and scope parameters SHOULD NOT include sensitive client or
resource owner information in plain text, as they can be transmitted
over insecure channels or stored insecurely.
7.10. Ensuring Endpoint Authenticity
In order to prevent man-in-the-middle attacks, the authorization The risk related to man-in-the-middle attacks is mitigated by the
server MUST require the use of TLS with server authentication as mandatory use of channel security mechanisms such as [RFC8446] for
defined by [RFC2818] for any request sent to the authorization and communicating with the Authorization and Token Endpoints. See
token endpoints. The client MUST validate the authorization server's Section 1.5 for further details.
TLS certificate as defined by [RFC6125] and in accordance with its
requirements for server identity authentication.
7.11. Credentials-Guessing Attacks 7.8. Credentials-Guessing Attacks
The authorization server MUST prevent attackers from guessing access The authorization server MUST prevent attackers from guessing access
tokens, authorization codes, refresh tokens, resource owner tokens, authorization codes, refresh tokens, resource owner
passwords, and client credentials. passwords, and client credentials.
The probability of an attacker guessing generated tokens (and other The probability of an attacker guessing generated tokens (and other
credentials not intended for handling by end-users) MUST be less than credentials not intended for handling by end-users) MUST be less than
or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
The authorization server MUST utilize other means to protect The authorization server MUST utilize other means to protect
credentials intended for end-user usage. credentials intended for end-user usage.
7.12. Phishing Attacks 7.9. Phishing Attacks
Wide deployment of this and similar protocols may cause end-users to Wide deployment of this and similar protocols may cause end-users to
become inured to the practice of being redirected to websites where become inured to the practice of being redirected to websites where
they are asked to enter their passwords. If end-users are not they are asked to enter their passwords. If end-users are not
careful to verify the authenticity of these websites before entering careful to verify the authenticity of these websites before entering
their credentials, it will be possible for attackers to exploit this their credentials, it will be possible for attackers to exploit this
practice to steal resource owners' passwords. practice to steal resource owners' passwords.
Service providers should attempt to educate end-users about the risks Service providers should attempt to educate end-users about the risks
phishing attacks pose and should provide mechanisms that make it easy phishing attacks pose and should provide mechanisms that make it easy
for end-users to confirm the authenticity of their sites. Client for end-users to confirm the authenticity of their sites. Client
developers should consider the security implications of how they developers should consider the security implications of how they
interact with the user agent (e.g., external, embedded), and the interact with the user agent (e.g., external, embedded), and the
ability of the end-user to verify the authenticity of the ability of the end-user to verify the authenticity of the
authorization server. authorization server.
To reduce the risk of phishing attacks, the authorization servers See Section 1.5 for further details on mitigating the risk of
MUST require the use of TLS on every endpoint used for end-user phishing attacks.
interaction.
7.13. Fake External User-Agents in Native Apps
The native app that is initiating the authorization request has a
large degree of control over the user interface and can potentially
present a fake external user agent, that is, an embedded user agent
made to appear as an external user agent.
When all good actors are using external user agents, the advantage is
that it is possible for security experts to detect bad actors, as
anyone faking an external user agent is provably bad. On the other
hand, if good and bad actors alike are using embedded user agents,
bad actors don't need to fake anything, making them harder to detect.
Once a malicious app is detected, it may be possible to use this
knowledge to blacklist the app's signature in malware scanning
software, take removal action (in the case of apps distributed by app
stores) and other steps to reduce the impact and spread of the
malicious app.
Authorization servers can also directly protect against fake external
user agents by requiring an authentication factor only available to
true external user agents.
Users who are particularly concerned about their security when using
in-app browser tabs may also take the additional step of opening the
request in the full browser from the in-app browser tab and complete
the authorization there, as most implementations of the in-app
browser tab pattern offer such functionality.
7.14. Malicious External User-Agents in Native Apps
If a malicious app is able to configure itself as the default handler
for https scheme URIs in the operating system, it will be able to
intercept authorization requests that use the default browser and
abuse this position of trust for malicious ends such as phishing the
user.
This attack is not confined to OAuth; a malicious app configured in
this way would present a general and ongoing risk to the user beyond
OAuth usage by native apps. Many operating systems mitigate this
issue by requiring an explicit user action to change the default
handler for http and https scheme URIs.
7.15. Cross-Site Request Forgery 7.10. Cross-Site Request Forgery
An attacker might attempt to inject a request to the redirect URI of An attacker might attempt to inject a request to the redirect URI of
the legitimate client on the victim's device, e.g., to cause the the legitimate client on the victim's device, e.g., to cause the
client to access resources under the attacker's control. This is a client to access resources under the attacker's control. This is a
variant of an attack known as Cross-Site Request Forgery (CSRF). variant of an attack known as Cross-Site Request Forgery (CSRF).
The traditional countermeasure are CSRF tokens that are bound to the The traditional countermeasure are CSRF tokens that are bound to the
user agent and passed in the state parameter to the authorization user agent and passed in the state parameter to the authorization
server as described in [RFC6819]. The same protection is provided by server as described in [RFC6819]. The same protection is provided by
the code_verifier parameter or the OpenID Connect nonce value. the code_verifier parameter or the OpenID Connect nonce value.
skipping to change at page 63, line 28 skipping to change at page 60, line 28
* If state is used for carrying application state, and integrity of * If state is used for carrying application state, and integrity of
its contents is a concern, clients MUST protect state against its contents is a concern, clients MUST protect state against
tampering and swapping. This can be achieved by binding the tampering and swapping. This can be achieved by binding the
contents of state to the browser session and/or signed/encrypted contents of state to the browser session and/or signed/encrypted
state values [I-D.bradley-oauth-jwt-encoded-state]. state values [I-D.bradley-oauth-jwt-encoded-state].
AS therefore MUST provide a way to detect their supported code AS therefore MUST provide a way to detect their supported code
challenge methods either via AS metadata according to [RFC8414] or challenge methods either via AS metadata according to [RFC8414] or
provide a deployment-specific way to ensure or determine support. provide a deployment-specific way to ensure or determine support.
7.16. Clickjacking 7.11. Clickjacking
As described in Section 4.4.1.9 of [RFC6819], the authorization As described in Section 4.4.1.9 of [RFC6819], the authorization
request is susceptible to clickjacking. An attacker can use this request is susceptible to clickjacking. An attacker can use this
vector to obtain the user's authentication credentials, change the vector to obtain the user's authentication credentials, change the
scope of access granted to the client, and potentially access the scope of access granted to the client, and potentially access the
user's resources. user's resources.
Authorization servers MUST prevent clickjacking attacks. Multiple Authorization servers MUST prevent clickjacking attacks. Multiple
countermeasures are described in [RFC6819], including the use of the countermeasures are described in [RFC6819], including the use of the
X-Frame-Options HTTP response header field and frame-busting X-Frame-Options HTTP response header field and frame-busting
skipping to change at page 64, line 24 skipping to change at page 61, line 24
HTTP/1.1 200 OK Content-Security-Policy: frame-ancestors HTTP/1.1 200 OK Content-Security-Policy: frame-ancestors
https://ext.example.org:8000 Content-Security-Policy: script-src https://ext.example.org:8000 Content-Security-Policy: script-src
'self' X-Frame-Options: ALLOW-FROM https://ext.example.org:8000 ... 'self' X-Frame-Options: ALLOW-FROM https://ext.example.org:8000 ...
Because some user agents do not support [CSP-2], this technique Because some user agents do not support [CSP-2], this technique
SHOULD be combined with others, including those described in SHOULD be combined with others, including those described in
[RFC6819], unless such legacy user agents are explicitly unsupported [RFC6819], unless such legacy user agents are explicitly unsupported
by the authorization server. Even in such cases, additional by the authorization server. Even in such cases, additional
countermeasures SHOULD still be employed. countermeasures SHOULD still be employed.
7.17. Code Injection and Input Validation 7.12. Code Injection and Input Validation
A code injection attack occurs when an input or otherwise external A code injection attack occurs when an input or otherwise external
variable is used by an application unsanitized and causes variable is used by an application unsanitized and causes
modification to the application logic. This may allow an attacker to modification to the application logic. This may allow an attacker to
gain access to the application device or its data, cause denial of gain access to the application device or its data, cause denial of
service, or introduce a wide range of malicious side-effects. service, or introduce a wide range of malicious side-effects.
The authorization server and client MUST sanitize (and validate when The authorization server and client MUST sanitize (and validate when
possible) any value received - in particular, the value of the state possible) any value received - in particular, the value of the state
and redirect_uri parameters. and redirect_uri parameters.
7.18. Open Redirectors 7.13. Open Redirectors
The following attacks can occur when an AS or client has an open The following attacks can occur when an AS or client has an open
redirector. An open redirector is an endpoint that forwards a user's redirector. An open redirector is an endpoint that forwards a user's
browser to an arbitrary URI obtained from a query parameter. browser to an arbitrary URI obtained from a query parameter.
7.18.1. Client as Open Redirector 7.13.1. Client as Open Redirector
Clients MUST NOT expose open redirectors. Attackers may use open Clients MUST NOT expose open redirectors. Attackers may use open
redirectors to produce URLs pointing to the client and utilize them redirectors to produce URLs pointing to the client and utilize them
to exfiltrate authorization codes and access tokens, as described in to exfiltrate authorization codes and access tokens, as described in
(#redir_uri_open_redir). Another abuse case is to produce URLs that (#redir_uri_open_redir). Another abuse case is to produce URLs that
appear to point to the client. This might trick users into trusting appear to point to the client. This might trick users into trusting
the URL and follow it in their browser. This can be abused for the URL and follow it in their browser. This can be abused for
phishing. phishing.
In order to prevent open redirection, clients should only redirect if In order to prevent open redirection, clients should only redirect if
the target URLs are whitelisted or if the origin and integrity of a the target URLs are whitelisted or if the origin and integrity of a
request can be authenticated. Countermeasures against open request can be authenticated. Countermeasures against open
redirection are described by OWASP [owasp_redir]. redirection are described by OWASP [owasp_redir].
7.18.2. Authorization Server as Open Redirector 7.13.2. Authorization Server as Open Redirector
Just as with clients, attackers could try to utilize a user's trust Just as with clients, attackers could try to utilize a user's trust
in the authorization server (and its URL in particular) for in the authorization server (and its URL in particular) for
performing phishing attacks. OAuth authorization servers regularly performing phishing attacks. OAuth authorization servers regularly
redirect users to other web sites (the clients), but must do so in a redirect users to other web sites (the clients), but must do so in a
safe way. safe way.
Section 4.1.2.1 already prevents open redirects by stating that the Section 4.1.2.1 already prevents open redirects by stating that the
AS MUST NOT automatically redirect the user agent in case of an AS MUST NOT automatically redirect the user agent in case of an
invalid combination of client_id and redirect_uri. invalid combination of client_id and redirect_uri.
skipping to change at page 65, line 35 skipping to change at page 62, line 35
and intentionally send an erroneous authorization request, e.g., by and intentionally send an erroneous authorization request, e.g., by
using an invalid scope value, thus instructing the AS to redirect the using an invalid scope value, thus instructing the AS to redirect the
user agent to its phishing site. user agent to its phishing site.
The AS MUST take precautions to prevent this threat. Based on its The AS MUST take precautions to prevent this threat. Based on its
risk assessment, the AS needs to decide whether it can trust the risk assessment, the AS needs to decide whether it can trust the
redirect URI and SHOULD only automatically redirect the user agent if redirect URI and SHOULD only automatically redirect the user agent if
it trusts the redirect URI. If the URI is not trusted, the AS MAY it trusts the redirect URI. If the URI is not trusted, the AS MAY
inform the user and rely on the user to make the correct decision. inform the user and rely on the user to make the correct decision.
7.19. Authorization Server Mix-Up Mitigation in Native Apps 7.14. Authorization Server Mix-Up Mitigation in Native Apps
(TODO: merge this with the regular mix-up section when it is brought (TODO: merge this with the regular mix-up section when it is brought
in) in)
To protect against a compromised or malicious authorization server To protect against a compromised or malicious authorization server
attacking another authorization server used by the same app, it is attacking another authorization server used by the same app, it is
REQUIRED that a unique redirect URI is used for each authorization REQUIRED that a unique redirect URI is used for each authorization
server used by the app (for example, by varying the path component), server used by the app (for example, by varying the path component),
and that authorization responses are rejected if the redirect URI and that authorization responses are rejected if the redirect URI
they were received on doesn't match the redirect URI in an outgoing they were received on doesn't match the redirect URI in an outgoing
authorization request. authorization request.
The native app MUST store the redirect URI used in the authorization The native app MUST store the redirect URI used in the authorization
request with the authorization session data (i.e., along with state request with the authorization session data (i.e., along with state
and other related data) and MUST verify that the URI on which the and other related data) and MUST verify that the URI on which the
authorization response was received exactly matches it. authorization response was received exactly matches it.
The requirement of Section 7.3, specifically that authorization The requirement of Section 8.1, specifically that authorization
servers reject requests with URIs that don't match what was servers reject requests with URIs that don't match what was
registered, is also required to prevent such attacks. registered, is also required to prevent such attacks.
7.20. Embedded User Agents in Native Apps 7.15. Other Recommendations
Embedded user agents are a technically possible method for
authorizing native apps. These embedded user agents are unsafe for
use by third parties to the authorization server by definition, as
the app that hosts the embedded user agent can access the user's full
authentication credential, not just the OAuth authorization grant
that was intended for the app.
In typical web-view-based implementations of embedded user agents,
the host application can record every keystroke entered in the login
form to capture usernames and passwords, automatically submit forms
to bypass user consent, and copy session cookies and use them to
perform authenticated actions as the user.
Even when used by trusted apps belonging to the same party as the
authorization server, embedded user agents violate the principle of
least privilege by having access to more powerful credentials than
they need, potentially increasing the attack surface.
Encouraging users to enter credentials in an embedded user agent
without the usual address bar and visible certificate validation
features that browsers have makes it impossible for the user to know
if they are signing in to the legitimate site; even when they are, it
trains them that it's OK to enter credentials without validating the
site first.
Aside from the security concerns, embedded user agents do not share
the authentication state with other apps or the browser, requiring
the user to log in for every authorization request, which is often
considered an inferior user experience.
7.21. Other Recommendations
Authorization servers SHOULD NOT allow clients to influence their Authorization servers SHOULD NOT allow clients to influence their
client_id or sub value or any other claim if that can cause confusion client_id or sub value or any other claim if that can cause confusion
with a genuine resource owner (see (#client_impersonating)). with a genuine resource owner (see (#client_impersonating)).
8. Native Applications 8. Native Applications
Native applications are clients installed and executed on the device Native applications are clients installed and executed on the device
used by the resource owner (i.e., desktop application, native mobile used by the resource owner (i.e., desktop application, native mobile
application). Native applications require special consideration application). Native applications require special consideration
skipping to change at page 67, line 31 skipping to change at page 63, line 41
with the operating system to invoke the client as the handler, manual with the operating system to invoke the client as the handler, manual
copy-and-paste of the credentials, running a local web server, copy-and-paste of the credentials, running a local web server,
installing a user agent extension, or by providing a redirect URI installing a user agent extension, or by providing a redirect URI
identifying a server-hosted resource under the client's control, identifying a server-hosted resource under the client's control,
which in turn makes the response available to the native application. which in turn makes the response available to the native application.
Previously, it was common for native apps to use embedded user agents Previously, it was common for native apps to use embedded user agents
(commonly implemented with web-views) for OAuth authorization (commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app. See Section 7.20 needing to authenticate from scratch in each app. See Section 8.5.1
for a deeper analysis of the drawbacks of using embedded user agents for a deeper analysis of the drawbacks of using embedded user agents
for OAuth. for OAuth.
Native app authorization requests that use the browser are more Native app authorization requests that use the browser are more
secure and can take advantage of the user's authentication state. secure and can take advantage of the user's authentication state.
Being able to use the existing authentication session in the browser Being able to use the existing authentication session in the browser
enables single sign-on, as users don't need to authenticate to the enables single sign-on, as users don't need to authenticate to the
authorization server each time they use a new app (unless required by authorization server each time they use a new app (unless required by
the authorization server policy). the authorization server policy).
Supporting authorization flows between a native app and the browser Supporting authorization flows between a native app and the browser
is possible without changing the OAuth protocol itself, as the OAuth is possible without changing the OAuth protocol itself, as the OAuth
authorization request and response are already defined in terms of authorization request and response are already defined in terms of
URIs. This encompasses URIs that can be used for inter-app URIs. This encompasses URIs that can be used for inter-app
communication. Some OAuth server implementations that assume all communication. Some OAuth server implementations that assume all
clients are confidential web clients will need to add an clients are confidential web clients will need to add an
understanding of public native app clients and the types of redirect understanding of public native app clients and the types of redirect
URIs they use to support this best practice. URIs they use to support this best practice.
8.1. Using Inter-App URI Communication for OAuth in Native Apps 8.1. Registration of Native App Clients
Except when using a mechanism like Dynamic Client Registration
[RFC7591] to provision per-instance secrets, native apps are
classified as public clients, as defined in Section 2.1; they MUST be
registered with the authorization server as such. Authorization
servers MUST record the client type in the client registration
details in order to identify and process requests accordingly.
8.1.1. Client Authentication of Native Apps
Secrets that are statically included as part of an app distributed to
multiple users should not be treated as confidential secrets, as one
user may inspect their copy and learn the shared secret. For this
reason, it is NOT RECOMMENDED for authorization servers to require
client authentication of public native apps clients using a shared
secret, as this serves little value beyond client identification
which is already provided by the client_id request parameter.
Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public
client (as defined in Section 2.1), and not accept the secret as
proof of the client's identity. Without additional measures, such
clients are subject to client impersonation (see Section 7.3.1).
8.2. Using Inter-App URI Communication for OAuth in Native Apps
Just as URIs are used for OAuth on the web to initiate the Just as URIs are used for OAuth on the web to initiate the
authorization request and return the authorization response to the authorization request and return the authorization response to the
requesting website, URIs can be used by native apps to initiate the requesting website, URIs can be used by native apps to initiate the
authorization request in the device's browser and return the response authorization request in the device's browser and return the response
to the requesting native app. to the requesting native app.
By adopting the same methods used on the web for OAuth, benefits seen By adopting the same methods used on the web for OAuth, benefits seen
in the web context like the usability of a single sign-on session and in the web context like the usability of a single sign-on session and
the security of a separate authentication context are likewise gained the security of a separate authentication context are likewise gained
in the native app context. Reusing the same approach also reduces in the native app context. Reusing the same approach also reduces
the implementation complexity and increases interoperability by the implementation complexity and increases interoperability by
relying on standards-based web flows that are not specific to a relying on standards-based web flows that are not specific to a
particular platform. particular platform.
Native apps MUST use an external user agent to perform OAuth Native apps MUST use an external user agent to perform OAuth
authorization requests. This is achieved by opening the authorization requests. This is achieved by opening the
authorization request in the browser (detailed in Section 8.2) and authorization request in the browser (detailed in Section 8.3) and
using a redirect URI that will return the authorization response back using a redirect URI that will return the authorization response back
to the native app (defined in Section 8.3). to the native app (defined in Section 8.4).
8.2. Initiating the Authorization Request from a Native App 8.3. Initiating the Authorization Request from a Native App
Native apps needing user authorization create an authorization Native apps needing user authorization create an authorization
request URI with the authorization code grant type per Section 4.1 request URI with the authorization code grant type per Section 4.1
using a redirect URI capable of being received by the native app. using a redirect URI capable of being received by the native app.
The function of the redirect URI for a native app authorization The function of the redirect URI for a native app authorization
request is similar to that of a web-based authorization request. request is similar to that of a web-based authorization request.
Rather than returning the authorization response to the OAuth Rather than returning the authorization response to the OAuth
client's server, the redirect URI used by a native app returns the client's server, the redirect URI used by a native app returns the
response to the app. Several options for a redirect URI that will response to the app. Several options for a redirect URI that will
return the authorization response to the native app in different return the authorization response to the native app in different
platforms are documented in Section 8.3. Any redirect URI that platforms are documented in Section 8.4. Any redirect URI that
allows the app to receive the URI and inspect its parameters is allows the app to receive the URI and inspect its parameters is
viable. viable.
After constructing the authorization request URI, the app uses After constructing the authorization request URI, the app uses
platform-specific APIs to open the URI in an external user agent. platform-specific APIs to open the URI in an external user agent.
Typically, the external user agent used is the default browser, that Typically, the external user agent used is the default browser, that
is, the application configured for handling http and https scheme is, the application configured for handling http and https scheme
URIs on the system; however, different browser selection criteria and URIs on the system; however, different browser selection criteria and
other categories of external user agents MAY be used. other categories of external user agents MAY be used.
skipping to change at page 69, line 18 skipping to change at page 66, line 13
use is out of scope for this specification. use is out of scope for this specification.
Some platforms support a browser feature known as "in-app browser Some platforms support a browser feature known as "in-app browser
tabs", where an app can present a tab of the browser within the app tabs", where an app can present a tab of the browser within the app
context without switching apps, but still retain key benefits of the context without switching apps, but still retain key benefits of the
browser such as a shared authentication state and security context. browser such as a shared authentication state and security context.
On platforms where they are supported, it is RECOMMENDED, for On platforms where they are supported, it is RECOMMENDED, for
usability reasons, that apps use in-app browser tabs for the usability reasons, that apps use in-app browser tabs for the
authorization request. authorization request.
8.3. Receiving the Authorization Response in a Native App 8.4. Receiving the Authorization Response in a Native App
There are several redirect URI options available to native apps for There are several redirect URI options available to native apps for
receiving the authorization response from the browser, the receiving the authorization response from the browser, the
availability and user experience of which varies by platform. availability and user experience of which varies by platform.
To fully support native apps, authorization servers MUST offer at To fully support native apps, authorization servers MUST offer at
least the three redirect URI options described in the following least the three redirect URI options described in the following
subsections to native apps. Native apps MAY use whichever redirect subsections to native apps. Native apps MAY use whichever redirect
option suits their needs best, taking into account platform-specific option suits their needs best, taking into account platform-specific
implementation details. implementation details.
8.3.1. Private-Use URI Scheme Redirection 8.4.1. Private-Use URI Scheme Redirection
Many mobile and desktop computing platforms support inter-app Many mobile and desktop computing platforms support inter-app
communication via URIs by allowing apps to register private-use URI communication via URIs by allowing apps to register private-use URI
schemes (sometimes colloquially referred to as "custom URL schemes") schemes (sometimes colloquially referred to as "custom URL schemes")
like com.example.app. When the browser or another app attempts to like com.example.app. When the browser or another app attempts to
load a URI with a private-use URI scheme, the app that registered it load a URI with a private-use URI scheme, the app that registered it
is launched to handle the request. is launched to handle the request.
To perform an authorization request with a private-use URI scheme To perform an authorization request with a private-use URI scheme
redirect, the native app launches the browser with a standard redirect, the native app launches the browser with a standard
skipping to change at page 70, line 29 skipping to change at page 67, line 25
com.example.app:/oauth2redirect/example-provider com.example.app:/oauth2redirect/example-provider
When the authorization server completes the request, it redirects to When the authorization server completes the request, it redirects to
the client's redirect URI as it would normally. As the redirect URI the client's redirect URI as it would normally. As the redirect URI
uses a private-use URI scheme, it results in the operating system uses a private-use URI scheme, it results in the operating system
launching the native app, passing in the URI as a launch parameter. launching the native app, passing in the URI as a launch parameter.
Then, the native app uses normal processing for the authorization Then, the native app uses normal processing for the authorization
response. response.
8.3.2. Claimed "https" Scheme URI Redirection 8.4.2. Claimed "https" Scheme URI Redirection
Some operating systems allow apps to claim https scheme [RFC7230] Some operating systems allow apps to claim https scheme [RFC7230]
URIs in the domains they control. When the browser encounters a URIs in the domains they control. When the browser encounters a
claimed URI, instead of the page being loaded in the browser, the claimed URI, instead of the page being loaded in the browser, the
native app is launched with the URI supplied as a launch parameter. native app is launched with the URI supplied as a launch parameter.
Such URIs can be used as redirect URIs by native apps. They are Such URIs can be used as redirect URIs by native apps. They are
indistinguishable to the authorization server from a regular web- indistinguishable to the authorization server from a regular web-
based client redirect URI. An example is: based client redirect URI. An example is:
https://app.example.com/oauth2redirect/example-provider https://app.example.com/oauth2redirect/example-provider
As the redirect URI alone is not enough to distinguish public native As the redirect URI alone is not enough to distinguish public native
app clients from confidential web clients, it is REQUIRED in app clients from confidential web clients, it is REQUIRED in
Section 7.3 that the client type be recorded during client Section 8.1 that the client type be recorded during client
registration to enable the server to determine the client type and registration to enable the server to determine the client type and
act accordingly. act accordingly.
App-claimed https scheme redirect URIs have some advantages compared App-claimed https scheme redirect URIs have some advantages compared
to other native app redirect options in that the identity of the to other native app redirect options in that the identity of the
destination app is guaranteed to the authorization server by the destination app is guaranteed to the authorization server by the
operating system. For this reason, native apps SHOULD use them over operating system. For this reason, native apps SHOULD use them over
the other options where possible. the other options where possible.
8.3.3. Loopback Interface Redirection 8.4.3. Loopback Interface Redirection
Native apps that are able to open a port on the loopback network Native apps that are able to open a port on the loopback network
interface without needing special permissions (typically, those on interface without needing special permissions (typically, those on
desktop operating systems) can use the loopback interface to receive desktop operating systems) can use the loopback interface to receive
the OAuth redirect. the OAuth redirect.
Loopback redirect URIs use the http scheme and are constructed with Loopback redirect URIs use the http scheme and are constructed with
the loopback IP literal and whatever port the client is listening on. the loopback IP literal and whatever port the client is listening on.
That is, http://127.0.0.1:{port}/{path} for IPv4, and That is, http://127.0.0.1:{port}/{path} for IPv4, and
skipping to change at page 72, line 5 skipping to change at page 68, line 45
The authorization server MUST allow any port to be specified at the The authorization server MUST allow any port to be specified at the
time of the request for loopback IP redirect URIs, to accommodate time of the request for loopback IP redirect URIs, to accommodate
clients that obtain an available ephemeral port from the operating clients that obtain an available ephemeral port from the operating
system at the time of the request. system at the time of the request.
Clients SHOULD NOT assume that the device supports a particular Clients SHOULD NOT assume that the device supports a particular
version of the Internet Protocol. It is RECOMMENDED that clients version of the Internet Protocol. It is RECOMMENDED that clients
attempt to bind to the loopback interface using both IPv4 and IPv6 attempt to bind to the loopback interface using both IPv4 and IPv6
and use whichever is available. and use whichever is available.
8.5. Security Considerations in Native Apps
8.5.1. Embedded User Agents in Native Apps
Embedded user agents are a technically possible method for
authorizing native apps. These embedded user agents are unsafe for
use by third parties to the authorization server by definition, as
the app that hosts the embedded user agent can access the user's full
authentication credentials, not just the OAuth authorization grant
that was intended for the app.
In typical web-view-based implementations of embedded user agents,
the host application can record every keystroke entered in the login
form to capture usernames and passwords, automatically submit forms
to bypass user consent, and copy session cookies and use them to
perform authenticated actions as the user.
Even when used by trusted apps belonging to the same party as the
authorization server, embedded user agents violate the principle of
least privilege by having access to more powerful credentials than
they need, potentially increasing the attack surface.
Encouraging users to enter credentials in an embedded user agent
without the usual address bar and visible certificate validation
features that browsers have makes it impossible for the user to know
if they are signing in to the legitimate site; even when they are, it
trains them that it's OK to enter credentials without validating the
site first.
Aside from the security concerns, embedded user agents do not share
the authentication state with other apps or the browser, requiring
the user to log in for every authorization request, which is often
considered an inferior user experience.
8.5.2. Fake External User-Agents in Native Apps
The native app that is initiating the authorization request has a
large degree of control over the user interface and can potentially
present a fake external user agent, that is, an embedded user agent
made to appear as an external user agent.
When all good actors are using external user agents, the advantage is
that it is possible for security experts to detect bad actors, as
anyone faking an external user agent is provably bad. On the other
hand, if good and bad actors alike are using embedded user agents,
bad actors don't need to fake anything, making them harder to detect.
Once a malicious app is detected, it may be possible to use this
knowledge to blacklist the app's signature in malware scanning
software, take removal action (in the case of apps distributed by app
stores) and other steps to reduce the impact and spread of the
malicious app.
Authorization servers can also directly protect against fake external
user agents by requiring an authentication factor only available to
true external user agents.
Users who are particularly concerned about their security when using
in-app browser tabs may also take the additional step of opening the
request in the full browser from the in-app browser tab and complete
the authorization there, as most implementations of the in-app
browser tab pattern offer such functionality.
8.5.3. Malicious External User-Agents in Native Apps
If a malicious app is able to configure itself as the default handler
for https scheme URIs in the operating system, it will be able to
intercept authorization requests that use the default browser and
abuse this position of trust for malicious ends such as phishing the
user.
This attack is not confined to OAuth; a malicious app configured in
this way would present a general and ongoing risk to the user beyond
OAuth usage by native apps. Many operating systems mitigate this
issue by requiring an explicit user action to change the default
handler for http and https scheme URIs.
9. Browser-Based Apps 9. Browser-Based Apps
Browser-based apps are are clients that run in a web browser, Browser-based apps are are clients that run in a web browser,
typically written in JavaScript, also known as "single-page apps". typically written in JavaScript, also known as "single-page apps".
These types of apps have particular security considerations similar These types of apps have particular security considerations similar
to native apps. to native apps.
TODO: Bring in the normative text of the browser-based apps BCP when TODO: Bring in the normative text of the browser-based apps BCP when
it is finalized. it is finalized.
skipping to change at page 72, line 51 skipping to change at page 71, line 41
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
* The Resource Owner Password Credentials grant is omitted from this * The Resource Owner Password Credentials grant is omitted from this
specification as per Section 2.4 of specification as per Section 2.4 of
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
* Bearer token usage omits the use of bearer tokens in the query * Bearer token usage omits the use of bearer tokens in the query
string of URIs as per Section 4.3.2 of string of URIs as per Section 4.3.2 of
[I-D.ietf-oauth-security-topics] [I-D.ietf-oauth-security-topics]
* Refresh tokens should either be sender-constrained or one-time use * Refresh tokens for public clients must either be sender-
as per Section 4.12.2 of [I-D.ietf-oauth-security-topics] constrained or one-time use as per Section 4.12.2 of
[I-D.ietf-oauth-security-topics]
10.1. Removal of the OAuth 2.0 Implicit grant
The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was
deprecated in [I-D.ietf-oauth-security-topics].
The intent of removing the Implicit grant is to no longer issue
access tokens in the authorization response, as such tokens are
vulnerable to leakage and injection, and are unable to be sender-
constrained to a client. This behavior was indicated by clients
using the response_type=token parameter. This value for the
response_type parameter is no longer defined in OAuth 2.1.
Removal of response_type=token does not have an effect on other
extension response types returning other artifacts from the
authorization endpoint, for example, response_type=id_token defined
by [OpenID].
11. IANA Considerations 11. IANA Considerations
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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[BCP195] Saint-Andre, P., "Recommendations for Secure Use of [BCP195] Saint-Andre, P., "Recommendations for Secure Use of
Transport Layer Security (TLS)", 2015. Transport Layer Security (TLS)", 2015.
[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-18, 13 April 2021, topics-19, 16 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-oauth- <https://www.ietf.org/archive/id/draft-ietf-oauth-
security-topics-18.txt>. security-topics-19.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 33 skipping to change at page 74, line 38
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>. <https://www.rfc-editor.org/info/rfc8252>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<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,
<https://www.w3.org/TR/1999/REC-html401-19991224>. <https://www.w3.org/TR/1999/REC-html401-19991224>.
skipping to change at page 76, line 16 skipping to change at page 75, line 25
<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, D. T., and H. Zandbelt, Bradley, J., Lodderstedt, D. T., and H. Zandbelt,
"Encoding claims in the OAuth 2 state parameter using a "Encoding claims in the OAuth 2 state parameter using a
JWT", Work in Progress, Internet-Draft, draft-bradley- JWT", Work in Progress, Internet-Draft, draft-bradley-
oauth-jwt-encoded-state-09, 4 November 2018, oauth-jwt-encoded-state-09, 4 November 2018,
<https://www.ietf.org/archive/id/draft-bradley-oauth-jwt- <https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-
encoded-state-09.txt>. encoded-state-09.txt>.
[I-D.ietf-oauth-access-token-jwt]
Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", Work in Progress, Internet-Draft, draft-
ietf-oauth-access-token-jwt-13, 25 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-oauth-access-
token-jwt-13.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-08, 17 May 2021, browser-based-apps-08, 17 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-oauth-browser- <https://www.ietf.org/archive/id/draft-ietf-oauth-browser-
based-apps-08.txt>. based-apps-08.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 Demonstrating Proof- Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof-
of-Possession at the Application Layer (DPoP)", Work in of-Possession at the Application Layer (DPoP)", Work in
Progress, Internet-Draft, draft-ietf-oauth-dpop-03, 7 Progress, Internet-Draft, draft-ietf-oauth-dpop-06, 1
April 2021, <https://www.ietf.org/archive/id/draft-ietf- March 2022, <https://www.ietf.org/archive/id/draft-ietf-
oauth-dpop-03.txt>. oauth-dpop-06.txt>.
[I-D.ietf-oauth-par]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
Work in Progress, Internet-Draft, draft-ietf-oauth-par-10,
29 July 2021, <https://www.ietf.org/archive/id/draft-ietf-
oauth-par-10.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-07, 12 September 2021, Draft, draft-ietf-oauth-rar-10, 26 January 2022,
<https://www.ietf.org/archive/id/draft-ietf-oauth-rar- <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-
07.txt>. 10.txt>.
[I-D.ietf-oauth-token-binding] [I-D.ietf-oauth-token-binding]
Jones, M. B., Campbell, B., Bradley, J., and W. Denniss, Jones, M. B., 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,
<https://www.ietf.org/archive/id/draft-ietf-oauth-token- <https://www.ietf.org/archive/id/draft-ietf-oauth-token-
binding-08.txt>. 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 79, line 5 skipping to change at page 77, line 44
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705, and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020, DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>. <https://www.rfc-editor.org/info/rfc8705>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>. February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/info/rfc9068>.
[RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/info/rfc9126>.
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
This section provides Augmented Backus-Naur Form (ABNF) syntax This section provides Augmented Backus-Naur Form (ABNF) syntax
descriptions for the elements defined in this specification using the descriptions for the elements defined in this specification using the
notation of [RFC5234]. The ABNF below is defined in terms of Unicode notation of [RFC5234]. The ABNF below is defined in terms of Unicode
code points [W3C.REC-xml-20081126]; these characters are typically code points [W3C.REC-xml-20081126]; these characters are typically
encoded in UTF-8. Elements are presented in the order first defined. encoded in UTF-8. Elements are presented in the order first defined.
Some of the definitions that follow use the "URI-reference" Some of the definitions that follow use the "URI-reference"
definition from [RFC3986]. definition from [RFC3986].
skipping to change at page 83, line 35 skipping to change at page 82, line 35
- 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 * [RFC9068]: JSON Web Token (JWT) Profile for OAuth 2.0 Access
for OAuth 2.0 Access Tokens 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.
skipping to change at page 84, line 11 skipping to change at page 83, line 11
- The Token Introspection extension defines a mechanism for - The Token Introspection extension defines a mechanism for
resource servers to obtain information about access tokens. resource servers to obtain information about access tokens.
* [RFC7009]: Token Revocation * [RFC7009]: Token Revocation
- The Token Revocation extension defines a mechanism for clients - The Token Revocation extension defines a mechanism for clients
to indicate to the authorization server that an access token is to indicate to the authorization server that an access token is
no longer needed. no longer needed.
* [I-D.ietf-oauth-par]: Pushed Authorization Requests * [RFC9126]: Pushed Authorization Requests
- The Pushed Authorization Requests extension describes a - The Pushed Authorization Requests extension describes a
technique of initiating an OAuth flow from the back channel, technique of initiating an OAuth flow from the back channel,
providing better security and more flexibility for building providing better security and more flexibility for building
complex authorization requests. complex authorization requests.
* [I-D.ietf-oauth-rar]: Rich Authorization Requests * [I-D.ietf-oauth-rar]: Rich Authorization Requests
- Rich Authorization Requests specifies a new parameter - Rich Authorization Requests specifies a new parameter
authorization_details that is used to carry fine-grained authorization_details that is used to carry fine-grained
authorization data in the OAuth authorization request. authorization data in the OAuth authorization request.
Appendix D. Acknowledgements Appendix D. Acknowledgements
TBD TBD
Appendix E. Document History Appendix E. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-05
* Added a section about the removal of the implicit flow
* Moved many normative requirements from security considerations
into the appropriate inline sections
* Reorganized and consolidated TLS language
* Require TLS on redirect URIs except for localhost/custom URL
scheme
* Updated refresh token guidance to match security BCP
-04 -04
* Added explicit mention of not sending access tokens in URI query strings * Added explicit mention of not sending access tokens in URI query
* Clarifications on definition of client types strings
* Consolidated text around loopback vs localhost
* Editorial clarifications throughout the document * Clarifications on definition of client types
* Consolidated text around loopback vs localhost
* Editorial clarifications throughout the document
-03 -03
* refactoring to collect all the grant types under the same top-level header in section 4 * refactoring to collect all the grant types under the same top-
* Better split normative and security consideration text into the appropriate places, both moving text that was really security considerations out of the main part of the document, as well as pulling normative requirements from the security considerations sections into the appropriate part of the main document level header in section 4
* Incorporated many of the published errata on RFC6749
* Updated references to various RFCs * Better split normative and security consideration text into the
* Editorial clarifications throughout the document appropriate places, both moving text that was really security
considerations out of the main part of the document, as well as
pulling normative requirements from the security considerations
sections into the appropriate part of the main document
* Incorporated many of the published errata on RFC6749
* Updated references to various RFCs
* Editorial clarifications throughout the document
-02 -02
-01 -01
-00 -00
* initial revision * initial revision
Authors' Addresses Authors' Addresses
Dick Hardt Dick Hardt
Hellō Hellō
Email: dick.hardt@gmail.com Email: dick.hardt@gmail.com
Aaron Parecki Aaron Parecki
Okta Okta
Email: aaron@parecki.com Email: aaron@parecki.com
URI: https://aaronparecki.com URI: https://aaronparecki.com
Torsten Lodderstedt Torsten Lodderstedt
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
 End of changes. 120 change blocks. 
561 lines changed or deleted 536 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/