< draft-parecki-oauth-v2-1-02.txt		draft-parecki-oauth-v2-1-03.txt >
	OAuth Working Group D. Hardt		OAuth Working Group D. Hardt
	Internet-Draft SignIn.Org		Internet-Draft SignIn.Org
	Intended status: Standards Track A. Parecki		Intended status: Standards Track A. Parecki
	Expires: 26 October 2020 Okta		Expires: 6 January 2021 Okta
	T. Lodderstedt		T. Lodderstedt
	yes.com		yes.com
	24 April 2020		5 July 2020
	The OAuth 2.1 Authorization Framework		The OAuth 2.1 Authorization Framework
	draft-parecki-oauth-v2-1-02		draft-parecki-oauth-v2-1-03
	Abstract		Abstract
	The OAuth 2.1 authorization framework enables a third-party		The OAuth 2.1 authorization framework enables a third-party
	application to obtain limited access to an HTTP service, either on		application to obtain limited access to an HTTP service, either on
	behalf of a resource owner by orchestrating an approval interaction		behalf of a resource owner by orchestrating an approval interaction
	between the resource owner and the HTTP service, or by allowing the		between the resource owner and the HTTP service, or by allowing the
	third-party application to obtain access on its own behalf. This		third-party application to obtain access on its own behalf. This
	specification replaces and obsoletes the OAuth 2.0 Authorization		specification replaces and obsoletes the OAuth 2.0 Authorization
	Framework described in RFC 6749.		Framework described in RFC 6749.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 26 October 2020.		This Internet-Draft will expire on 6 January 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 17		3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . 17
	3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 18		3.1.1. Response Type . . . . . . . . . . . . . . . . . . . . 18
	3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . 18		3.1.2. Redirection Endpoint . . . . . . . . . . . . . . . . 18
	3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 20		3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . 20
	3.2.1. Client Authentication . . . . . . . . . . . . . . . . 21		3.2.1. Client Authentication . . . . . . . . . . . . . . . . 21
	3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 21		3.3. Access Token Scope . . . . . . . . . . . . . . . . . . . 21
	4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 22		4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 22
	4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 22		4.1. Authorization Code Grant . . . . . . . . . . . . . . . . 22
	4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24		4.1.1. Authorization Request . . . . . . . . . . . . . . . . 24
	4.1.2. Authorization Response . . . . . . . . . . . . . . . 27		4.1.2. Authorization Response . . . . . . . . . . . . . . . 27
	4.1.3. Access Token Request . . . . . . . . . . . . . . . . 29		4.1.3. Access Token Request . . . . . . . . . . . . . . . . 30
	4.1.4. Access Token Response . . . . . . . . . . . . . . . . 31		4.1.4. Access Token Response . . . . . . . . . . . . . . . . 31
	4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 31		4.2. Client Credentials Grant . . . . . . . . . . . . . . . . 31
	4.2.1. Authorization Request and Response . . . . . . . . . 32		4.2.1. Authorization Request and Response . . . . . . . . . 32
	4.2.2. Access Token Request . . . . . . . . . . . . . . . . 32		4.2.2. Access Token Request . . . . . . . . . . . . . . . . 32
	4.2.3. Access Token Response . . . . . . . . . . . . . . . . 33		4.2.3. Access Token Response . . . . . . . . . . . . . . . . 33
	4.3. Extension Grants . . . . . . . . . . . . . . . . . . . . 33		4.3. Extension Grants . . . . . . . . . . . . . . . . . . . . 33
	5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 34		5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 34
	5.1. Successful Response . . . . . . . . . . . . . . . . . . . 34		5.1. Successful Response . . . . . . . . . . . . . . . . . . . 34
	5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 35		5.2. Error Response . . . . . . . . . . . . . . . . . . . . . 35
	6. Refreshing an Access Token . . . . . . . . . . . . . . . . . 37		6. Refreshing an Access Token . . . . . . . . . . . . . . . . . 37
	7. Accessing Protected Resources . . . . . . . . . . . . . . . . 39		6.1. Refresh Token Protection . . . . . . . . . . . . . . . . 38
			7. Accessing Protected Resources . . . . . . . . . . . . . . . . 40
	7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 40		7.1. Access Token Types . . . . . . . . . . . . . . . . . . . 40
	7.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 40		7.2. Bearer Tokens . . . . . . . . . . . . . . . . . . . . . . 41
	7.2.1. Authenticated Requests . . . . . . . . . . . . . . . 40		7.2.1. Authenticated Requests . . . . . . . . . . . . . . . 41
	7.2.2. The WWW-Authenticate Response Header Field . . . . . 42		7.2.2. The WWW-Authenticate Response Header Field . . . . . 43
	7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 44		7.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . . 44
	7.3.1. Error Codes . . . . . . . . . . . . . . . . . . . . . 44		7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 45
			7.3.1. Extension Token Types . . . . . . . . . . . . . . . . 45
	7.4. Access Token Security Considerations . . . . . . . . . . 45		7.4. Access Token Security Considerations . . . . . . . . . . 45
	7.4.1. Security Threats . . . . . . . . . . . . . . . . . . 45		7.4.1. Security Threats . . . . . . . . . . . . . . . . . . 46
	7.4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 46		7.4.2. Threat Mitigation . . . . . . . . . . . . . . . . . . 46
	7.4.3. Summary of Recommendations . . . . . . . . . . . . . 47		7.4.3. Summary of Recommendations . . . . . . . . . . . . . 48
	7.4.4. Token Replay Prevention . . . . . . . . . . . . . . . 49		7.4.4. Token Replay Prevention . . . . . . . . . . . . . . . 49
	7.4.5. Access Token Privilege Restriction . . . . . . . . . 49		7.4.5. Access Token Privilege Restriction . . . . . . . . . 50
	8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 50		8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 50
	8.1. Defining Access Token Types . . . . . . . . . . . . . . . 50		8.1. Defining Access Token Types . . . . . . . . . . . . . . . 50
	8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 50		8.2. Defining New Endpoint Parameters . . . . . . . . . . . . 51
	8.3. Defining New Authorization Grant Types . . . . . . . . . 50		8.3. Defining New Authorization Grant Types . . . . . . . . . 51
	8.4. Defining New Authorization Endpoint Response Types . . . 51		8.4. Defining New Authorization Endpoint Response Types . . . 51
	8.5. Defining Additional Error Codes . . . . . . . . . . . . . 51		8.5. Defining Additional Error Codes . . . . . . . . . . . . . 52
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 52		9. Security Considerations . . . . . . . . . . . . . . . . . . . 52
	9.1. Client Authentication . . . . . . . . . . . . . . . . . . 52		9.1. Client Authentication . . . . . . . . . . . . . . . . . . 53
	9.1.1. Client Authentication of Native Apps . . . . . . . . 53		9.1.1. Client Authentication of Native Apps . . . . . . . . 53
	9.2. Registration of Native App Clients . . . . . . . . . . . 53		9.2. Registration of Native App Clients . . . . . . . . . . . 54
	9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 54		9.3. Client Impersonation . . . . . . . . . . . . . . . . . . 54
	9.3.1. Impersonation of Native Apps . . . . . . . . . . . . 55		9.3.1. Impersonation of Native Apps . . . . . . . . . . . . 55
	9.4. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 55		9.4. Access Tokens . . . . . . . . . . . . . . . . . . . . . . 55
	9.4.1. Access Token Privilege Restriction . . . . . . . . . 55		9.4.1. Access Token Privilege Restriction . . . . . . . . . 56
	9.4.2. Access Token Replay Prevention . . . . . . . . . . . 56		9.4.2. Access Token Replay Prevention . . . . . . . . . . . 56
	9.5. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 56		9.5. Refresh Tokens . . . . . . . . . . . . . . . . . . . . . 57
	9.6. Protecting Redirect-Based Flows . . . . . . . . . . . . . 57		9.6. Client Impersonating Resource Owner . . . . . . . . . . . 57
	9.6.1. Loopback Redirect Considerations in Native Apps . . . 58		9.7. Protecting Redirect-Based Flows . . . . . . . . . . . . . 58
	9.6.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 58		9.7.1. Loopback Redirect Considerations in Native Apps . . . 58
	9.7. Authorization Codes . . . . . . . . . . . . . . . . . . . 59		9.7.2. HTTP 307 Redirect . . . . . . . . . . . . . . . . . . 59
	9.8. Request Confidentiality . . . . . . . . . . . . . . . . . 60		9.8. Authorization Codes . . . . . . . . . . . . . . . . . . . 60
	9.9. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 60		9.9. Request Confidentiality . . . . . . . . . . . . . . . . . 61
	9.10. Credentials-Guessing Attacks . . . . . . . . . . . . . . 60		9.10. Ensuring Endpoint Authenticity . . . . . . . . . . . . . 61
	9.11. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 60		9.11. Credentials-Guessing Attacks . . . . . . . . . . . . . . 62
	9.12. Fake External User-Agents in Native Apps . . . . . . . . 61		9.12. Phishing Attacks . . . . . . . . . . . . . . . . . . . . 62
	9.13. Malicious External User-Agents in Native Apps . . . . . . 61		9.13. Fake External User-Agents in Native Apps . . . . . . . . 62
	9.14. Cross-Site Request Forgery . . . . . . . . . . . . . . . 62		9.14. Malicious External User-Agents in Native Apps . . . . . . 63
	9.15. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 62		9.15. Cross-Site Request Forgery . . . . . . . . . . . . . . . 63
	9.16. Code Injection and Input Validation . . . . . . . . . . . 63		9.16. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 64
	9.17. Open Redirectors . . . . . . . . . . . . . . . . . . . . 63		9.17. Code Injection and Input Validation . . . . . . . . . . . 65
	9.17.1. Client as Open Redirector . . . . . . . . . . . . . 64		9.18. Open Redirectors . . . . . . . . . . . . . . . . . . . . 65
	9.17.2. Authorization Server as Open Redirector . . . . . . 64		9.18.1. Client as Open Redirector . . . . . . . . . . . . . 65
	9.18. Authorization Server Mix-Up Mitigation in Native Apps . . 64		9.18.2. Authorization Server as Open Redirector . . . . . . 65
	9.19. Embedded User Agents in Native Apps . . . . . . . . . . . 65
	9.20. Other Recommendations . . . . . . . . . . . . . . . . . . 66
	10. Native Applications . . . . . . . . . . . . . . . . . . . . . 66		9.19. Authorization Server Mix-Up Mitigation in Native Apps . . 66
			9.20. Embedded User Agents in Native Apps . . . . . . . . . . . 66
			9.21. Other Recommendations . . . . . . . . . . . . . . . . . . 67
			10. Native Applications . . . . . . . . . . . . . . . . . . . . . 67
	10.1. Using Inter-App URI Communication for OAuth in Native		10.1. Using Inter-App URI Communication for OAuth in Native
	Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 67		Apps . . . . . . . . . . . . . . . . . . . . . . . . . . 68
	10.2. Initiating the Authorization Request from a Native		10.2. Initiating the Authorization Request from a Native
	App . . . . . . . . . . . . . . . . . . . . . . . . . . 67		App . . . . . . . . . . . . . . . . . . . . . . . . . . 69
	10.3. Receiving the Authorization Response in a Native App . . 68		10.3. Receiving the Authorization Response in a Native App . . 70
	10.3.1. Private-Use URI Scheme Redirection . . . . . . . . . 68		10.3.1. Private-Use URI Scheme Redirection . . . . . . . . . 70
	10.3.2. Claimed "https" Scheme URI Redirection . . . . . . . 69		10.3.2. Claimed "https" Scheme URI Redirection . . . . . . . 71
	10.3.3. Loopback Interface Redirection . . . . . . . . . . . 70		10.3.3. Loopback Interface Redirection . . . . . . . . . . . 71
	11. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 71		11. Browser-Based Apps . . . . . . . . . . . . . . . . . . . . . 72
	12. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 71		12. Differences from OAuth 2.0 . . . . . . . . . . . . . . . . . 72
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
	13.1. OAuth Access Token Types Registry . . . . . . . . . . . 72		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
	13.1.1. Registration Template . . . . . . . . . . . . . . . 72		14.1. Normative References . . . . . . . . . . . . . . . . . . 73
	13.1.2. Initial Registry Contents . . . . . . . . . . . . . 73		14.2. Informative References . . . . . . . . . . . . . . . . . 76
	13.2. OAuth Parameters Registry . . . . . . . . . . . . . . . 73		Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 79
	13.2.1. Registration Template . . . . . . . . . . . . . . . 74		A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 79
	13.2.2. Initial Registry Contents . . . . . . . . . . . . . 74		A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 79
	13.3. OAuth Authorization Endpoint Response Types Registry . . 77		A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 80
	13.3.1. Registration Template . . . . . . . . . . . . . . . 77		A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 80
	13.3.2. Initial Registry Contents . . . . . . . . . . . . . 78		A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 80
	13.4. OAuth Extensions Error Registry . . . . . . . . . . . . 78		A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 80
	13.4.1. Registration Template . . . . . . . . . . . . . . . 78		A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 80
	13.4.2. Initial Registry Contents . . . . . . . . . . . . . 79		A.8. "error_description" Syntax . . . . . . . . . . . . . . . 80
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 79		A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 81
	14.1. Normative References . . . . . . . . . . . . . . . . . . 79		A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 81
	14.2. Informative References . . . . . . . . . . . . . . . . . 82		A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 81
	Appendix A. Augmented Backus-Naur Form (ABNF) Syntax . . . . . . 84		A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 81
	A.1. "client_id" Syntax . . . . . . . . . . . . . . . . . . . 85		A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 81
	A.2. "client_secret" Syntax . . . . . . . . . . . . . . . . . 85		A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 81
	A.3. "response_type" Syntax . . . . . . . . . . . . . . . . . 85		A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 81
	A.4. "scope" Syntax . . . . . . . . . . . . . . . . . . . . . 85		A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 82
	A.5. "state" Syntax . . . . . . . . . . . . . . . . . . . . . 85		A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 82
	A.6. "redirect_uri" Syntax . . . . . . . . . . . . . . . . . . 86		A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 82
	A.7. "error" Syntax . . . . . . . . . . . . . . . . . . . . . 86
	A.8. "error_description" Syntax . . . . . . . . . . . . . . . 86
	A.9. "error_uri" Syntax . . . . . . . . . . . . . . . . . . . 86
	A.10. "grant_type" Syntax . . . . . . . . . . . . . . . . . . . 86
	A.11. "code" Syntax . . . . . . . . . . . . . . . . . . . . . . 86
	A.12. "access_token" Syntax . . . . . . . . . . . . . . . . . . 87
	A.13. "token_type" Syntax . . . . . . . . . . . . . . . . . . . 87
	A.14. "expires_in" Syntax . . . . . . . . . . . . . . . . . . . 87
	A.15. "refresh_token" Syntax . . . . . . . . . . . . . . . . . 87
	A.16. Endpoint Parameter Syntax . . . . . . . . . . . . . . . . 87
	A.17. "code_verifier" Syntax . . . . . . . . . . . . . . . . . 87
	A.18. "code_challenge" Syntax . . . . . . . . . . . . . . . . . 87
	Appendix B. Use of application/x-www-form-urlencoded Media		Appendix B. Use of application/x-www-form-urlencoded Media
	Type . . . . . . . . . . . . . . . . . . . . . . . . . . 88		Type . . . . . . . . . . . . . . . . . . . . . . . . . . 82
			Appendix C. Extensions . . . . . . . . . . . . . . . . . . . . . 83
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 88		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 84
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88		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 7, line 6 ¶		skipping to change at page 6, line 51 ¶
	behalf of the resource owner and with its authorization. The term		behalf of the resource owner and with its authorization. The term
	"client" does not imply any particular implementation		"client" does not imply any particular implementation
	characteristics (e.g., whether the application executes on a		characteristics (e.g., whether the application executes on a
	server, a desktop, or other devices).		server, a desktop, or other devices).
	"authorization server": The server issuing access tokens to the		"authorization server": The server issuing access tokens to the
	client after successfully authenticating the resource owner and		client after successfully authenticating the resource owner and
	obtaining authorization. This is sometimes abbreviated as "AS".		obtaining authorization. This is sometimes abbreviated as "AS".
	The interaction between the authorization server and resource server		The interaction between the authorization server and resource server
	is beyond the scope of this specification. The authorization server		is beyond the scope of this specification, however several extension
			have been defined to provide an option for interoperability between
			resource servers and authorization servers. The authorization server
	may be the same server as the resource server or a separate entity.		may be the same server as the resource server or a separate entity.
	A single authorization server may issue access tokens accepted by		A single authorization server may issue access tokens accepted by
	multiple resource servers.		multiple resource servers.
	1.2. Protocol Flow		1.2. Protocol Flow
	+--------+ +---------------+		+--------+ +---------------+
	| |--(1)- Authorization Request ->| Resource |		| |--(1)- Authorization Request ->| Resource |
	| | | Owner |		| | | Owner |
	| |<-(2)-- Authorization Grant ---| |		| |<-(2)-- Authorization Grant ---| |
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	server. Client credentials are used as an authorization grant		server. Client credentials are used as an authorization grant
	typically when the client is acting on its own behalf (the client is		typically when the client is acting on its own behalf (the client is
	also the resource owner) or is requesting access to protected		also the resource owner) or is requesting access to protected
	resources based on an authorization previously arranged with the		resources based on an authorization previously arranged with the
	authorization server.		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 usually opaque to the client. Tokens		client. The string is opaque to the client, but depending on the
	represent specific scopes and durations of access, granted by the		authorization server, may be parseable by the resource server.
	resource owner, and enforced by the resource server and authorization
	server.		Tokens represent specific scopes and durations of access, granted by
			the resource owner, and enforced by the resource server and
			authorization server.
	The token may denote an identifier used to retrieve the authorization		The token may denote an identifier used to retrieve the authorization
	information or may self-contain the authorization information in a		information or may self-contain the authorization information in a
	verifiable manner (i.e., a token string consisting of some data and a		verifiable manner (i.e., a token string consisting of some data and a
	signature). Additional authentication credentials, which are beyond		signature). One example of a structured token format is
	the scope of this specification, may be required in order for the		[I-D.ietf-oauth-access-token-jwt], a method of encoding access token
	client to use a token.		data as a JSON Web Token [RFC7519].
			Additional authentication credentials, which are beyond the scope of
			this specification, may be required in order for the client to use a
			token. This is typically referred to as a sender-constrained access
			token, such as Mutual TLS Access Tokens [RFC8705].
	The access token provides an abstraction layer, replacing different		The access token provides an abstraction layer, replacing different
	authorization constructs (e.g., username and password) with a single		authorization constructs (e.g., username and password) with a single
	token understood by the resource server. This abstraction enables		token understood by the resource server. This abstraction enables
	issuing access tokens more restrictive than the authorization grant		issuing access tokens more restrictive than the authorization grant
	used to obtain them, as well as removing the resource server's need		used to obtain them, as well as removing the resource server's need
	to understand a wide range of authentication methods.		to understand a wide range of authentication methods.
	Access tokens can have different formats, structures, and methods of		Access tokens can have different formats, structures, and methods of
	utilization (e.g., cryptographic properties) based on the resource		utilization (e.g., cryptographic properties) based on the resource
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 46 ¶
	Figure 2: Refreshing an Expired Access Token		Figure 2: Refreshing an Expired Access Token
	The flow illustrated in Figure 2 includes the following steps:		The flow illustrated in Figure 2 includes the following steps:
	1. The client requests an access token by authenticating with the		1. The client requests an access token by authenticating with the
	authorization server and presenting an authorization grant.		authorization server and presenting an authorization grant.
	2. The authorization server authenticates the client and validates		2. The authorization server authenticates the client and validates
	the authorization grant, and if valid, issues an access token and		the authorization grant, and if valid, issues an access token and
	a refresh token.		optionally a refresh token.
	3. The client makes a protected resource request to the resource		3. The client makes a protected resource request to the resource
	server by presenting the access token.		server by presenting the access token.
	4. The resource server validates the access token, and if valid,		4. The resource server validates the access token, and if valid,
	serves the request.		serves the request.
	5. Steps (3) and (4) repeat until the access token expires. If the		5. Steps (3) and (4) repeat until the access token expires. If the
	client knows the access token expired, it skips to step (7);		client knows the access token expired, it skips to step (7);
	otherwise, it makes another protected resource request.		otherwise, it makes another protected resource request.
	6. Since the access token is invalid, the resource server returns an		6. Since the access token is invalid, the resource server returns an
	invalid token error.		invalid token error.
	7. The client requests a new access token by authenticating with the		7. The client requests a new access token by presenting the refresh
	authorization server and presenting the refresh token. The		token and providing client authentication if it has been issued
	client authentication requirements are based on the client type		credentials. The client authentication requirements are based on
	and on the authorization server policies.		the client type and on the authorization server policies.
	8. The authorization server authenticates the client and validates		8. The authorization server authenticates the client and validates
	the refresh token, and if valid, issues a new access token (and,		the refresh token, and if valid, issues a new access token (and,
	optionally, a new refresh token).		optionally, a new refresh token).
	1.6. TLS Version		1.6. TLS Version
	Whenever Transport Layer Security (TLS) is used by this		Whenever Transport Layer Security (TLS) is used by this
	specification, the appropriate version (or versions) of TLS will vary		specification, the appropriate version (or versions) of TLS will vary
	over time, based on the widespread deployment and known security		over time, based on the widespread deployment and known security
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 43 ¶
	mechanisms that meet their security requirements.		mechanisms that meet their security requirements.
	1.7. HTTP Redirections		1.7. HTTP Redirections
	This specification makes extensive use of HTTP redirections, in which		This specification makes extensive use of HTTP redirections, in which
	the client or the authorization server directs the resource owner's		the client or the authorization server directs the resource owner's
	user-agent to another destination. While the examples in this		user-agent to another destination. While the examples in this
	specification show the use of the HTTP 302 status code, any other		specification show the use of the HTTP 302 status code, any other
	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 9.6.2 for details.		implementation detail. See Section 9.7.2 for details.
	1.8. Interoperability		1.8. Interoperability
	OAuth 2.1 provides a rich authorization framework with well-defined		OAuth 2.1 provides a rich authorization framework with well-defined
	security properties. However, as a rich and highly extensible		security properties.
	framework with many optional components, on its own, this
	specification is likely to produce a wide range of non-interoperable
	implementations.
	In addition, this specification leaves a few required components		This specification leaves a few required components partially or
	partially or fully undefined (e.g., client registration,		fully undefined (e.g., client registration, authorization server
	authorization server capabilities, endpoint discovery). Without		capabilities, endpoint discovery). Some of these behaviors are
	these components, clients must be manually and specifically		defined in optional extensions which implementations can choose to
	configured against a specific authorization server and resource		use.
	server in order to interoperate.
	This framework was designed with the clear expectation that future		Please refer to Appendix C for a list of current known extensions at
	work will define prescriptive profiles and extensions necessary to		the time of this publication.
	achieve full web-scale interoperability.
	1.9. Notational Conventions		1.9. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 49 ¶
	authorization server. The means through which the client registers		authorization server. The means through which the client registers
	with the authorization server are beyond the scope of this		with the authorization server are beyond the scope of this
	specification but typically involve end-user interaction with an HTML		specification but typically involve end-user interaction with an HTML
	registration form, or by using Dynamic Client Registration		registration form, or by using Dynamic Client Registration
	([RFC7591]).		([RFC7591]).
	Client registration does not require a direct interaction between the		Client registration does not require a direct interaction between the
	client and the authorization server. When supported by the		client and the authorization server. When supported by the
	authorization server, registration can rely on other means for		authorization server, registration can rely on other means for
	establishing trust and obtaining the required client properties		establishing trust and obtaining the required client properties
	(e.g., redirection URI, client type). For example, registration can		(e.g., redirect URI, client type). For example, registration can be
	be accomplished using a self-issued or third-party-issued assertion,		accomplished using a self-issued or third-party-issued assertion, or
	or by the authorization server performing client discovery using a		by the authorization server performing client discovery using a
	trusted channel.		trusted channel.
	When registering a client, the client developer SHALL:		When registering a client, the client developer SHALL:
	* specify the client type as described in Section 2.1,		* specify the client type as described in Section 2.1,
	* provide its client redirection URIs as described in Section 3.1.2,
			* provide its client redirect URIs as described in Section 3.1.2,
	and		and
	* include any other information required by the authorization server		* include any other information required by the authorization server
	(e.g., application name, website, description, logo image, the		(e.g., application name, website, description, logo image, the
	acceptance of legal terms).		acceptance of legal terms).
	Dynamic Client Registration ([RFC7591]) defines a common general data		Dynamic Client Registration ([RFC7591]) defines a common general data
	model for clients that may be used even with manual client		model for clients that may be used even with manual client
	registration.		registration.
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 32 ¶
	Clients are identified at the authorization server by a "client_id".		Clients are identified at the authorization server by a "client_id".
	It is, for example, used by the authorization server to determine the		It is, for example, used by the authorization server to determine the
	set of redirect URIs this client can use.		set of redirect URIs this client can use.
	Clients requiring a higher level of confidence in their identity by		Clients requiring a higher level of confidence in their identity by
	the authorization server use credentials to authenticate with the		the authorization server use credentials to authenticate with the
	authorization server. Such credentials are either issued by the		authorization server. Such credentials are either issued by the
	authorization server or registered by the developer of the client		authorization server or registered by the developer of the client
	with the authorization server.		with the authorization server.
	OAuth 2.1 defines two client types:		OAuth 2.1 defines three client types:
	"confidential": Clients that have credentials are designated as		"confidential": Clients that have credentials and their identity has
	"confidential clients"		been confirmed by the AS are designated as "confidential clients"
			"credentialed": Clients that have credentials and their identity has
			been not been confirmed by the AS are designated as "credentialed
			clients"
	"public": Clients without credentials are called "public clients"		"public": Clients without credentials are called "public clients"
	Confidential clients MUST take precautions to prevent leakage and		Any clients with credentials MUST take precautions to prevent leakage
	abuse of their credentials.		and abuse of their credentials.
	Authorization servers SHOULD consider the level of confidence in a		Authorization servers SHOULD consider the level of confidence in a
	client's identity when deciding whether they allow such a client		client's identity when deciding whether they allow such a client
	access to more critical functions, such as the client credentials		access to more critical functions, such as the Client Credentials
	grant type.		grant type.
	A client may be implemented as a distributed set of components, each		A single "client_id" MUST NOT be treated as more than one type of
	with a different client type and security context (e.g., a		client.
	distributed client with both a confidential server-based component
	and a public browser-based component). If the authorization server
	does not provide support for such clients or does not provide
	guidance with regard to their registration, the client SHOULD
	register each component as a separate client.
	This specification has been designed around the following client		This specification has been designed around the following client
	profiles:		profiles:
	"web application": A web application is a confidential client		"web application": A web application is a confidential client
	running on a web server. Resource owners access the client via an		running on a web server. Resource owners access the client via an
	HTML user interface rendered in a user-agent on the device used by		HTML user interface rendered in a user-agent on the device used by
	the resource owner. The client credentials as well as any access		the resource owner. The client credentials as well as any access
	token issued to the client are stored on the web server and are		token issued to the client are stored on the web server and are
	not exposed to or accessible by the resource owner.		not exposed to or accessible by the resource owner.
	skipping to change at page 14, line 47 ¶		skipping to change at page 14, line 50 ¶
	information provided by the client. The client identifier is not a		information provided by the client. The client identifier is not a
	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 influence their		Authorization servers SHOULD NOT allow clients to choose or influence
	"client_id" value in such a way that it may be confused with the		their "client_id" value. See Section 9.6 for details.
	identifier of a genuine resource owner during subsequent protocol
	interactions.
	2.3. Client Authentication		2.3. Client Authentication
	If the client type is confidential, the client and authorization		If the client has credentials, (is a confidential or credentialed
	server establish a client authentication method suitable for the		client), the client and authorization server establish a client
	security requirements of the authorization server. The authorization		authentication method suitable for the security requirements of the
	server MAY accept any form of client authentication meeting its		authorization server. The authorization server MAY accept any form
	security requirements.		of client authentication meeting its security requirements.
	Confidential clients are typically issued (or establish) a set of		Confidential and credentialed clients are typically issued (or
	client credentials used for authenticating with the authorization		establish) a set of client credentials used for authenticating with
	server (e.g., password, public/private key pair).		the authorization server (e.g., password, public/private key pair).
	Authorization servers SHOULD use client authentication if possible.		Authorization servers SHOULD use client authentication if possible.
	It is RECOMMENDED to use asymmetric (public-key based) methods for		It is RECOMMENDED to use asymmetric (public-key based) methods for
	client authentication such as mTLS [RFC8705] or "private_key_jwt"		client authentication such as mTLS [RFC8705] or "private_key_jwt"
	[OpenID]. When asymmetric methods for client authentication are		[OpenID]. When asymmetric methods for client authentication are
	used, authorization servers do not need to store sensitive symmetric		used, authorization servers do not need to store sensitive symmetric
	keys, making these methods more robust against a number of attacks.		keys, making these methods more robust against a number of attacks.
	The authorization server MAY establish a client authentication method		The authorization server MAY establish a client authentication method
	with public clients. However, the authorization server MUST NOT rely		with public clients, which converts them to credentialed clients.
	on public client authentication for the purpose of identifying the		However, the authorization server MUST NOT rely on credentialed
	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.		request.
	2.3.1. Client Password		2.3.1. Client Password
	Clients in possession of a client password, also known as a client		Clients in possession of a client password, also known as a client
	secret, MAY use the HTTP Basic authentication scheme as defined in		secret, MAY use the HTTP Basic authentication scheme as defined in
	[RFC2617] to authenticate with the authorization server. The client		[RFC2617] 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"
	skipping to change at page 18, line 50 ¶		skipping to change at page 18, line 50 ¶
	After completing its interaction with the resource owner, the		After completing its interaction with the resource owner, the
	authorization server directs the resource owner's user-agent back to		authorization server directs the resource owner's user-agent back to
	the client. The authorization server redirects the user-agent to the		the client. The authorization server redirects the user-agent to the
	client's redirection endpoint previously established with the		client's redirection endpoint previously established with the
	authorization server during the client registration process.		authorization server during the client registration process.
	The authorization server MUST compare the two URIs using simple		The authorization server MUST compare the two URIs using simple
	string comparison as defined in [RFC3986], Section 6.2.1.		string comparison as defined in [RFC3986], Section 6.2.1.
	The redirection endpoint URI MUST be an absolute URI as defined by		The redirect URI MUST be an absolute URI as defined by [RFC3986]
	[RFC3986] Section 4.3. The endpoint URI MAY include an "application/		Section 4.3. The endpoint URI MAY include an "application/x-www-
	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.
	3.1.2.1. Endpoint Request Confidentiality		3.1.2.1. Endpoint Request Confidentiality
	The redirection endpoint SHOULD require the use of TLS as described		The redirection endpoint SHOULD require the use of TLS as described
	in Section 1.6 when the requested response type is "code", or when		in Section 1.6 when the requested response type is "code", or when
	the redirection request will result in the transmission of sensitive		the redirection request will result in the transmission of sensitive
	credentials over an open network. If TLS is not available, the		credentials over an open network. If TLS is not available, the
	skipping to change at page 19, line 27 ¶		skipping to change at page 19, line 27 ¶
	Lack of transport-layer security can have a severe impact on the		Lack of transport-layer security can have a severe impact on the
	security of the client and the protected resources it is authorized		security of the client and the protected resources it is authorized
	to access. The use of transport-layer security is particularly		to access. The use of transport-layer security is particularly
	critical when the authorization process is used as a form of		critical when the authorization process is used as a form of
	delegated end-user authentication by the client (e.g., third-party		delegated end-user authentication by the client (e.g., third-party
	sign-in service).		sign-in service).
	3.1.2.2. Registration Requirements		3.1.2.2. Registration Requirements
	The authorization server MUST require all clients to register their		The authorization server MUST require all clients to register one or
	redirection endpoint prior to utilizing the authorization endpoint.		more complete redirect URIs prior to utilizing the authorization
			endpoint. The client MAY use the "state" request parameter to
	The authorization server MUST require the client to provide one or		achieve per-request customization if needed.
	more complete redirection URIs. The client MAY use the "state"
	request parameter to achieve per-request customization if needed.
	The authorization server MAY allow the client to register multiple		The authorization server MAY allow the client to register multiple
	redirection endpoints.		redirect URIs.
	Lack of a redirection URI registration requirement can enable an		Lack of requiring registration of redirect URIs enables an attacker
	attacker to use the authorization endpoint as an open redirector as		to use the authorization endpoint as an open redirector as described
	described in Section 9.17.		in Section 9.18.
	3.1.2.3. Dynamic Configuration		3.1.2.3. Dynamic Configuration
	If multiple redirection URIs have been registered the client MUST		If multiple redirect URIs have been registered the client MUST
	include a redirection 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.
	3.1.2.4. Invalid Endpoint		3.1.2.4. 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 redirection URI, the authorization server		invalid, or mismatching redirect URI, the authorization server SHOULD
	SHOULD inform the resource owner of the error and MUST NOT		inform the resource owner of the error and MUST NOT automatically
	automatically redirect the user-agent to the invalid redirection URI.		redirect the user-agent to the invalid redirect URI.
	3.1.2.5. Endpoint Content		3.1.2.5. 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 redirection URI and the credentials it contains.		access to the redirect URI and the credentials (e.g. authorization
			code) it contains.
	The client SHOULD NOT include any third-party scripts (e.g., third-		The client SHOULD NOT include any third-party scripts (e.g., third-
	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.
	skipping to change at page 21, line 12 ¶		skipping to change at page 21, line 7 ¶
	The client MUST use the HTTP "POST" method when making access token		The client MUST use the HTTP "POST" method when making access token
	requests.		requests.
	Parameters sent without a value MUST be treated as if they were		Parameters sent without a value MUST be treated as if they were
	omitted from the request. The authorization server MUST ignore		omitted from the request. The authorization server MUST ignore
	unrecognized request parameters. Request and response parameters		unrecognized request parameters. Request and response parameters
	defined by this specification MUST NOT be included more than once.		defined by this specification MUST NOT be included more than once.
	3.2.1. Client Authentication		3.2.1. Client Authentication
	Confidential clients or other clients issued client credentials MUST		Confidential or credentialed clients client MUST authenticate with
	authenticate with the authorization server as described in		the authorization server as described in Section 2.3 when making
	Section 2.3 when making requests to the token endpoint. Client		requests to the token endpoint. Client authentication is used for:
	authentication is used for:
	* Enforcing the binding of refresh tokens and authorization codes to		* Enforcing the binding of refresh tokens and authorization codes to
	the client they were issued to. Client authentication is critical		the client they were issued to. Client authentication is critical
	when an authorization code is transmitted to the redirection		when an authorization code is transmitted to the redirection
	endpoint over an insecure channel.		endpoint over an insecure channel.
	* Recovering from a compromised client by disabling the client or		* Recovering from a compromised client by disabling the client or
	changing its credentials, thus preventing an attacker from abusing		changing its credentials, thus preventing an attacker from abusing
	stolen refresh tokens. Changing a single set of client		stolen refresh tokens. Changing a single set of client
	credentials is significantly faster than revoking an entire set of		credentials is significantly faster than revoking an entire set of
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 25 ¶
	authorization grant, which the client uses to request the access		authorization grant, which the client uses to request the access
	token. OAuth defines two grant types: authorization code and client		token. OAuth defines two grant types: authorization code and client
	credentials. It also provides an extension mechanism for defining		credentials. It also provides an extension mechanism for defining
	additional grant types.		additional grant types.
	4.1. Authorization Code Grant		4.1. Authorization Code Grant
	The authorization code grant type is used to obtain both access		The authorization code grant type is used to obtain both access
	tokens and refresh tokens.		tokens and refresh tokens.
	Since this is a redirection-based flow, the client must be capable of		Since this is a redirect-based flow, the client must be capable of
	interacting with the resource owner's user-agent (typically a web		interacting with the resource owner's user-agent (typically a web
	browser) and capable of receiving incoming requests (via redirection)		browser) and capable of receiving incoming requests (via redirection)
	from the authorization server.		from the authorization server.
	+----------+		+----------+
	| Resource |		| Resource |
	| Owner |		| Owner |
	| |		| |
	+----------+		+----------+
	^		^
	|		|
	(2)		(2)
	+----|-----+ Client Identifier +---------------+		+----|-----+ Client Identifier +---------------+
	| -+----(1)-- & Redirection URI ---->| |		| -+----(1)-- & Redirect URI ---->| |
	| User- | | Authorization |		| User- | | Authorization |
	| Agent -+----(2)-- User authenticates --->| Server |		| Agent -+----(2)-- User authenticates --->| Server |
	| | | |		| | | |
	| -+----(3)-- Authorization Code ---<| |		| -+----(3)-- Authorization Code ---<| |
	+-|----|---+ +---------------+		+-|----|---+ +---------------+
	| | ^ v		| | ^ v
	(1) (3) | |		(1) (3) | |
	| | | |		| | | |
	^ v | |		^ v | |
	+---------+ | |		+---------+ | |
	| |>---(4)-- Authorization Code ---------' |		| |>---(4)-- Authorization Code ---------' |
	| Client | & Redirection URI |		| Client | & Redirect URI |
	| | |		| | |
	| |<---(5)----- Access Token -------------------'		| |<---(5)----- Access Token -------------------'
	+---------+ (w/ Optional Refresh Token)		+---------+ (w/ Optional Refresh Token)
	Note: The lines illustrating steps (1), (2), and (3) are broken into		Note: The lines illustrating steps (1), (2), and (3) are broken into
	two parts as they pass through the user-agent.		two parts as they pass through the user-agent.
	Figure 3: Authorization Code Flow		Figure 3: Authorization Code Flow
	The flow illustrated in Figure 3 includes the following steps:		The flow illustrated in Figure 3 includes the following steps:
	(1) The client initiates the flow by directing the resource owner's		(1) The client initiates the flow by directing the resource owner's
	user-agent to the authorization endpoint. The client includes its		user-agent to the authorization endpoint. The client includes its
	client identifier, PKCE code challenge, optional requested scope,		client identifier, code challenge (derived from a generated code
	optional local state, and a redirection URI to which the		verifier), optional requested scope, optional local state, and a
	authorization server will send the user-agent back once access is		redirect URI to which the authorization server will send the user-
	granted (or denied).		agent back once access is granted (or denied).
	(2) The authorization server authenticates the resource owner (via		(2) The authorization server authenticates the resource owner (via
	the user-agent) and establishes whether the resource owner grants or		the user-agent) and establishes whether the resource owner grants or
	denies the client's access request.		denies the client's access request.
	(3) Assuming the resource owner grants access, the authorization		(3) Assuming the resource owner grants access, the authorization
	server redirects the user-agent back to the client using the		server redirects the user-agent back to the client using the redirect
	redirection URI provided earlier (in the request or during client		URI provided earlier (in the request or during client registration).
	registration). The redirection URI includes an authorization code		The redirect URI includes an authorization code and any local state
	and any local state provided by the client earlier.		provided by the client earlier.
	(4) The client requests an access token from the authorization		(4) The client requests an access token from the authorization
	server's token endpoint by including the authorization code received		server's token endpoint by including the authorization code received
	in the previous step, and including its code verifier. When making		in the previous step, and including its code verifier. When making
	the request, the client authenticates with the authorization server		the request, the client authenticates with the authorization server
	if it can. The client includes the redirection URI used to obtain		if it can. The client includes the redirect URI used to obtain the
	the authorization code for verification.		authorization code for verification.
	(5) The authorization server authenticates the client when possible,		(5) The authorization server authenticates the client when possible,
	validates the authorization code, validates the code verifier, and		validates the authorization code, validates the code verifier, and
	ensures that the redirection URI received matches the URI used to		ensures that the redirect URI received matches the URI used to
	redirect the client in step (C). If valid, the authorization server		redirect the client in step (3). If valid, the authorization server
	responds back with an access token and, optionally, a refresh token.		responds back with an access token and, optionally, a refresh token.
	4.1.1. Authorization Request		4.1.1. Authorization Request
	To begin the authorization request, the client builds the		To begin the authorization request, the client builds the
	authorization request URI by adding parameters to the authorization		authorization request URI by adding parameters to the authorization
	server's authorization endpoint URI.		server's authorization endpoint URI.
	Clients use a unique secret per authorization request to protect		Clients use a unique secret per authorization request to protect
	against code injection and CSRF attacks. The client first generates		against code injection and CSRF attacks. The client first generates
	this secret, which it can later use along with the authorization code		this secret, which it can later use along with the authorization code
	to prove that the application using the authorization code is the		to prove that the application using the authorization code is the
	same application that requested it. This practice is known as		same application that requested it. The properties "code_challenge"
	"Proof-Key for Code Exchange", or PKCE, after the OAuth 2.0 extension		and "code_verifier" are adopted from the OAuth 2.0 extension known as
	([RFC7636]) where it was originally developed.		"Proof-Key for Code Exchange", or PKCE ([RFC7636]) where this
			technique was originally developed.
	4.1.1.1. Client Creates a PKCE Code Verifier		Clients MUST use "code_challenge" and "code_verifier" and
			authorization servers MUST enforce their use except under the
			conditions described in Section 9.8. In this case, using and
			enforcing "code_challenge" and "code_verifier" as described in the
			following is still RECOMMENDED.
	The client first creates a PKCE code verifier, "code_verifier", for		4.1.1.1. Client Creates a Code Verifier
	each Authorization Request, in the following manner:
	code_verifier = high-entropy cryptographic random STRING using the		The client first creates a code verifier, "code_verifier", for each
	unreserved characters `[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"`		Authorization Request, in the following manner:
	from Section 2.3 of {{RFC3986}}, with a minimum length of 43 characters
	and a maximum length of 128 characters.		code_verifier = high-entropy cryptographic random STRING using the
			unreserved characters `[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"`
			from Section 2.3 of {{RFC3986}}, with a minimum length of 43 characters
			and a maximum length of 128 characters.
	ABNF for "code_verifier" is as follows.		ABNF for "code_verifier" is as follows.
	code-verifier = 43*128unreserved		code-verifier = 43*128unreserved
	unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"		unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
	ALPHA = %x41-5A / %x61-7A		ALPHA = %x41-5A / %x61-7A
	DIGIT = %x30-39		DIGIT = %x30-39
	NOTE: The code verifier SHOULD have enough entropy to make it		NOTE: The code verifier SHOULD have enough entropy to make it
	impractical to guess the value. It is RECOMMENDED that the output of		impractical to guess the value. It is RECOMMENDED that the output of
	a suitable random number generator be used to create a 32-octet		a suitable random number generator be used to create a 32-octet
	sequence. The octet sequence is then base64url-encoded to produce a		sequence. The octet sequence is then base64url-encoded to produce a
	43-octet URL-safe string to use as the code verifier.		43-octet URL-safe string to use as the code verifier.
	4.1.1.2. Client Creates the PKCE Code Challenge		4.1.1.2. Client Creates the Code Challenge
	The client then creates a PKCE code challenge derived from the code		The client then creates a code challenge derived from the code
	verifier by using one of the following transformations on the code		verifier by using one of the following transformations on the code
	verifier:		verifier:
	plain		plain
	code_challenge = code_verifier		code_challenge = code_verifier
	S256		S256
	code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))		code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
	If the client is capable of using "S256", it MUST use "S256", as		If the client is capable of using "S256", it MUST use "S256", as
	"S256" is Mandatory To Implement (MTI) on the server. Clients are		"S256" is Mandatory To Implement (MTI) on the server. Clients are
	permitted to use "plain" only if they cannot support "S256" for some		permitted to use "plain" only if they cannot support "S256" for some
	technical reason and know via out-of-band configuration or via		technical reason and know via out-of-band configuration or via
	Authorization Server Metadata ([RFC8414]) that the server supports		Authorization Server Metadata ([RFC8414]) that the server supports
	"plain".		"plain".
	The plain transformation is for compatibility with existing		The plain transformation is for compatibility with existing
	deployments and for constrained environments that can't use the S256		deployments and for constrained environments that can't use the
	transformation.		"S256" transformation.
	ABNF for "code_challenge" is as follows.		ABNF for "code_challenge" is as follows.
	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
	4.1.1.3. Client Initiates the Authorization Request		4.1.1.3. Client Initiates the Authorization Request
	The client constructs the request URI by adding the following		The client constructs the request URI by adding the following
	parameters to the query component of the authorization endpoint URI		parameters to the query component of the authorization endpoint URI
	using the "application/x-www-form-urlencoded" format, per Appendix B:		using the "application/x-www-form-urlencoded" format, per Appendix B:
	"response_type": REQUIRED. Value MUST be set to "code".		"response_type": REQUIRED. Value MUST be set to "code".
	"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. Code challenge.		"code_challenge": REQUIRED or RECOMMENDED (see Section 9.8). Code
			challenge.
	"code_challenge_method": OPTIONAL, defaults to "plain" if not		"code_challenge_method": OPTIONAL, defaults to "plain" if not
	present in the request. Code verifier transformation method is		present in the request. Code verifier transformation method is
	"S256" or "plain".		"S256" or "plain".
	"redirect_uri": OPTIONAL. As described in Section 3.1.2.		"redirect_uri": OPTIONAL. As described in Section 3.1.2.
	"scope": OPTIONAL. The scope of the access request as described by		"scope": OPTIONAL. The scope of the access request as described by
	Section 3.3.		Section 3.3.
	skipping to change at page 26, line 45 ¶		skipping to change at page 27, line 6 ¶
	&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. If the request is valid,		required parameters are present and valid. If the request is valid,
	the authorization server authenticates the resource owner and obtains		the authorization server authenticates the resource owner and obtains
	an authorization decision (by asking the resource owner or by		an authorization decision (by asking the resource owner or by
	establishing approval via other means).		establishing approval via other means).
	When a decision is established, the authorization server directs the		When a decision is established, the authorization server directs the
	user-agent to the provided client redirection URI using an HTTP		user-agent to the provided client redirect URI using an HTTP
	redirection response, or by other means available to it via the user-		redirection response, or by other means available to it via the user-
	agent.		agent.
	4.1.2. Authorization Response		4.1.2. Authorization Response
	If the resource owner grants the access request, the authorization		If the resource owner grants the access request, the authorization
	server issues an authorization code and delivers it to the client by		server issues an authorization code and delivers it to the client by
	adding the following parameters to the query component of the		adding the following parameters to the query component of the
	redirection URI using the "application/x-www-form-urlencoded" format,		redirect URI using the "application/x-www-form-urlencoded" format,
	per Appendix B:		per Appendix B:
	"code": REQUIRED. The authorization code generated by the		"code": REQUIRED. The authorization code generated by the
	authorization server. The authorization code MUST expire shortly		authorization server. The authorization code MUST expire shortly
	after it is issued to mitigate the risk of leaks. A maximum		after it is issued to mitigate the risk of leaks. A maximum
	authorization code lifetime of 10 minutes is RECOMMENDED. The		authorization code lifetime of 10 minutes is RECOMMENDED. The
	client MUST NOT use the authorization code more than once. If an		client MUST NOT use the authorization code more than once. If an
	authorization code is used more than once, the authorization		authorization code is used more than once, the authorization
	server MUST deny the request and SHOULD revoke (when possible) all		server MUST deny the request and SHOULD revoke (when possible) all
	tokens previously issued based on that authorization code. The		tokens previously issued based on that authorization code. The
	authorization code is bound to the client identifier and		authorization code is bound to the client identifier and redirect
	redirection URI.		URI.
	"state": REQUIRED if the "state" parameter was present in the client		"state": REQUIRED if the "state" parameter was present in the client
	authorization request. The exact value received from the client.		authorization request. The exact value received from the client.
	For example, the authorization server redirects the user-agent by		For example, the authorization server redirects the user-agent by
	sending the following HTTP response:		sending the following HTTP response:
	HTTP/1.1 302 Found		HTTP/1.1 302 Found
	Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA		Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
	&state=xyz		&state=xyz
	skipping to change at page 28, line 12 ¶		skipping to change at page 28, line 18 ¶
	include the "code_challenge" value in client requests in a form that		include the "code_challenge" value in client requests in a form that
	other entities can extract.		other entities can extract.
	The exact method that the server uses to associate the		The exact method that the server uses to associate the
	"code_challenge" with the issued "code" is out of scope for this		"code_challenge" with the issued "code" is out of scope for this
	specification.		specification.
	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
	redirection URI, or if the client identifier is missing or invalid,		redirect URI, or if the client identifier is missing or invalid, the
	the authorization server SHOULD inform the resource owner of the		authorization server SHOULD inform the resource owner of the error
	error and MUST NOT automatically redirect the user-agent to the		and MUST NOT automatically redirect the user-agent to the invalid
	invalid redirection URI.		redirect URI.
	If the client does not send the "code_challenge" in the request, the		An AS MUST reject requests without a "code_challenge" from public
	authorization endpoint MUST return the authorization error response		clients, and MUST reject such requests from other clients unless
	with the "error" value set to "invalid_request". The		there is reasonable assurance that the client mitigates authorization
	"error_description" or the response of "error_uri" SHOULD explain the		code injection in other ways. See Section 9.8 for details.
	nature of error, e.g., code challenge required.
	If the server supporting PKCE does not support the requested		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		authorization error response with "error" value set to
	"invalid_request". The "error_description" or the response of		"invalid_request". The "error_description" or the response of
	"error_uri" SHOULD explain the nature of error, e.g., transform		"error_uri" SHOULD explain the nature of error, e.g., transform
	algorithm not supported.		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 redirection URI,		fails for reasons other than a missing or invalid redirect URI, the
	the authorization server informs the client by adding the following		authorization server informs the client by adding the following
	parameters to the query component of the redirection URI using the		parameters to the query component of the redirect URI using the
	"application/x-www-form-urlencoded" format, per Appendix B:		"application/x-www-form-urlencoded" format, per Appendix B:
	"error": REQUIRED. A single ASCII [USASCII] error code from the		"error": REQUIRED. A single ASCII [USASCII] error code from the
	following:		following:
	"invalid_request": The request is missing a required parameter,		"invalid_request": The request is missing a required parameter,
	includes an invalid parameter value, includes a parameter more		includes an invalid parameter value, includes a parameter more
	than once, or is otherwise malformed.		than once, or is otherwise malformed.
	"unauthorized_client": The client is not authorized to request an		"unauthorized_client": The client is not authorized to request an
	skipping to change at page 30, line 15 ¶		skipping to change at page 30, line 24 ¶
	"code": REQUIRED. The authorization code received from the		"code": REQUIRED. The authorization code received from the
	authorization server.		authorization server.
	"redirect_uri": REQUIRED, if the "redirect_uri" parameter was		"redirect_uri": REQUIRED, if the "redirect_uri" parameter was
	included in the authorization request as described in		included in the authorization request as described in
	Section 4.1.1, and their values MUST be identical.		Section 4.1.1, and their values MUST be identical.
	"client_id": REQUIRED, if the client is not authenticating with the		"client_id": REQUIRED, if the client is not authenticating with the
	authorization server as described in Section 3.2.1.		authorization server as described in Section 3.2.1.
	"code_verifier": REQUIRED. Code verifier		"code_verifier": REQUIRED, if the "code_challenge" parameter was
			included in the authorization request. MUST NOT be used
			otherwise. The original code verifier string.
	If the client type is confidential or the client was issued client		Confidential or credentialed clients MUST authenticate with the
	credentials (or assigned other authentication requirements), the		authorization server as described in Section 3.2.1.
	client MUST authenticate with the authorization server as described
	in Section 3.2.1.
	For example, the client makes the following HTTP request using TLS		For example, the client makes the following HTTP request using TLS
	(with extra line breaks for display purposes only):		(with extra line breaks for display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA		grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
	&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed		&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed
	The authorization server MUST:		The authorization server MUST:
	* require client authentication for confidential clients or for any		* require client authentication for confidential and credentialed
	client that was issued client credentials (or with other		clients (or clients with other authentication requirements),
	authentication requirements),
	* authenticate the client if client authentication is included,		* authenticate the client if client authentication is included,
	* ensure that the authorization code was issued to the authenticated		* ensure that the authorization code was issued to the authenticated
	confidential client, or if the client is public, ensure that the		confidential or credentialed client, or if the client is public,
	code was issued to "client_id" in the request,		ensure that the code was issued to "client_id" in the request,
	* verify that the authorization code is valid,		* verify that the authorization code is valid,
	* verify the "code_verifier" by calculating the code challenge from		* verify that the "code_verifier" parameter is present if and only
	the received "code_verifier" and comparing it with the previously		if a "code_challenge" parameter was present in the authorization
	associated "code_challenge", after first transforming it according		request,
	to the "code_challenge_method" method specified by the client, and
			* if a "code_verifier" is present, verify the "code_verifier" by
			calculating the code challenge from the received "code_verifier"
			and comparing it with the previously associated "code_challenge",
			after first transforming it according to the
			"code_challenge_method" method specified by the client, and
	* ensure that the "redirect_uri" parameter is present if the		* ensure that the "redirect_uri" parameter is present if the
	"redirect_uri" parameter was included in the initial authorization		"redirect_uri" parameter was included in the initial authorization
	request as described in Section 4.1.1.3, and if included ensure		request as described in Section 4.1.1.3, and if included ensure
	that their values are identical.		that their values are identical.
	4.1.4. Access Token Response		4.1.4. Access Token Response
	If the access token request is valid and authorized, the		If the access token request is valid and authorized, the
	authorization server issues an access token and optional refresh		authorization server issues an access token and optional refresh
	skipping to change at page 31, line 43 ¶		skipping to change at page 32, line 6 ¶
	4.2. Client Credentials Grant		4.2. Client Credentials Grant
	The client can request an access token using only its client		The client can request an access token using only its client
	credentials (or other supported means of authentication) when the		credentials (or other supported means of authentication) when the
	client is requesting access to the protected resources under its		client is requesting access to the protected resources under its
	control, or those of another resource owner that have been previously		control, or those of another resource owner that have been previously
	arranged with the authorization server (the method of which is beyond		arranged with the authorization server (the method of which is beyond
	the scope of this specification).		the scope of this specification).
	The client credentials grant type MUST only be used by confidential		The client credentials grant type MUST only be used by confidential
	clients.		or credentialed clients.
	+---------+ +---------------+		+---------+ +---------------+
	| | | |		| | | |
	| |>--(A)- Client Authentication --->| Authorization |		| |>--(1)- Client Authentication --->| Authorization |
	| Client | | Server |		| Client | | Server |
	| |<--(B)---- Access Token ---------<| |		| |<--(2)---- Access Token ---------<| |
	| | | |		| | | |
	+---------+ +---------------+		+---------+ +---------------+
	Figure 4: Client Credentials Flow		Figure 4: Client Credentials Flow
	The flow illustrated in Figure 4 includes the following steps:		The flow illustrated in Figure 4 includes the following steps:
	(A) The client authenticates with the authorization server and		(1) The client authenticates with the authorization server and
	requests an access token from the token endpoint.		requests an access token from the token endpoint.
	(B) The authorization server authenticates the client, and if valid,		(2) The authorization server authenticates the client, and if valid,
	issues an access token.		issues an access token.
	4.2.1. Authorization Request and Response		4.2.1. Authorization Request and Response
	Since the client authentication is used as the authorization grant,		Since the client authentication is used as the authorization grant,
	no additional authorization request is needed.		no additional authorization request is needed.
	4.2.2. Access Token Request		4.2.2. Access Token Request
	The client makes a request to the token endpoint by adding the		The client makes a request to the token endpoint by adding the
	skipping to change at page 33, line 34 ¶		skipping to change at page 33, line 43 ¶
	"example_parameter": "example_value"		"example_parameter": "example_value"
	}		}
	4.3. Extension Grants		4.3. 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 a Security Assertion		For example, to request an access token using the Device
	Markup Language (SAML) 2.0 assertion grant type as defined by		Authorization Grant as defined by [RFC8628] after the user has
	[RFC7522], the client could make the following HTTP request using TLS		authorized the client on a separate device, the client makes the
	(with extra line breaks for display purposes only):		following HTTP request using TLS (with extra line breaks for display
			purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-		grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
	bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU		&device_code=GmRhmhcxhwEzkoEqiMEg_DnyEysNkuNhszIySk9eS
	[...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-		&client_id=C409020731
	If the access token request is valid and authorized, the		If the access token request is valid and authorized, the
	authorization server issues an access token and optional refresh		authorization server issues an access token and optional refresh
	token as described in Section 5.1. If the request failed client		token as described in Section 5.1. If the request failed client
	authentication or is invalid, the authorization server returns an		authentication or is invalid, the authorization server returns an
	error response as described in Section 5.2.		error response as described in Section 5.2.
	5. Issuing an Access Token		5. Issuing an Access Token
	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 35, line 32 ¶		skipping to change at page 35, line 46 ¶
	server are left undefined. The client should avoid making		server are left undefined. The client should avoid making
	assumptions about value sizes. The authorization server SHOULD		assumptions about value sizes. The authorization server SHOULD
	document the size of any value it issues.		document the size of any value it issues.
	5.2. Error Response		5.2. Error Response
	The authorization server responds with an HTTP 400 (Bad Request)		The authorization server responds with an HTTP 400 (Bad Request)
	status code (unless specified otherwise) and includes the following		status code (unless specified otherwise) and includes the following
	parameters with the response:		parameters with the response:
	The authorization server responds with an HTTP 400 (Bad Request)
	status code (unless specified otherwise) and includes the following
	parameters with the response:
	"error": REQUIRED. A single ASCII [USASCII] error code from the		"error": REQUIRED. A single ASCII [USASCII] error code from the
	following:		following:
	"invalid_request": The request is missing a required parameter,		"invalid_request": The request is missing a required parameter,
	includes an unsupported parameter value (other than grant		includes an unsupported parameter value (other than grant
	type), repeats a parameter, includes multiple credentials,		type), repeats a parameter, includes multiple credentials,
	utilizes more than one mechanism for authenticating the client,		utilizes more than one mechanism for authenticating the client,
	or is otherwise malformed.		contains a "code_verifier" although no "code_challenge" was
			sent in the authorization request, or is otherwise malformed.
	"invalid_client": Client authentication failed (e.g., unknown		"invalid_client": Client authentication failed (e.g., unknown
	client, no client authentication included, or unsupported		client, no client authentication included, or unsupported
	authentication method). The authorization server MAY return an		authentication method). The authorization server MAY return an
	HTTP 401 (Unauthorized) status code to indicate which HTTP		HTTP 401 (Unauthorized) status code to indicate which HTTP
	authentication schemes are supported. If the client attempted		authentication schemes are supported. If the client attempted
	to authenticate via the "Authorization" request header field,		to authenticate via the "Authorization" request header field,
	the authorization server MUST respond with an HTTP 401		the authorization server MUST respond with an HTTP 401
	(Unauthorized) status code and include the "WWW-Authenticate"		(Unauthorized) status code and include the "WWW-Authenticate"
	response header field matching the authentication scheme used		response header field matching the authentication scheme used
	by the client.		by the client.
	"invalid_grant": The provided authorization grant (e.g.,		"invalid_grant": The provided authorization grant (e.g.,
	authorization code, resource owner credentials) or refresh		authorization code, resource owner credentials) or refresh
	token is invalid, expired, revoked, does not match the		token is invalid, expired, revoked, does not match the redirect
	redirection URI used in the authorization request, or was		URI used in the authorization request, or was issued to another
	issued to another client.		client.
	"unauthorized_client": The authenticated client is not authorized		"unauthorized_client": The authenticated client is not authorized
	to use this authorization grant type.		to use this authorization grant type.
	"unsupported_grant_type": The authorization grant type is not		"unsupported_grant_type": The authorization grant type is not
	supported by the authorization server.		supported by the authorization server.
	"invalid_scope": The requested scope is invalid, unknown,		"invalid_scope": The requested scope is invalid, unknown,
	malformed, or exceeds the scope granted by the resource owner.		malformed, or exceeds the scope granted by the resource owner.
	skipping to change at page 37, line 47 ¶		skipping to change at page 38, line 11 ¶
	"refresh_token": REQUIRED. The refresh token issued to the client.		"refresh_token": REQUIRED. The refresh token issued to the client.
	"scope": OPTIONAL. The scope of the access request as described by		"scope": OPTIONAL. The scope of the access request as described by
	Section 3.3. The requested scope MUST NOT include any scope not		Section 3.3. The requested scope MUST NOT include any scope not
	originally granted by the resource owner, and if omitted is		originally granted by the resource owner, and if omitted is
	treated as equal to the scope originally granted by the resource		treated as equal to the scope originally granted by the resource
	owner.		owner.
	Because refresh tokens are typically long-lasting credentials used to		Because refresh tokens are typically long-lasting credentials used to
	request additional access tokens, the refresh token is bound to the		request additional access tokens, the refresh token is bound to the
	client to which it was issued. If the client type is confidential or		client to which it was issued. Confidential or credentialed clients
	the client was issued client credentials (or assigned other		MUST authenticate with the authorization server as described in
	authentication requirements), the client MUST authenticate with the		Section 3.2.1.
	authorization server as described in Section 3.2.1.
	For example, the client makes the following HTTP request using		For example, the client makes the following HTTP request using
	transport-layer security (with extra line breaks for display purposes		transport-layer security (with extra line breaks for display purposes
	only):		only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW		Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA		grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
	The authorization server MUST:		The authorization server MUST:
	* require client authentication for confidential clients or for any		* require client authentication for confidential or credentialed
	client that was issued client credentials (or with other		clients
	authentication requirements),
	* authenticate the client if client authentication is included and		* authenticate the client if client authentication is included and
	ensure that the refresh token was issued to the authenticated		ensure that the refresh token was issued to the authenticated
	client, and		client, and
	* validate the refresh token.		* validate the refresh token.
	Authorization server MUST utilize one of these methods to detect		6.1. Refresh Token Protection
			Authorization servers SHOULD utilize one of these methods to detect
	refresh token replay by malicious actors for public clients:		refresh token replay by malicious actors for public clients:
	* _Sender-constrained refresh tokens:_ the authorization server		* _Sender-constrained refresh tokens:_ the authorization server
	cryptographically binds the refresh token to a certain client		cryptographically binds the refresh token to a certain client
	instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705].		instance by utilizing [I-D.ietf-oauth-token-binding], [RFC8705],
			[I-D.ietf-oauth-dpop], or another suitable method.
	* _Refresh token rotation:_ the authorization server issues a new		* _Refresh token rotation:_ the authorization server issues a new
	refresh token with every access token refresh response. The		refresh token with every access token refresh response. The
	previous refresh token is invalidated but information about the		previous refresh token is invalidated but information about the
	relationship is retained by the authorization server. If a		relationship is retained by the authorization server. If a
	refresh token is compromised and subsequently used by both the		refresh token is compromised and subsequently used by both the
	attacker and the legitimate client, one of them will present an		attacker and the legitimate client, one of them will present an
	invalidated refresh token, which will inform the authorization		invalidated refresh token, which will inform the authorization
	server of the breach. The authorization server cannot determine		server of the breach. The authorization server cannot determine
	which party submitted the invalid refresh token, but it will		which party submitted the invalid refresh token, but it will
	revoke the active refresh token. This stops the attack at the		revoke the active refresh token. This stops the attack at the
	cost of forcing the legitimate client to obtain a fresh		cost of forcing the legitimate client to obtain a fresh
	authorization grant.		authorization grant.
	Implementation note: the grant to which a refresh token belongs		Implementation note: the grant to which a refresh token belongs may
	may be encoded into the refresh token itself. This can enable an		be encoded into the refresh token itself. This can enable an
	authorization server to efficiently determine the grant to which a		authorization server to efficiently determine the grant to which a
	refresh token belongs, and by extension, all refresh tokens that		refresh token belongs, and by extension, all refresh tokens that need
	need to be revoked. Authorization servers MUST ensure the		to be revoked. Authorization servers MUST ensure the integrity of
	integrity of the refresh token value in this case, for example,		the refresh token value in this case, for example, using signatures.
	using signatures.
	If valid and authorized, the authorization server issues an access		If valid and authorized, the authorization server issues an access
	token as described in Section 5.1. If the request failed		token as described in Section 5.1. If the request failed
	verification or is invalid, the authorization server returns an error		verification or is invalid, the authorization server returns an error
	response as described in Section 5.2.		response as described in Section 5.2.
	The authorization server MAY issue a new refresh token, in which case		The authorization server MAY issue a new refresh token, in which case
	the client MUST discard the old refresh token and replace it with the		the client MUST discard the old refresh token and replace it with the
	new refresh token. The authorization server MAY revoke the old		new refresh token. The authorization server MAY revoke the old
	refresh token after issuing a new refresh token to the client. If a		refresh token after issuing a new refresh token to the client. If a
	skipping to change at page 39, line 47 ¶		skipping to change at page 40, line 12 ¶
	or determined based on the client policy or the grant associated with		or determined based on the client policy or the grant associated with
	the refresh token (and its sensitivity).		the refresh token (and its sensitivity).
	7. Accessing Protected Resources		7. Accessing Protected Resources
	The client accesses protected resources by presenting the access		The client accesses protected resources by presenting the access
	token to the resource server. The resource server MUST validate the		token to the resource server. The resource server MUST validate the
	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.		authorization server, such as using Token Introspection [RFC7662] or
			a structured access token format such as a JWT
			[I-D.ietf-oauth-access-token-jwt].
	The method in which the client utilizes the access token to		The method in which the client utilizes the access token to
	authenticate with the resource server depends on the type of access		authenticate with the resource server depends on the type of access
	token issued by the authorization server. Typically, it involves		token issued by the authorization server. Typically, it involves
	using the HTTP "Authorization" request header field [RFC2617] with an		using the HTTP "Authorization" request header field [RFC2617] with an
	authentication scheme defined by the specification of the access		authentication scheme defined by the specification of the access
	token type used, such as "Bearer", defined below.		token type used, such as "Bearer", defined below.
	7.1. Access Token Types		7.1. Access Token Types
	skipping to change at page 40, line 48 ¶		skipping to change at page 41, line 19 ¶
	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 extended to include proof-of-possession		Bearer tokens may be extended to include proof-of-possession
	techniques by other specifications.		techniques by other specifications.
	7.2.1. Authenticated Requests		7.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
	requetss to resource servers. Clients MUST NOT use more than one		requests to resource servers. Clients MUST NOT use more than one
	method to transmit the token in each request.		method to transmit the token in each request.
	7.2.1.1. Authorization Request Header Field		7.2.1.1. Authorization Request Header Field
	When sending the access token in the "Authorization" request header		When sending the access token in the "Authorization" request header
	field defined by HTTP/1.1 [RFC2617], the client uses the "Bearer"		field defined by HTTP/1.1 [RFC2617], the client uses the "Bearer"
	authentication scheme to transmit the access token.		authentication scheme to transmit the access token.
	For example:		For example:
	skipping to change at page 43, line 23 ¶		skipping to change at page 43, line 49 ¶
	Committee (OATC) Online Multimedia Authorization Protocol [OMAP]		Committee (OATC) Online Multimedia Authorization Protocol [OMAP]
	OAuth 2.0 use cases, respectively:		OAuth 2.0 use cases, respectively:
	scope="openid profile email"		scope="openid profile email"
	scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"		scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
	If the protected resource request included an access token and failed		If the protected resource request included an access token and failed
	authentication, the resource server SHOULD include the "error"		authentication, the resource server SHOULD include the "error"
	attribute to provide the client with the reason why the access		attribute to provide the client with the reason why the access
	request was declined. The parameter value is described in		request was declined. The parameter value is described in
	Section 7.3.1. In addition, the resource server MAY include the		Section 7.2.3. In addition, the resource server MAY include the
	"error_description" attribute to provide developers a human-readable		"error_description" attribute to provide developers a human-readable
	explanation that is not meant to be displayed to end-users. It also		explanation that is not meant to be displayed to end-users. It also
	MAY include the "error_uri" attribute with an absolute URI		MAY include the "error_uri" attribute with an absolute URI
	identifying a human-readable web page explaining the error. The		identifying a human-readable web page explaining the error. The
	"error", "error_description", and "error_uri" attributes MUST NOT		"error", "error_description", and "error_uri" attributes MUST NOT
	appear more than once.		appear more than once.
	Values for the "scope" attribute (specified in Appendix A.4) MUST NOT		Values for the "scope" attribute (specified in Appendix A.4) MUST NOT
	include characters outside the set %x21 / %x23-5B / %x5D-7E for		include characters outside the set %x21 / %x23-5B / %x5D-7E for
	representing scope values and %x20 for delimiters between scope		representing scope values and %x20 for delimiters between scope
	skipping to change at page 44, line 10 ¶		skipping to change at page 44, line 32 ¶
	WWW-Authenticate: Bearer realm="example"		WWW-Authenticate: Bearer realm="example"
	And in response to a protected resource request with an		And in response to a protected resource request with an
	authentication attempt using an expired access token:		authentication attempt using an expired access token:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example",		WWW-Authenticate: Bearer realm="example",
	error="invalid_token",		error="invalid_token",
	error_description="The access token expired"		error_description="The access token expired"
	7.3. Error Response		7.2.3. Error Codes
	If a resource access request fails, the resource server SHOULD inform
	the client of the error. While the specifics of such error responses
	are beyond the scope of this specification, this document establishes
	a common registry in Section 13.4 for error values to be shared among
	OAuth token authentication schemes.
	New authentication schemes designed primarily for OAuth token
	authentication SHOULD define a mechanism for providing an error
	status code to the client, in which the error values allowed are
	registered in the error registry established by this specification.
	Such schemes MAY limit the set of valid error codes to a subset of
	the registered values. If the error code is returned using a named
	parameter, the parameter name SHOULD be "error".
	Other schemes capable of being used for OAuth token authentication,
	but not primarily designed for that purpose, MAY bind their error
	values to the registry in the same manner.
	New authentication schemes MAY choose to also specify the use of the
	"error_description" and "error_uri" parameters to return error
	information in a manner parallel to their usage in this
	specification.
	7.3.1. Error Codes
	When a request fails, the resource server responds using the		When a request fails, the resource server responds using the
	appropriate HTTP status code (typically, 400, 401, 403, or 405) and		appropriate HTTP status code (typically, 400, 401, 403, or 405) and
	includes one of the following error codes in the response:		includes one of the following error codes in the response:
	"invalid_request": The request is missing a required parameter,		"invalid_request": The request is missing a required parameter,
	includes an unsupported parameter or parameter value, repeats the		includes an unsupported parameter or parameter value, repeats the
	same parameter, uses more than one method for including an access		same parameter, uses more than one method for including an access
	token, or is otherwise malformed. The resource server SHOULD		token, or is otherwise malformed. The resource server SHOULD
	respond with the HTTP 400 (Bad Request) status code.		respond with the HTTP 400 (Bad Request) status code.
	skipping to change at page 45, line 21 ¶		skipping to change at page 45, line 19 ¶
	If the request lacks any authentication information (e.g., the client		If the request lacks any authentication information (e.g., the client
	was unaware that authentication is necessary or attempted using an		was unaware that authentication is necessary or attempted using an
	unsupported authentication method), the resource server SHOULD NOT		unsupported authentication method), the resource server SHOULD NOT
	include an error code or other error information.		include an error code or other error information.
	For example:		For example:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example"		WWW-Authenticate: Bearer realm="example"
	7.4. Access Token Security Considerations		7.3. Error Response
			If a resource access request fails, the resource server SHOULD inform
			the client of the error. The method by which the resource server
			does this is determined by the particular token type, such as the
			description of Bearer tokens in Section 7.2.3.
			7.3.1. Extension Token Types
			[RFC6750] establishes a common registry in Section 11.4
			(https://tools.ietf.org/html/rfc6749#section-11.4) for error values
			to be shared among OAuth token authentication schemes.
			New authentication schemes designed primarily for OAuth token
			authentication SHOULD define a mechanism for providing an error
			status code to the client, in which the error values allowed are
			registered in the error registry established by this specification.
			Such schemes MAY limit the set of valid error codes to a subset of
			the registered values. If the error code is returned using a named
			parameter, the parameter name SHOULD be "error".
			Other schemes capable of being used for OAuth token authentication,
			but not primarily designed for that purpose, MAY bind their error
			values to the registry in the same manner.
			New authentication schemes MAY choose to also specify the use of the
			"error_description" and "error_uri" parameters to return error
			information in a manner parallel to their usage in this
			specification.
			7.4. Access Token Security Considerations
	7.4.1. Security Threats		7.4.1. Security Threats
	The following list presents several common threats against protocols		The following list presents several common threats against protocols
	utilizing some form of tokens. This list of threats is based on NIST		utilizing some form of tokens. This list of threats is based on NIST
	Special Publication 800-63 [NIST800-63].		Special Publication 800-63 [NIST800-63].
	7.4.1.1. Token manufacture/modification		7.4.1.1. Token manufacture/modification
	An attacker may generate a bogus token or modify the token contents		An attacker may generate a bogus token or modify the token contents
	(such as the authentication or attribute statements) of an existing		(such as the authentication or attribute statements) of an existing
	skipping to change at page 50, line 11 ¶		skipping to change at page 50, line 44 ¶
	utilize the parameter "scope" and "authorization_details" as		utilize the parameter "scope" and "authorization_details" as
	specified in [I-D.ietf-oauth-rar] to determine those resources and/or		specified in [I-D.ietf-oauth-rar] to determine those resources and/or
	actions.		actions.
	8. Extensibility		8. Extensibility
	8.1. Defining Access Token Types		8.1. Defining Access Token Types
	Access token types can be defined in one of two ways: registered in		Access token types can be defined in one of two ways: registered in
	the Access Token Types registry (following the procedures in		the Access Token Types registry (following the procedures in
	Section 13.1), or by using a unique absolute URI as its name.		Section 11.1 of [RFC6749]), or by using a unique absolute URI as its
			name.
	Types utilizing a URI name SHOULD be limited to vendor-specific		Types utilizing a URI name SHOULD be limited to vendor-specific
	implementations that are not commonly applicable, and are specific to		implementations that are not commonly applicable, and are specific to
	the implementation details of the resource server where they are		the implementation details of the resource server where they are
	used.		used.
	All other types MUST be registered. Type names MUST conform to the		All other types MUST be registered. Type names MUST conform to the
	type-name ABNF. If the type definition includes a new HTTP		type-name ABNF. If the type definition includes a new HTTP
	authentication scheme, the type name SHOULD be identical to the HTTP		authentication scheme, the type name SHOULD be identical to the HTTP
	authentication scheme name (as defined by [RFC2617]). The token type		authentication scheme name (as defined by [RFC2617]). The token type
	"example" is reserved for use in examples.		"example" is reserved for use in examples.
	type-name = 1*name-char		type-name = 1*name-char
	name-char = "-" / "." / "_" / DIGIT / ALPHA		name-char = "-" / "." / "_" / DIGIT / ALPHA
	8.2. Defining New Endpoint Parameters		8.2. Defining New Endpoint Parameters
	New request or response parameters for use with the authorization		New request or response parameters for use with the authorization
	endpoint or the token endpoint are defined and registered in the		endpoint or the token endpoint are defined and registered in the
	OAuth Parameters registry following the procedure in Section 13.2.		OAuth Parameters registry following the procedure in Section 11.2 of
			[RFC6749].
	Parameter names MUST conform to the param-name ABNF, and parameter		Parameter names MUST conform to the param-name ABNF, and parameter
	values syntax MUST be well-defined (e.g., using ABNF, or a reference		values syntax MUST be well-defined (e.g., using ABNF, or a reference
	to the syntax of an existing parameter).		to the syntax of an existing parameter).
	param-name = 1*name-char		param-name = 1*name-char
	name-char = "-" / "." / "_" / DIGIT / ALPHA		name-char = "-" / "." / "_" / DIGIT / ALPHA
	Unregistered vendor-specific parameter extensions that are not		Unregistered vendor-specific parameter extensions that are not
	commonly applicable and that are specific to the implementation		commonly applicable and that are specific to the implementation
	details of the authorization server where they are used SHOULD		details of the authorization server where they are used SHOULD
	utilize a vendor-specific prefix that is not likely to conflict with		utilize a vendor-specific prefix that is not likely to conflict with
	other registered values (e.g., begin with 'companyname_').		other registered values (e.g., begin with 'companyname_').
	8.3. Defining New Authorization Grant Types		8.3. Defining New Authorization Grant Types
	New authorization grant types can be defined by assigning them a		New authorization grant types can be defined by assigning them a
	unique absolute URI for use with the "grant_type" parameter. If the		unique absolute URI for use with the "grant_type" parameter. If the
	extension grant type requires additional token endpoint parameters,		extension grant type requires additional token endpoint parameters,
	they MUST be registered in the OAuth Parameters registry as described		they MUST be registered in the OAuth Parameters registry as described
	by Section 13.2.		by Section 11.2 of [RFC6749].
	8.4. Defining New Authorization Endpoint Response Types		8.4. Defining New Authorization Endpoint Response Types
	New response types for use with the authorization endpoint are		New response types for use with the authorization endpoint are
	defined and registered in the Authorization Endpoint Response Types		defined and registered in the Authorization Endpoint Response Types
	registry following the procedure in Section 13.3. Response type		registry following the procedure in Section 11.3 of [RFC6749].
	names MUST conform to the response-type ABNF.		Response type names MUST conform to the response-type ABNF.
	response-type = response-name *( SP response-name )		response-type = response-name *( SP response-name )
	response-name = 1*response-char		response-name = 1*response-char
	response-char = "_" / DIGIT / ALPHA		response-char = "_" / DIGIT / ALPHA
	If a response type contains one or more space characters (%x20), it		If a response type contains one or more space characters (%x20), it
	is compared as a space-delimited list of values in which the order of		is compared as a space-delimited list of values in which the order of
	values does not matter. Only one order of values can be registered,		values does not matter. Only one order of values can be registered,
	which covers all other arrangements of the same set of values.		which covers all other arrangements of the same set of values.
	For example, an extension can define and register the "code		For example, an extension can define and register the "code
	other_token" response type. Once registered, the same combination		other_token" response type. Once registered, the same combination
	cannot be registered as "other_token code", but both values can be		cannot be registered as "other_token code", but both values can be
	used to denote the same response type.		used to denote the same response type.
	8.5. Defining Additional Error Codes		8.5. Defining Additional Error Codes
	In cases where protocol extensions (i.e., access token types,		In cases where protocol extensions (i.e., access token types,
	extension parameters, or extension grant types) require additional		extension parameters, or extension grant types) require additional
	error codes to be used with the authorization code grant error		error codes to be used with the authorization code grant error
	response (Section 4.1.2.1), the token error response (Section 5.2),		response (Section 4.1.2.1), the token error response (Section 5.2),
	or the resource access error response (Section 7.3), such error codes		or the resource access error response (Section 7.3), such error codes
	MAY be defined.		MAY be defined.
	Extension error codes MUST be registered (following the procedures in		Extension error codes MUST be registered (following the procedures in
	Section 13.4) if the extension they are used in conjunction with is a		Section 11.4 of [RFC6749]) if the extension they are used in
	registered access token type, a registered endpoint parameter, or an		conjunction with is a registered access token type, a registered
	extension grant type. Error codes used with unregistered extensions		endpoint parameter, or an extension grant type. Error codes used
	MAY be registered.		with unregistered extensions MAY be registered.
	Error codes MUST conform to the error ABNF and SHOULD be prefixed by		Error codes MUST conform to the error ABNF and SHOULD be prefixed by
	an identifying name when possible. For example, an error identifying		an identifying name when possible. For example, an error identifying
	an invalid value set to the extension parameter "example" SHOULD be		an invalid value set to the extension parameter "example" SHOULD be
	named "example_invalid".		named "example_invalid".
	error = 1*error-char		error = 1*error-char
	error-char = %x20-21 / %x23-5B / %x5D-7E		error-char = %x20-21 / %x23-5B / %x5D-7E
	9. Security Considerations		9. Security Considerations
	skipping to change at page 52, line 33 ¶		skipping to change at page 53, line 21 ¶
	[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.
	Authorization server MUST only rely on client authentication if the		Authorization server MUST only rely on client authentication if the
	process of issuance/registration and distribution of the underlying		process of issuance/registration and distribution of the underlying
	credentials ensures their confidentiality.		credentials ensures their confidentiality.
	When client authentication is not possible, the authorization server		When client authentication is not possible, the authorization server
	SHOULD employ other means to validate the client's identity - for		SHOULD employ other means to validate the client's identity - for
	example, by requiring the registration of the client redirection URI		example, by requiring the registration of the client redirect URI or
	or enlisting the resource owner to confirm identity. A valid		enlisting the resource owner to confirm identity. A valid redirect
	redirection URI is not sufficient to verify the client's identity		URI is not sufficient to verify the client's identity when asking for
	when asking for resource owner authorization but can be used to		resource owner authorization but can be used to prevent delivering
	prevent delivering credentials to a counterfeit client after		credentials to a counterfeit client after obtaining resource owner
	obtaining resource owner authorization.		authorization.
	The authorization server must consider the security implications of		The authorization server must consider the security implications of
	interacting with unauthenticated clients and take measures to limit		interacting with unauthenticated clients and take measures to limit
	the potential exposure of other credentials (e.g., refresh tokens)		the potential exposure of other credentials (e.g., refresh tokens)
	issued to such clients.		issued to such clients.
	The privileges an authorization server associates with a certain		The privileges an authorization server associates with a certain
	client identity MUST depend on the assessment of the overall process		client identity MUST depend on the assessment of the overall process
	for client identification and client credential lifecycle management.		for client identification and client credential lifecycle management.
	For example, authentication of a dynamically registered client just		For example, authentication of a dynamically registered client just
	skipping to change at page 54, line 28 ¶		skipping to change at page 55, line 8 ¶
	9.3. Client Impersonation		9.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 MUST authenticate the client whenever		The authorization server MUST authenticate the client whenever
	possible. If the authorization server cannot authenticate the client		possible. If the authorization server cannot authenticate the client
	due to the client's nature, the authorization server MUST require the		due to the client's nature, the authorization server MUST require the
	registration of any redirection URI used for receiving authorization		registration of any redirect URI used for receiving authorization
	responses and SHOULD utilize other means to protect resource owners		responses and SHOULD utilize other means to protect resource owners
	from such potentially malicious clients. For example, the		from such potentially malicious clients. For example, the
	authorization server can engage the resource owner to assist in		authorization server can engage the resource owner to assist in
	identifying the client and its origin.		identifying the client and its origin.
	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.
	skipping to change at page 56, line 49 ¶		skipping to change at page 57, line 24 ¶
	shared only among the authorization server and the client to whom the		shared only among the authorization server and the client to whom the
	refresh tokens were issued. The authorization server MUST maintain		refresh tokens were issued. The authorization server MUST maintain
	the binding between a refresh token and the client to whom it was		the binding between a refresh token and the client to whom it was
	issued. Refresh tokens MUST only be transmitted using TLS as		issued. Refresh tokens MUST only be transmitted using TLS as
	described in Section 1.6 with server authentication as defined by		described in Section 1.6 with server authentication as defined by
	[RFC2818].		[RFC2818].
	The authorization server MUST verify the binding between the refresh		The authorization server MUST verify the binding between the refresh
	token and client identity whenever the client identity can be		token and client identity whenever the client identity can be
	authenticated. When client authentication is not possible, the		authenticated. When client authentication is not possible, the
	authorization server MUST issue sender-constrained refresh tokens or		authorization server SHOULD issue sender-constrained refresh tokens
	use refresh token rotation as described in		or use refresh token rotation as described in
	(#refresh_token_protection).		(#refresh_token_protection).
	The authorization server MUST ensure that refresh tokens cannot be		The authorization server MUST ensure that refresh tokens cannot be
	generated, modified, or guessed to produce valid refresh tokens by		generated, modified, or guessed to produce valid refresh tokens by
	unauthorized parties.		unauthorized parties.
	9.6. Protecting Redirect-Based Flows		9.6. Client Impersonating Resource Owner
			Resource servers may make access control decisions based on the
			identity of the resource owner as communicated in the "sub" claim
			returned by the authorization server in a token introspection
			response [RFC7662] or other mechanisms. If a client is able to
			choose its own "client_id" during registration with the authorization
			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
			the client credentials grant may be mistaken for an access token
			authorized by the privileged user if the resource server does not
			perform additional checks.
			Authorization servers SHOULD NOT allow clients to influence their
			"client_id" or "sub" value or any other claim if that can cause
			confusion with a genuine resource owner. Where this cannot be
			avoided, authorization servers MUST provide other means for the
			resource server to distinguish between access tokens authorized by a
			resource owner from access tokens authorized by the client itself.
			9.7. Protecting Redirect-Based Flows
	When comparing client redirect URIs against pre-registered URIs,		When comparing client redirect URIs against pre-registered URIs,
	authorization servers MUST utilize exact string matching. This		authorization servers MUST utilize exact string matching. This
	measure contributes to the prevention of leakage of authorization		measure contributes to the prevention of leakage of authorization
	codes and access tokens (see (#insufficient_uri_validation)). It can		codes and access tokens (see (#insufficient_uri_validation)). It can
	also help to detect mix-up attacks (see (#mix_up)).		also help to detect mix-up attacks (see (#mix_up)).
	Clients MUST NOT expose URLs that forward the user's browser to		Clients MUST NOT expose URLs that forward the user's browser to
	arbitrary URIs obtained from a query parameter ("open redirector").		arbitrary URIs obtained from a query parameter ("open redirector").
	Open redirectors can enable exfiltration of authorization codes and		Open redirectors can enable exfiltration of authorization codes and
	access tokens, see (#open_redirector_on_client).		access tokens, see (#open_redirector_on_client).
	Clients MUST prevent Cross-Site Request Forgery (CSRF). In this		Clients MUST prevent Cross-Site Request Forgery (CSRF). In this
	context, CSRF refers to requests to the redirection endpoint that do		context, CSRF refers to requests to the redirection endpoint that do
	not originate at the authorization server, but a malicious third		not originate at the authorization server, but a malicious third
	party (see Section 4.4.1.8. of [RFC6819] for details). Clients that		party (see Section 4.4.1.8. of [RFC6819] for details). Clients that
	have ensured that the authorization server supports PKCE MAY rely the		have ensured that the authorization server supports the
	CSRF protection provided by PKCE. In OpenID Connect flows, the		"code_challenge" parameter MAY rely the CSRF protection provided by
	"nonce" parameter provides CSRF protection. Otherwise, one-time use		that mechanism. In OpenID Connect flows, the "nonce" parameter
	CSRF tokens carried in the "state" parameter that are securely bound		provides CSRF protection. Otherwise, one-time use CSRF tokens
	to the user agent MUST be used for CSRF protection (see		carried in the "state" parameter that are securely bound to the user
	(#csrf_countermeasures)).		agent MUST be used for CSRF protection (see (#csrf_countermeasures)).
	In order to prevent mix-up attacks (see (#mix_up)), clients MUST only		In order to prevent mix-up attacks (see (#mix_up)), clients MUST only
	process redirect responses of the authorization server they sent the		process redirect responses of the authorization server they sent the
	respective request to and from the same user agent this authorization		respective request to and from the same user agent this authorization
	request was initiated with. Clients MUST store the authorization		request was initiated with. Clients MUST store the authorization
	server they sent an authorization request to and bind this		server they sent an authorization request to and bind this
	information to the user agent and check that the authorization		information to the user agent and check that the authorization
	request was received from the correct authorization server. Clients		request was received from the correct authorization server. Clients
	MUST ensure that the subsequent token request, if applicable, is sent		MUST ensure that the subsequent token request, if applicable, is sent
	to the same authorization server. Clients SHOULD use distinct		to the same authorization server. Clients SHOULD use distinct
	redirect URIs for each authorization server as a means to identify		redirect URIs for each authorization server as a means to identify
	the authorization server a particular response came from.		the authorization server a particular response came from.
	An AS that redirects a request potentially containing user		An AS that redirects a request potentially containing user
	credentials MUST avoid forwarding these user credentials accidentally		credentials MUST avoid forwarding these user credentials accidentally
	(see Section 9.6.2 for details).		(see Section 9.7.2 for details).
	9.6.1. Loopback Redirect Considerations in Native Apps		9.7.1. Loopback Redirect Considerations in Native Apps
	Loopback interface redirect URIs use the "http" scheme (i.e., without		Loopback interface redirect URIs use the "http" scheme (i.e., without
	Transport Layer Security (TLS)). This is acceptable for loopback		Transport Layer Security (TLS)). This is acceptable for loopback
	interface redirect URIs as the HTTP request never leaves the device.		interface redirect URIs as the HTTP request never leaves the device.
	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.
	While redirect URIs using localhost (i.e.,		While redirect URIs using localhost (i.e.,
	"http://localhost:{port}/{path}") function similarly to loopback IP		"http://localhost:{port}/{path}") function similarly to loopback IP
	redirects described in Section 10.3.3, the use of "localhost" is NOT		redirects described in Section 10.3.3, the use of "localhost" is NOT
	RECOMMENDED. Specifying a redirect URI with the loopback IP literal		RECOMMENDED. Specifying a redirect URI with the loopback IP literal
	rather than "localhost" avoids inadvertently listening on network		rather than "localhost" avoids inadvertently listening on network
	interfaces other than the loopback interface. It is also less		interfaces other than the loopback interface. It is also less
	susceptible to client-side firewalls and misconfigured host name		susceptible to client-side firewalls and misconfigured host name
	resolution on the user's device.		resolution on the user's device.
	9.6.2. HTTP 307 Redirect		9.7.2. HTTP 307 Redirect
	An AS which redirects a request that potentially contains user		An AS which redirects a request that potentially contains user
	credentials MUST NOT use the HTTP 307 status code for redirection.		credentials MUST NOT use the HTTP 307 status code for redirection.
	If an HTTP redirection (and not, for example, JavaScript) is used for		If an HTTP redirection (and not, for example, JavaScript) is used for
	such a request, AS SHOULD use HTTP status code 303 "See Other".		such a request, AS SHOULD use HTTP status code 303 "See Other".
	At the authorization endpoint, a typical protocol flow is that the AS		At the authorization endpoint, a typical protocol flow is that the AS
	prompts the user to enter her credentials in a form that is then		prompts the user to enter her credentials in a form that is then
	submitted (using the HTTP POST method) back to the authorization		submitted (using the HTTP POST method) back to the authorization
	server. The AS checks the credentials and, if successful, redirects		server. The AS checks the credentials and, if successful, redirects
	the user agent to the client's redirection endpoint.		the user agent to the client's redirect URI.
	If the status code 307 were used for redirection, the user agent		If the status code 307 were used for redirection, the user agent
	would send the user credentials via HTTP POST to the client.		would send the user credentials via HTTP POST to the client.
	This discloses the sensitive credentials to the client. If the		This discloses the sensitive credentials to the client. If the
	relying party is malicious, it can use the credentials to impersonate		relying party is malicious, it can use the credentials to impersonate
	the user at the AS.		the user at the AS.
	The behavior might be unexpected for developers, but is defined in		The behavior might be unexpected for developers, but is defined in
	[RFC7231], Section 6.4.7. This status code does not require the user		[RFC7231], Section 6.4.7. This status code does not require the user
	skipping to change at page 59, line 14 ¶		skipping to change at page 60, line 5 ¶
	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.
	9.7. Authorization Codes		9.8. Authorization Codes
	The transmission of authorization codes MUST be made over a secure		The transmission of authorization codes MUST be made over a secure
	channel, and the client MUST require the use of TLS with its		channel, and the client MUST require the use of TLS with its redirect
	redirection URI if the URI identifies a network resource. Since		URI if the URI identifies a network resource. Since authorization
	authorization codes are transmitted via user-agent redirections, they		codes are transmitted via user-agent redirections, they could
	could potentially be disclosed through user-agent history and HTTP		potentially be disclosed through user-agent history and HTTP referrer
	referrer headers.		headers.
	Authorization codes MUST be short lived and single-use. If the		Authorization codes MUST be short lived and single-use. If the
	authorization server observes multiple attempts to exchange an		authorization server observes multiple attempts to exchange an
	authorization code for an access token, the authorization server		authorization code for an access token, the authorization server
	SHOULD attempt to revoke all refresh and access tokens already		SHOULD attempt to revoke all refresh and access tokens already
	granted based on the compromised authorization code.		granted based on the compromised authorization code.
	If the client can be authenticated, the authorization servers MUST		If the client can be authenticated, the authorization servers MUST
	authenticate the client and ensure that the authorization code was		authenticate the client and ensure that the authorization code was
	issued to the same client.		issued to the same client.
	Clients MUST prevent injection (replay) of authorization codes into		Clients MUST prevent injection (replay) of authorization codes into
	the authorization response by attackers. The use of PKCE is		the authorization response by attackers. To this end, using
	RECOMMENDED to this end. The OpenID Connect "nonce" parameter and ID		"code_challenge" and "code_verifier" is REQUIRED for clients and
	Token Claim [OpenID] MAY be used as well. The PKCE challenge or		authorization servers MUST enforce their use, unless both of the
	OpenID Connect "nonce" MUST be transaction-specific and securely		following criteria are met:
	bound to the client and the user agent in which the transaction was
	started.
	Note: although PKCE so far was designed as a mechanism to protect		* The client is a confidential or credentialed client.
	native apps, this advice applies to all kinds of OAuth clients,
	including web applications.
	When using PKCE, clients SHOULD use PKCE code challenge methods that		* In the specific deployment and the specific request, there is
	do not expose the PKCE verifier in the authorization request.		reasonable assurance for authorization server that the client
	Otherwise, attackers that can read the authorization request (cf.		implements the OpenID Connect "nonce" mechanism properly.
	Attacker A4 in (#secmodel)) can break the security provided by PKCE.
			In this case, using and enforcing "code_challenge" and
			"code_verifier" is still RECOMMENDED.
			The "code_challenge" or OpenID Connect "nonce" value MUST be
			transaction-specific and securely bound to the client and the user
			agent in which the transaction was started. If a transaction leads
			to an error, fresh values for "code_challenge" or "nonce" MUST be
			chosen.
			Historic note: Although PKCE [RFC7636] was originally designed as a
			mechanism to protect native apps, this advice applies to all kinds of
			OAuth clients, including web applications and other confidential
			clients.
			Clients SHOULD use code challenge methods that do not expose the
			"code_verifier" in the authorization request. Otherwise, attackers
			that can read the authorization request (cf. Attacker A4 in
			(#secmodel)) can break the security provided by this mechanism.
	Currently, "S256" is the only such method.		Currently, "S256" is the only such method.
	Authorization servers MUST support PKCE.		When an authorization code arrives at the token endpoint, the
			authorization server MUST do the following check:
			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 token request, and it MUST be verified according to the steps
			in Section 4.1.3. (This is no change from the current behavior
			in [RFC7636].)
			2. If there was no "code_challenge" in the authorization request,
			any request to the token endpoint containing a "code_verifier"
			MUST be 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
	PKCE. To this end, they MUST either (a) publish the element		the "code_challenge" mechanism. To this end, they MUST either (a)
	"code_challenge_methods_supported" in their AS metadata ([RFC8414])		publish the element "code_challenge_methods_supported" in their AS
	containing the supported PKCE challenge methods (which can be used by		metadata ([RFC8414]) containing the supported
	the client to detect PKCE support) or (b) provide a deployment-		"code_challenge_method"s (which can be used by the client to detect
	specific way to ensure or determine PKCE support by the AS.		support) or (b) provide a deployment-specific way to ensure or
			determine support by the AS.
	9.8. Request Confidentiality		9.9. Request Confidentiality
	Access tokens, refresh tokens, authorization codes, and client		Access tokens, refresh tokens, authorization codes, and client
	credentials MUST NOT be transmitted in the clear.		credentials MUST NOT be transmitted in the clear.
	The "state" and "scope" parameters SHOULD NOT include sensitive		The "state" and "scope" parameters SHOULD NOT include sensitive
	client or resource owner information in plain text, as they can be		client or resource owner information in plain text, as they can be
	transmitted over insecure channels or stored insecurely.		transmitted over insecure channels or stored insecurely.
	9.9. Ensuring Endpoint Authenticity		9.10. Ensuring Endpoint Authenticity
	In order to prevent man-in-the-middle attacks, the authorization		In order to prevent man-in-the-middle attacks, the authorization
	server MUST require the use of TLS with server authentication as		server MUST require the use of TLS with server authentication as
	defined by [RFC2818] for any request sent to the authorization and		defined by [RFC2818] for any request sent to the authorization and
	token endpoints. The client MUST validate the authorization server's		token endpoints. The client MUST validate the authorization server's
	TLS certificate as defined by [RFC6125] and in accordance with its		TLS certificate as defined by [RFC6125] and in accordance with its
	requirements for server identity authentication.		requirements for server identity authentication.
	9.10. Credentials-Guessing Attacks		9.11. 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.
	9.11. Phishing Attacks		9.12. 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		To reduce the risk of phishing attacks, the authorization servers
	MUST require the use of TLS on every endpoint used for end-user		MUST require the use of TLS on every endpoint used for end-user
	interaction.		interaction.
	9.12. Fake External User-Agents in Native Apps		9.13. Fake External User-Agents in Native Apps
	The native app that is initiating the authorization request has a		The native app that is initiating the authorization request has a
	large degree of control over the user interface and can potentially		large degree of control over the user interface and can potentially
	present a fake external user-agent, that is, an embedded user-agent		present a fake external user-agent, that is, an embedded user-agent
	made to appear as an external user-agent.		made to appear as an external user-agent.
	When all good actors are using external user-agents, the advantage is		When all good actors are using external user-agents, the advantage is
	that it is possible for security experts to detect bad actors, as		that it is possible for security experts to detect bad actors, as
	anyone faking an external user-agent is provably bad. On the other		anyone faking an external user-agent is provably bad. On the other
	hand, if good and bad actors alike are using embedded user-agents,		hand, if good and bad actors alike are using embedded user-agents,
	skipping to change at page 61, line 45 ¶		skipping to change at page 63, line 18 ¶
	Authorization servers can also directly protect against fake external		Authorization servers can also directly protect against fake external
	user-agents by requiring an authentication factor only available to		user-agents by requiring an authentication factor only available to
	true external user-agents.		true external user-agents.
	Users who are particularly concerned about their security when using		Users who are particularly concerned about their security when using
	in-app browser tabs may also take the additional step of opening the		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		request in the full browser from the in-app browser tab and complete
	the authorization there, as most implementations of the in-app		the authorization there, as most implementations of the in-app
	browser tab pattern offer such functionality.		browser tab pattern offer such functionality.
	9.13. Malicious External User-Agents in Native Apps		9.14. Malicious External User-Agents in Native Apps
	If a malicious app is able to configure itself as the default handler		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		for "https" scheme URIs in the operating system, it will be able to
	intercept authorization requests that use the default browser and		intercept authorization requests that use the default browser and
	abuse this position of trust for malicious ends such as phishing the		abuse this position of trust for malicious ends such as phishing the
	user.		user.
	This attack is not confined to OAuth; a malicious app configured in		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		this way would present a general and ongoing risk to the user beyond
	OAuth usage by native apps. Many operating systems mitigate this		OAuth usage by native apps. Many operating systems mitigate this
	issue by requiring an explicit user action to change the default		issue by requiring an explicit user action to change the default
	handler for "http" and "https" scheme URIs.		handler for "http" and "https" scheme URIs.
	9.14. Cross-Site Request Forgery		9.15. 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
	PKCE or the OpenID Connect "nonce" value.		the "code_verifier" parameter or the OpenID Connect "nonce" value.
	When using PKCE instead of "state" or "nonce" for CSRF protection, it		When using "code_verifier" instead of "state" or "nonce" for CSRF
	is important to note that:		protection, it is important to note that:
	* Clients MUST ensure that the AS supports PKCE before using PKCE		* Clients MUST ensure that the AS supports the
	for CSRF protection. If an authorization server does not support		"code_challenge_method" intended to be used by the client. If an
	PKCE, "state" or "nonce" MUST be used for CSRF protection.		authorization server does not support the requested method,
			"state" or "nonce" MUST be used for CSRF protection instead.
	* If "state" is used for carrying application state, and integrity		* If "state" is used for carrying application state, and integrity
	of its contents is a concern, clients MUST protect "state" against		of 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 support for PKCE		AS therefore MUST provide a way to detect their supported code
	either via AS metadata according to [RFC8414] or provide a		challenge methods either via AS metadata according to [RFC8414] or
	deployment-specific way to ensure or determine PKCE support.		provide a deployment-specific way to ensure or determine support.
	9.15. Clickjacking		9.16. 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 63, line 27 ¶		skipping to change at page 65, line 4 ¶
	patterns (see [CSP-2] for details). Level 2 of this standard		patterns (see [CSP-2] for details). Level 2 of this standard
	provides a robust mechanism for protecting against clickjacking by		provides a robust mechanism for protecting against clickjacking by
	using policies that restrict the origin of frames (using "frame-		using policies that restrict the origin of frames (using "frame-
	ancestors") together with those that restrict the sources of scripts		ancestors") together with those that restrict the sources of scripts
	allowed to execute on an HTML page (by using "script-src"). A non-		allowed to execute on an HTML page (by using "script-src"). A non-
	normative example of such a policy is shown in the following listing:		normative example of such a policy is shown in the following listing:
	"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.
	9.16. Code Injection and Input Validation		9.17. 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		possible) any value received - in particular, the value of the
	"state" and "redirect_uri" parameters.		"state" and "redirect_uri" parameters.
	9.17. Open Redirectors		9.18. 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.
	9.17.1. Client as Open Redirector		9.18.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].
	9.17.2. Authorization Server as Open Redirector		9.18.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 64, line 45 ¶		skipping to change at page 66, line 22 ¶
	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.
	9.18. Authorization Server Mix-Up Mitigation in Native Apps		9.19. 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
	skipping to change at page 65, line 18 ¶		skipping to change at page 66, line 44 ¶
	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 9.2, specifically that authorization		The requirement of Section 9.2, 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.
	9.19. Embedded User Agents in Native Apps		9.20. Embedded User Agents in Native Apps
	Embedded user-agents are a technically possible method for		Embedded user-agents are a technically possible method for
	authorizing native apps. These embedded user-agents are unsafe for		authorizing native apps. These embedded user-agents are unsafe for
	use by third parties to the authorization server by definition, as		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		the app that hosts the embedded user-agent can access the user's full
	authentication credential, not just the OAuth authorization grant		authentication credential, not just the OAuth authorization grant
	that was intended for the app.		that was intended for the app.
	In typical web-view-based implementations of embedded user-agents,		In typical web-view-based implementations of embedded user-agents,
	the host application can record every keystroke entered in the login		the host application can record every keystroke entered in the login
	skipping to change at page 66, line 5 ¶		skipping to change at page 67, line 28 ¶
	features that browsers have makes it impossible for the user to know		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		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		trains them that it's OK to enter credentials without validating the
	site first.		site first.
	Aside from the security concerns, embedded user-agents do not share		Aside from the security concerns, embedded user-agents do not share
	the authentication state with other apps or the browser, requiring		the authentication state with other apps or the browser, requiring
	the user to log in for every authorization request, which is often		the user to log in for every authorization request, which is often
	considered an inferior user experience.		considered an inferior user experience.
	9.20. Other Recommendations		9.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		"client_id" or "sub" value or any other claim if that can cause
	confusion with a genuine resource owner (see		confusion with a genuine resource owner (see
	(#client_impersonating)).		(#client_impersonating)).
	10. Native Applications		10. 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
	skipping to change at page 66, line 27 ¶		skipping to change at page 67, line 50 ¶
	related to security, platform capabilities, and overall end-user		related to security, platform capabilities, and overall end-user
	experience.		experience.
	The authorization endpoint requires interaction between the client		The authorization endpoint requires interaction between the client
	and the resource owner's user-agent. The best current practice is to		and the resource owner's user-agent. The best current practice is to
	perform the OAuth authorization request in an external user-agent		perform the OAuth authorization request in an external user-agent
	(typically the browser) rather than an embedded user-agent (such as		(typically the browser) rather than an embedded user-agent (such as
	one implemented with web-views).		one implemented with web-views).
	The native application can capture the response from the		The native application can capture the response from the
	authorization server using a redirection URI with a scheme registered		authorization server using a redirect URI with a scheme registered
	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 redirection 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 9.19		needing to authenticate from scratch in each app. See Section 9.20
	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).
	skipping to change at page 68, line 18 ¶		skipping to change at page 69, line 40 ¶
	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.
	This best practice focuses on the browser as the RECOMMENDED external		This best practice focuses on the browser as the RECOMMENDED external
	user-agent for native apps. An external user-agent designed		user-agent for native apps. An external user-agent designed
	specifically for user authorization and capable of processing		specifically for user authorization and capable of processing
	authorization requests and responses like a browser MAY also be used.		authorization requests and responses like a browser MAY also be used.
	Other external user-agents, such as a native app provided by the		Other external user-agents, such as a native app provided by the
	authorization server may meet the criteria set out in this best		authorization server may meet the criteria set out in this best
	practice, including using the same redirection URI properties, but		practice, including using the same redirect URI properties, but their
	their 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.
	10.3. Receiving the Authorization Response in a Native App		10.3. Receiving the Authorization Response in a Native App
	skipping to change at page 69, line 7 ¶		skipping to change at page 70, line 28 ¶
	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
	authorization request, but one where the redirection URI utilizes a		authorization request, but one where the redirect URI utilizes a
	private-use URI scheme it registered with the operating system.		private-use URI scheme it registered with the operating system.
	When choosing a URI scheme to associate with the app, apps MUST use a		When choosing a URI scheme to associate with the app, apps MUST use a
	URI scheme based on a domain name under their control, expressed in		URI scheme based on a domain name under their control, expressed in
	reverse order, as recommended by Section 3.8 of [RFC7595] for		reverse order, as recommended by Section 3.8 of [RFC7595] for
	private-use URI schemes.		private-use URI schemes.
	For example, an app that controls the domain name "app.example.com"		For example, an app that controls the domain name "app.example.com"
	can use "com.example.app" as their scheme. Some authorization		can use "com.example.app" as their scheme. Some authorization
	servers assign client identifiers based on domain names, for example,		servers assign client identifiers based on domain names, for example,
	skipping to change at page 69, line 37 ¶		skipping to change at page 71, line 13 ¶
	redirect to help avoid this problem.		redirect to help avoid this problem.
	Following the requirements of Section 3.2 of [RFC3986], as there is		Following the requirements of Section 3.2 of [RFC3986], as there is
	no naming authority for private-use URI scheme redirects, only a		no naming authority for private-use URI scheme redirects, only a
	single slash ("/") appears after the scheme component. A complete		single slash ("/") appears after the scheme component. A complete
	example of a redirect URI utilizing a private-use URI scheme is:		example of a redirect URI utilizing a private-use URI scheme is:
	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 redirection URI as it would normally. As the		the client's redirect URI as it would normally. As the redirect URI
	redirection URI uses a private-use URI scheme, it results in the		uses a private-use URI scheme, it results in the operating system
	operating system launching the native app, passing in the URI as a		launching the native app, passing in the URI as a launch parameter.
	launch parameter. Then, the native app uses normal processing for		Then, the native app uses normal processing for the authorization
	the authorization response.		response.
	10.3.2. Claimed "https" Scheme URI Redirection		10.3.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-
	skipping to change at page 71, line 32 ¶		skipping to change at page 73, line 6 ¶
	([RFC6750]).		([RFC6750]).
	Where a later draft updates or obsoletes functionality found in the		Where a later draft updates or obsoletes functionality found in the
	original [RFC6749], that functionality in this draft is updated with		original [RFC6749], that functionality in this draft is updated with
	the normative changes described in a later draft, or removed		the normative changes described in a later draft, or removed
	entirely.		entirely.
	A non-normative list of changes from OAuth 2.0 is listed below:		A non-normative list of changes from OAuth 2.0 is listed below:
	* The authorization code grant is extended with the functionality		* The authorization code grant is extended with the functionality
	from PKCE ([RFC7636]) such that the only method of using the		from PKCE ([RFC7636]) such that the default method of using the
	authorization code grant according to this specification requires		authorization code grant according to this specification requires
	the addition of the PKCE mechanism		the addition of the PKCE parameters
	* Redirect URIs must be compared using exact string matching as per		* Redirect URIs must be compared using exact string matching as per
	Section 4.1.3 of [I-D.ietf-oauth-security-topics]		Section 4.1.3 of [I-D.ietf-oauth-security-topics]
	* The Implicit grant ("response_type=token") is omitted from this		* The Implicit grant ("response_type=token") is omitted from this
	specification as per Section 2.1.2 of		specification as per Section 2.1.2 of
	[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 must either be sender-constrained or one-time use		* Refresh tokens should either be sender-constrained or one-time use
	as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]		as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
	13. IANA Considerations		13. IANA Considerations
	13.1. OAuth Access Token Types Registry		This document does not require any IANA actions.
	This specification establishes the OAuth Access Token Types registry.
	Access token types are registered with a Specification Required
	([RFC8126]) after a two-week review period on the oauth-ext-
	review@ietf.org mailing list, on the advice of one or more Designated
	Experts. However, to allow for the allocation of values prior to
	publication, the Designated Expert(s) may approve registration once
	they are satisfied that such a specification will be published.
	Registration requests must be sent to the oauth-ext-review@ietf.org
	mailing list for review and comment, with an appropriate subject
	(e.g., "Request for access token type: example").
	Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request
	successful.
	IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing
	list.
	13.1.1. Registration Template
	Type name: The name requested (e.g., "example").
	Additional Token Endpoint Response Parameters: Additional response
	parameters returned together with the "access_token" parameter.
	New parameters MUST be separately registered in the OAuth
	Parameters registry as described by Section 13.2.
	HTTP Authentication Scheme(s): The HTTP authentication scheme
	name(s), if any, used to authenticate protected resource requests
	using access tokens of this type.
	Change controller: For Standards Track RFCs, state "IETF". For
	others, give the name of the responsible party. Other details
	(e.g., postal address, email address, home page URI) may also be
	included.
	Specification document(s): Reference to the document(s) that specify
	the parameter, preferably including a URI that can be used to
	retrieve a copy of the document(s). An indication of the relevant
	sections may also be included but is not required.
	13.1.2. Initial Registry Contents
	The OAuth Access Token Types registry's initial contents are:
	* Type name: Bearer
	* Additional Token Endpoint Response Parameters: (none)
	* HTTP Authentication Scheme(s): Bearer
	* Change controller: IETF
	* Specification document(s): OAuth 2.1
	13.2. OAuth Parameters Registry
	This specification establishes the OAuth Parameters registry.
	Additional parameters for inclusion in the authorization endpoint
	request, the authorization endpoint response, the token endpoint
	request, or the token endpoint response are registered with a
	Specification Required ([RFC8126]) after a two-week review period on
	the oauth-ext-review@ietf.org mailing list, on the advice of one or
	more Designated Experts. However, to allow for the allocation of
	values prior to publication, the Designated Expert(s) may approve
	registration once they are satisfied that such a specification will
	be published.
	Registration requests must be sent to the oauth-ext-review@ietf.org
	mailing list for review and comment, with an appropriate subject
	(e.g., "Request for parameter: example").
	Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request
	successful.
	IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing
	list.
	13.2.1. Registration Template
	Parameter name: The name requested (e.g., "example").
	Parameter usage location: The location(s) where parameter can be
	used. The possible locations are authorization request,
	authorization response, token request, or token response.
	Change controller: For Standards Track RFCs, state "IETF". For
	others, give the name of the responsible party. Other details
	(e.g., postal address, email address, home page URI) may also be
	included.
	Specification document(s): Reference to the document(s) that specify
	the parameter, preferably including a URI that can be used to
	retrieve a copy of the document(s). An indication of the relevant
	sections may also be included but is not required.
	13.2.2. Initial Registry Contents
	The OAuth Parameters registry's initial contents are:
	* Parameter name: client_id
	* Parameter usage location: authorization request, token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: client_secret
	* Parameter usage location: token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: response_type
	* Parameter usage location: authorization request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: redirect_uri
	* Parameter usage location: authorization request, token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: scope
	* Parameter usage location: authorization request, authorization
	response, token request, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: state
	* Parameter usage location: authorization request, authorization
	response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: code
	* Parameter usage location: authorization response, token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: error_description
	* Parameter usage location: authorization response, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: error_uri
	* Parameter usage location: authorization response, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: grant_type
	* Parameter usage location: token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: access_token
	* Parameter usage location: authorization response, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: token_type
	* Parameter usage location: authorization response, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: expires_in
	* Parameter usage location: authorization response, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: username
	* Parameter usage location: token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: password
	* Parameter usage location: token request
	* Change controller: IETF
	* Specification document(s): RFC 6749
	* Parameter name: refresh_token
	* Parameter usage location: token request, token response
	* Change controller: IETF
	* Specification document(s): RFC 6749
	13.3. OAuth Authorization Endpoint Response Types Registry
	This specification establishes the OAuth Authorization Endpoint
	Response Types registry.
	Additional response types for use with the authorization endpoint are
	registered with a Specification Required ([RFC8126]) after a two-week
	review period on the oauth-ext-review@ietf.org mailing list, on the
	advice of one or more Designated Experts. However, to allow for the
	allocation of values prior to publication, the Designated Expert(s)
	may approve registration once they are satisfied that such a
	specification will be published.
	Registration requests must be sent to the oauth-ext-review@ietf.org
	mailing list for review and comment, with an appropriate subject
	(e.g., "Request for response type: example").
	Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request
	successful.
	IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing
	list.
	13.3.1. Registration Template
	Response type name: The name requested (e.g., "example").
	Change controller: For Standards Track RFCs, state "IETF". For
	others, give the name of the responsible party. Other details
	(e.g., postal address, email address, home page URI) may also be
	included.
	Specification document(s): Reference to the document(s) that specify
	the type, preferably including a URI that can be used to retrieve
	a copy of the document(s). An indication of the relevant sections
	may also be included but is not required.
	13.3.2. Initial Registry Contents
	The OAuth Authorization Endpoint Response Types registry's initial
	contents are:
	* Response type name: code
	* Change controller: IETF
	* Specification document(s): RFC 6749
	13.4. OAuth Extensions Error Registry
	This specification establishes the OAuth Extensions Error registry.
	Additional error codes used together with other protocol extensions
	(i.e., extension grant types, access token types, or extension
	parameters) are registered with a Specification Required ([RFC8126])
	after a two-week review period on the oauth-ext-review@ietf.org
	mailing list, on the advice of one or more Designated Experts.
	However, to allow for the allocation of values prior to publication,
	the Designated Expert(s) may approve registration once they are
	satisfied that such a specification will be published.
	Registration requests must be sent to the oauth-ext-review@ietf.org
	mailing list for review and comment, with an appropriate subject
	(e.g., "Request for error code: example").
	Within the review period, the Designated Expert(s) will either
	approve or deny the registration request, communicating this decision
	to the review list and IANA. Denials should include an explanation
	and, if applicable, suggestions as to how to make the request
	successful.
	IANA must only accept registry updates from the Designated Expert(s)
	and should direct all requests for registration to the review mailing
	list.
	13.4.1. Registration Template
	Error name: The name requested (e.g., "example"). Values for the
	error name MUST NOT include characters outside the set %x20-21 /
	%x23-5B / %x5D-7E.
	Error usage location: The location(s) where the error can be used.
	The possible locations are authorization code grant error response
	(Section 4.1.2.1), token error response (Section 5.2), or resource
	access error response (Section 7.3).
	Related protocol extension: The name of the extension grant type,
	access token type, or extension parameter that the error code is
	used in conjunction with.
	Change controller: For Standards Track RFCs, state "IETF". For
	others, give the name of the responsible party. Other details
	(e.g., postal address, email address, home page URI) may also be
	included.
	Specification document(s): Reference to the document(s) that specify
	the error code, preferably including a URI that can be used to
	retrieve a copy of the document(s). An indication of the relevant
	sections may also be included but is not required.
	13.4.2. Initial Registry Contents
	The OAuth Error registry's initial contents are:
	* Error name: invalid_request
	* Error usage location: Resource access error response
	* Change controller: IETF
	* Specification document(s): OAuth 2.1
	* Error name: invalid_token
	* Error usage location: Resource access error response
	* Change controller: IETF
	* Specification document(s): OAuth 2.1
	* Error name: insufficient_scope
	* Error usage location: Resource access error response
	* Change controller: IETF
	* Specification document(s): OAuth 2.1		All referenced registries are defined by RFC6749 and related
			documents that this work is based upon. No changes to those
			registries are required by this specification.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-oauth-security-topics]		[I-D.ietf-oauth-security-topics]
	Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,		Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
	"OAuth 2.0 Security Best Current Practice", Work in		"OAuth 2.0 Security Best Current Practice", Work in
	Progress, Internet-Draft, draft-ietf-oauth-security-		Progress, Internet-Draft, draft-ietf-oauth-security-
	topics-15, 5 April 2020, <http://www.ietf.org/internet-		topics-15, 5 April 2020, <http://www.ietf.org/internet-
	skipping to change at page 81, line 40 ¶		skipping to change at page 75, line 29 ¶
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines		[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
	and Registration Procedures for URI Schemes", BCP 35,		and Registration Procedures for URI Schemes", BCP 35,
	RFC 7595, DOI 10.17487/RFC7595, June 2015,		RFC 7595, DOI 10.17487/RFC7595, June 2015,
	<https://www.rfc-editor.org/info/rfc7595>.		<https://www.rfc-editor.org/info/rfc7595>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	skipping to change at page 82, line 39 ¶		skipping to change at page 76, 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, T., and H. Zandbelt, "Encoding		Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
	claims in the OAuth 2 state parameter using a JWT", Work		claims in the OAuth 2 state parameter using a JWT", Work
	in Progress, Internet-Draft, draft-bradley-oauth-jwt-		in Progress, Internet-Draft, draft-bradley-oauth-jwt-
	encoded-state-09, 4 November 2018, <http://www.ietf.org/		encoded-state-09, 4 November 2018, <http://www.ietf.org/
	internet-drafts/draft-bradley-oauth-jwt-encoded-state-		internet-drafts/draft-bradley-oauth-jwt-encoded-state-
	09.txt>.		09.txt>.
			[I-D.ietf-oauth-access-token-jwt]
			Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
			Access Tokens", Work in Progress, Internet-Draft, draft-
			ietf-oauth-access-token-jwt-07, 27 April 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-oauth-
			access-token-jwt-07.txt>.
	[I-D.ietf-oauth-browser-based-apps]		[I-D.ietf-oauth-browser-based-apps]
	Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based		Parecki, A. and D. Waite, "OAuth 2.0 for Browser-Based
	Apps", Work in Progress, Internet-Draft, draft-ietf-oauth-		Apps", Work in Progress, Internet-Draft, draft-ietf-oauth-
	browser-based-apps-06, 5 April 2020, <http://www.ietf.org/		browser-based-apps-06, 5 April 2020, <http://www.ietf.org/
	internet-drafts/draft-ietf-oauth-browser-based-apps-		internet-drafts/draft-ietf-oauth-browser-based-apps-
	06.txt>.		06.txt>.
			[I-D.ietf-oauth-dpop]
			Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
			Jones, M., and D. Waite, "OAuth 2.0 Demonstration of
			Proof-of-Possession at the Application Layer (DPoP)", Work
			in Progress, Internet-Draft, draft-ietf-oauth-dpop-01, 1
			May 2020, <http://www.ietf.org/internet-drafts/draft-ietf-
			oauth-dpop-01.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-01,
			18 February 2020, <http://www.ietf.org/internet-drafts/
			draft-ietf-oauth-par-01.txt>.
	[I-D.ietf-oauth-rar]		[I-D.ietf-oauth-rar]
	Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0		Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
	Rich Authorization Requests", Work in Progress, Internet-		Rich Authorization Requests", Work in Progress, Internet-
	Draft, draft-ietf-oauth-rar-01, 19 February 2020,		Draft, draft-ietf-oauth-rar-01, 19 February 2020,
	<http://www.ietf.org/internet-drafts/draft-ietf-oauth-rar-		<http://www.ietf.org/internet-drafts/draft-ietf-oauth-rar-
	01.txt>.		01.txt>.
	[I-D.ietf-oauth-token-binding]		[I-D.ietf-oauth-token-binding]
	Jones, M., Campbell, B., Bradley, J., and W. Denniss,		Jones, M., Campbell, B., Bradley, J., and W. Denniss,
	"OAuth 2.0 Token Binding", Work in Progress, Internet-		"OAuth 2.0 Token Binding", Work in Progress, Internet-
	skipping to change at page 84, line 5 ¶		skipping to change at page 78, line 10 ¶
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0		[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
	Threat Model and Security Considerations", RFC 6819,		Threat Model and Security Considerations", RFC 6819,
	DOI 10.17487/RFC6819, January 2013,		DOI 10.17487/RFC6819, January 2013,
	<https://www.rfc-editor.org/info/rfc6819>.		<https://www.rfc-editor.org/info/rfc6819>.
			[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
			2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
			August 2013, <https://www.rfc-editor.org/info/rfc7009>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Authentication", RFC 7235,		Protocol (HTTP/1.1): Authentication", RFC 7235,
	DOI 10.17487/RFC7235, June 2014,		DOI 10.17487/RFC7235, June 2014,
	<https://www.rfc-editor.org/info/rfc7235>.		<https://www.rfc-editor.org/info/rfc7235>.
	[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0		(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
	Client Authentication and Authorization Grants", RFC 7522,		<https://www.rfc-editor.org/info/rfc7519>.
	DOI 10.17487/RFC7522, May 2015,
	<https://www.rfc-editor.org/info/rfc7522>.
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,		RFC 7591, DOI 10.17487/RFC7591, July 2015,
	<https://www.rfc-editor.org/info/rfc7591>.		<https://www.rfc-editor.org/info/rfc7591>.
			[RFC7592] Richer, J., Ed., Jones, M., Bradley, J., and M. Machulak,
			"OAuth 2.0 Dynamic Client Registration Management
			Protocol", RFC 7592, DOI 10.17487/RFC7592, July 2015,
			<https://www.rfc-editor.org/info/rfc7592>.
	[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key		[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
	for Code Exchange by OAuth Public Clients", RFC 7636,		for Code Exchange by OAuth Public Clients", RFC 7636,
	DOI 10.17487/RFC7636, September 2015,		DOI 10.17487/RFC7636, September 2015,
	<https://www.rfc-editor.org/info/rfc7636>.		<https://www.rfc-editor.org/info/rfc7636>.
			[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
			RFC 7662, DOI 10.17487/RFC7662, October 2015,
			<https://www.rfc-editor.org/info/rfc7662>.
	[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0		[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
	Authorization Server Metadata", RFC 8414,		Authorization Server Metadata", RFC 8414,
	DOI 10.17487/RFC8414, June 2018,		DOI 10.17487/RFC8414, June 2018,
	<https://www.rfc-editor.org/info/rfc8414>.		<https://www.rfc-editor.org/info/rfc8414>.
			[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
			"OAuth 2.0 Device Authorization Grant", RFC 8628,
			DOI 10.17487/RFC8628, August 2019,
			<https://www.rfc-editor.org/info/rfc8628>.
	[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>.
	skipping to change at page 88, line 43 ¶		skipping to change at page 83, line 17 ¶
	(4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO		(4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO
	SIGN) would be encoded into the octet sequence below (using		SIGN) would be encoded into the octet sequence below (using
	hexadecimal notation):		hexadecimal notation):
	20 25 26 2B C2 A3 E2 82 AC		20 25 26 2B C2 A3 E2 82 AC
	and then represented in the payload as:		and then represented in the payload as:
	+%25%26%2B%C2%A3%E2%82%AC		+%25%26%2B%C2%A3%E2%82%AC
	Appendix C. Acknowledgements		Appendix C. Extensions
			Below is a list of well-established extensions at the time of
			publication:
			* [RFC8628]: OAuth 2.0 Device Authorization Grant
			- The Device Authorization Grant (formerly known as the Device
			Flow) is an extension that enables devices with no browser or
			limited input capability to obtain an access token. This is
			commonly used by smart TV apps, or devices like hardware video
			encoders that can stream video to a streaming video service.
			* [RFC8414]: Authorization Server Metadata
			- Authorization Server Metadata (also known as OAuth Discovery)
			defines an endpoint clients can use to look up the information
			needed to interact with a particular OAuth server, such as the
			location of the authorization and token endpoints and the
			supported grant types.
			* [RFC8707]: Resource Indicators
			- Provides a way for the client to explicitly signal to the
			authorization server where it intends to use the access token
			it is requesting.
			* [RFC7591]: Dynamic Client Registration
			- Dynamic Client Registration provides a mechanism for
			programmatically registering clients with an authorization
			server.
			* [RFC7592]: Dynamic Client Management
			- Dynamic Client Management provides a mechanism for updating
			dynamically registered client information.
			* [I-D.ietf-oauth-access-token-jwt]: JSON Web Token (JWT) Profile
			for OAuth 2.0 Access Tokens
			- This specification defines a profile for issuing OAuth access
			tokens in JSON web token (JWT) format.
			* [RFC8705]: Mutual TLS
			- Mutual TLS describes a mechanism of binding access tokens and
			refresh tokens to the clients they were issued to, as well as a
			client authentication mechanism, via TLS certificate
			authentication.
			* [RFC7662]: Token Introspection
			- The Token Introspection extension defines a mechanism for
			resource servers to obtain information about access tokens.
			* [RFC7009]: Token Revocation
			- The Token Revocation extension defines a mechanism for clients
			to indicate to the authorization server that an access token is
			no longer needed.
			* [I-D.ietf-oauth-par]: Pushed Authorization Requests
			- The Pushed Authorization Requsts extension describes a
			technique of initiating an OAuth flow from the back channel,
			providing better security and more flexibility for building
			complex authorization requests.
			* [I-D.ietf-oauth-rar]: Rich Authorization Requests
			- Rich Authorization Requests specifies a new parameter
			"authorization_details" that is used to carry fine-grained
			authorization data in the OAuth authorization request.
			Appendix D. Acknowledgements
	TBD		TBD
	Authors' Addresses		Authors' Addresses
	Dick Hardt		Dick Hardt
	SignIn.Org		SignIn.Org
	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. 165 change blocks.
	784 lines changed or deleted		583 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/