< draft-ietf-oauth-v2-12.txt		draft-ietf-oauth-v2-13.txt >
	Network Working Group E. Hammer-Lahav, Ed.		Network Working Group E. Hammer-Lahav, Ed.
	Internet-Draft Yahoo!		Internet-Draft Yahoo!
	Obsoletes: 5849 (if approved) D. Recordon		Obsoletes: 5849 (if approved) D. Recordon
	Intended status: Standards Track Facebook		Intended status: Standards Track Facebook
	Expires: July 25, 2011 D. Hardt		Expires: August 20, 2011 D. Hardt
	Microsoft		Microsoft
	January 21, 2011		February 16, 2011
	The OAuth 2.0 Authorization Protocol		The OAuth 2.0 Authorization Protocol
	draft-ietf-oauth-v2-12		draft-ietf-oauth-v2-13
	Abstract		Abstract
	This specification describes the OAuth 2.0 authorization protocol.		This specification describes the OAuth 2.0 authorization protocol.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 July 25, 2011.		This Internet-Draft will expire on August 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Authorization Grant . . . . . . . . . . . . . . . . . . . 6		1.3. Access Token . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 7		1.4. Authorization Grant . . . . . . . . . . . . . . . . . . . 6
	1.5. Notational Conventions . . . . . . . . . . . . . . . . . . 9		1.5. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 8
	2. Client Authentication . . . . . . . . . . . . . . . . . . . . 9		1.6. Document Structure . . . . . . . . . . . . . . . . . . . . 10
	2.1. Client Password Authentication . . . . . . . . . . . . . . 9		1.7. Notational Conventions . . . . . . . . . . . . . . . . . . 10
	2.2. Other Client Authentication Methods . . . . . . . . . . . 10		2. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 10
	3. Protocol Endpoints . . . . . . . . . . . . . . . . . . . . . . 11		2.1. Authorization Endpoint . . . . . . . . . . . . . . . . . . 11
	3.1. Authorization Endpoint . . . . . . . . . . . . . . . . . . 11		2.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Token Endpoint . . . . . . . . . . . . . . . . . . . . . . 12		3. Client Authentication . . . . . . . . . . . . . . . . . . . . 13
	4. Requesting an Access Token . . . . . . . . . . . . . . . . . . 13		3.1. Client Password Authentication . . . . . . . . . . . . . . 13
	4.1. Authorization Code . . . . . . . . . . . . . . . . . . . . 13		3.2. Other Client Authentication Methods . . . . . . . . . . . 13
	4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . . 19		4. Obtaining Authorization . . . . . . . . . . . . . . . . . . . 14
	4.3. Resource Owner Password Credentials . . . . . . . . . . . 24		4.1. Authorization Code . . . . . . . . . . . . . . . . . . . . 14
	4.4. Client Credentials . . . . . . . . . . . . . . . . . . . . 26		4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . . . 20
	4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28		4.3. Resource Owner Password Credentials . . . . . . . . . . . 25
	5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 28		4.4. Client Credentials . . . . . . . . . . . . . . . . . . . . 28
	5.1. Successful Response . . . . . . . . . . . . . . . . . . . 28		4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 30
	5.2. Error Response . . . . . . . . . . . . . . . . . . . . . . 30		5. Issuing an Access Token . . . . . . . . . . . . . . . . . . . 30
	6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 31		5.1. Successful Response . . . . . . . . . . . . . . . . . . . 31
	7. Accessing Protected Resources . . . . . . . . . . . . . . . . 32		5.2. Error Response . . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Access Token Types . . . . . . . . . . . . . . . . . . . . 33		6. Refreshing an Access Token . . . . . . . . . . . . . . . . . . 33
	8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33		7. Accessing Protected Resources . . . . . . . . . . . . . . . . 34
	8.1. Defining Access Token Types . . . . . . . . . . . . . . . 33		7.1. Access Token Types . . . . . . . . . . . . . . . . . . . . 35
	8.2. Defining New Endpoint Parameters . . . . . . . . . . . . . 34		8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 36
	8.3. Defining New Authorization Grant Types . . . . . . . . . . 34		8.1. Defining Access Token Types . . . . . . . . . . . . . . . 36
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 34		8.2. Defining New Endpoint Parameters . . . . . . . . . . . . . 36
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		8.3. Defining New Authorization Grant Types . . . . . . . . . . 36
	10.1. The OAuth Access Token Type Registry . . . . . . . . . . . 35		9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	10.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 36		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 39		10.1. The OAuth Access Token Type Registry . . . . . . . . . . . 37
	Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 39		10.2. The OAuth Parameters Registry . . . . . . . . . . . . . . 38
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 41
	Appendix D. Document History . . . . . . . . . . . . . . . . . . 39		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 41
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43		Appendix C. Document History . . . . . . . . . . . . . . . . . . 41
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 43		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	11.2. Informative References . . . . . . . . . . . . . . . . . . 45		11.1. Normative References . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45		11.2. Informative References . . . . . . . . . . . . . . . . . . 42
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	In the traditional client-server authentication model, the client		In the traditional client-server authentication model, the client
	accesses a protected resource on the server by authenticating with		accesses a protected resource on the server by authenticating with
	the server using the resource owner's credentials. In order to		the server using the resource owner's credentials. In order to
	provide third-party applications access to protected resources, the		provide third-party applications access to protected resources, the
	resource owner shares its credentials with the third-party. This		resource owner shares its credentials with the third-party. This
	creates several problems and limitations:		creates several problems and limitations:
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	authorization server		authorization server
	The server issuing access tokens to the client after successfully		The server issuing access tokens to the client after successfully
	authenticating the resource owner and obtaining authorization.		authenticating the resource owner and obtaining authorization.
	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. 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
	When interacting with the authorization server, the client identifies		When interacting with the authorization server, the client identifies
	itself using a set of client credentials which include a client		itself using a set of client credentials which include a client
	identifier and other authentication attributes. The means through		identifier and other authentication attributes. The means through
	which the client obtains its credentials are beyond the scope of this		which the client obtains its credentials are beyond the scope of this
	specification, but typically involve registration with the		specification, but typically involve registration with the
	authorization server.		authorization server.
	+--------+ +---------------+		+--------+ +---------------+
	| |--(A)- Authorization Request ->| Resource |		| |--(A)- Authorization Request ->| Resource |
	| | | Owner |		| | | Owner |
	skipping to change at page 5, line 28 ¶		skipping to change at page 5, line 47 ¶
	authorization server using its client credentials (prearranged		authorization server using its client credentials (prearranged
	between the client and authorization server) and presenting the		between the client and authorization server) and presenting the
	authorization grant.		authorization grant.
	(D) The authorization server validates the client credentials and		(D) The authorization server validates the client credentials and
	the authorization grant, and if valid issues an access token.		the authorization grant, and if valid issues an access token.
	(E) The client requests the protected resource from the resource		(E) The client requests the protected resource from the resource
	server and authenticates by presenting the access token.		server and authenticates by presenting the access token.
	(F) The resource server validates the access token, and if valid,		(F) The resource server validates the access token, and if valid,
	serves the request.		serves the request.
	1.2. Access Token		1.3. Access Token
	An access token is a string representing an authorization issued to		An access token is a string representing an authorization issued to
	the client. The string is usually opaque to the client. Tokens		the client. The string is usually opaque to the client. Tokens
	represent specific scopes and durations of access, granted by the		represent specific scopes and durations of access, granted by the
	resource owner, and enforced by the resource server and authorization		resource owner, and enforced by the resource server and authorization
	server.		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 self-contain the authorization information in a		information, or 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). Tokens may be pure capabilities. Additional		signature). Additional authentication credentials may be required in
	authentication credentials may be required in order for the client to		order for the client to use a token.
	use a token.
	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
	server security requirements. Access token attributes and the		server security requirements. Access token attributes and the
	methods used to access protected resources are beyond the scope of		methods used to access protected resources are beyond the scope of
	this specification and are defined by companion specifications.		this specification and are defined by companion specifications.
	1.3. Authorization Grant		1.4. Authorization Grant
	An authorization grant is a general term used to describe the		An authorization grant is a general term used to describe the
	intermediate credentials representing the resource owner		intermediate credentials representing the resource owner
	authorization, and serves as an abstraction layer. An authorization		authorization, and serves as an abstraction layer. An authorization
	grant is used by the client to obtain an access token.		grant is used by the client to obtain an access token.
	1.3.1. Authorization Code		1.4.1. Authorization Code
	The authorization code is obtained by using an authorization server		The authorization code is obtained by using an authorization server
	as an intermediary between the client and resource owner. Instead of		as an intermediary between the client and resource owner. Instead of
	requesting authorization directly from the resource owner, the client		requesting authorization directly from the resource owner, the client
	directs the resource owner to an authorization server (via its user-		directs the resource owner to an authorization server (via its user-
	agent), which in turns directs the resource owner back to the client		agent), which in turns directs the resource owner back to the client
	with the authorization code.		with the authorization code.
	Before directing the resource owner back to the client with the		Before directing the resource owner back to the client with the
	authorization code, the authorization server authenticates the		authorization code, the authorization server authenticates the
	resource owner and obtains authorization. Because the resource owner		resource owner and obtains authorization. Because the resource owner
	only authenticates with the authorization server, the resource		only authenticates with the authorization server, the resource
	owner's credentials are never shared with the client.		owner's credentials are never shared with the client.
	The authorization code provides a few important security benefits		The authorization code provides a few important security benefits
	such as the ability to authenticate the client and issuing the access		such as the ability to authenticate the client and issuing the access
	token directly to the client without potentially exposing it to		token directly to the client without potentially exposing it to
	others, including the resource owner.		others, including the resource owner.
	1.3.2. Implicit		1.4.2. Implicit
	An implicit grant is issued when the resource owner's authorization		An implicit grant is issued when the resource owner's authorization
	is expressed directly as an access token, without using an		is expressed directly as an access token, without using an
	intermediate credential. The implicit grant is issued in a similar		intermediate credential. The implicit grant is issued in a similar
	manner as an authorization code, but instead of the resource owner		manner as an authorization code, but instead of the resource owner
	being redirected back to the client with the authorization code, it		being redirected back to the client with the authorization code, it
	is redirected back with an access token and its related attributes.		is redirected back with an access token and its related attributes.
	When issuing an implicit grant, the authorization server cannot		When issuing an implicit grant, the authorization server cannot
	verify the identity of the client, and the access token may be		verify the identity of the client, and the access token may be
	exposed to the resource owner or other applications with access to		exposed to the resource owner or other applications with access to
	the resource owner's user-agent.		the resource owner's user-agent.
	Implicit grants improve the responsiveness and efficiency of some		Implicit grants improve the responsiveness and efficiency of some
	clients (such as a client implemented as an in-browser application)		clients (such as a client implemented as an in-browser application)
	since it reduces the number of round trip required to obtain an		since it reduces the number of round trips required to obtain an
	access token.		access token.
	1.3.3. Resource Owner Password Credentials		1.4.3. Resource Owner Password Credentials
	The resource owner password credentials (e.g. a username and		The resource owner password credentials (e.g. a username and
	password) can be used directly as an authorization grant to obtain an		password) can be used directly as an authorization grant to obtain an
	access token. The credentials should only be used when there is a		access token. The credentials should only be used when there is a
	high degree of trust between the resource owner and the client (e.g.		high degree of trust between the resource owner and the client (e.g.
	its computer operating system or a highly privileged application),		its computer operating system or a highly privileged application),
	and when other authorization grant types are not available (such as		and when other authorization grant types are not available (such as
	an authorization code).		an authorization code).
	Even though this grant type requires direct client access to the		Even though this grant type requires direct client access to the
	resource owner credentials, the resource owner credentials are used		resource owner credentials, the resource owner credentials are used
	for a single request and are exchanged for an access token. Unlike		for a single request and are exchanged for an access token. Unlike
	the HTTP Basic authentication scheme defined in [RFC2617], this grant		the HTTP Basic authentication scheme defined in [RFC2617], this grant
	type eliminates the need for the client to store the resource-owner		type eliminates the need for the client to store the resource-owner
	credentials for future use.		credentials for future use.
	1.3.4. Client Credentials		1.4.4. Client Credentials
	The client credentials can be used as an authorization grant when the		The client credentials can be used as an authorization grant when the
	authorization scope is limited to the protected resources under the		authorization scope is limited to the protected resources under the
	control of the client, or to protected resources previously arranged		control of the client, or to protected resources previously arranged
	with the authorization server. Client credentials are used as an		with the authorization server. Client credentials are used as an
	authorization grant typically when the client is acting on its own		authorization grant typically when the client is acting on its own
	behalf (the client is also the resource owner).		behalf (the client is also the resource owner).
	1.3.5. Extensions		1.4.5. Extensions
	Additional grant types may be defined to provide a bridge between		Additional grant types may be defined to provide a bridge between
	OAuth and other trust frameworks. For example,		OAuth and other trust frameworks. For example,
	[I-D.ietf-oauth-saml2-bearer] defines a SAML 2.0		[I-D.ietf-oauth-saml2-bearer] defines a SAML 2.0
	[OASIS.saml-core-2.0-os] bearer assertion grant type, which can be		[OASIS.saml-core-2.0-os] bearer assertion grant type, which can be
	used to obtain an access token.		used to obtain an access token.
	1.4. Refresh Token		1.5. Refresh Token
	A refresh token is optionally issued by the authorization server to		A refresh token is optionally issued by the authorization server to
	the client together with an access token. The client can use the		the client together with an access token. The client can use the
	refresh token to request another access token based on the same		refresh token to request another access token based on the same
	authorization, without having to involve the resource owner again, or		authorization, without having to involve the resource owner again, or
	having to retain the original authorization grant used to obtain the		having to retain the original authorization grant used to obtain the
	initial access token.		initial access token.
	A refresh token is a string representing the authorization granted to		A refresh token is a string representing the authorization granted to
	the client by the resource owner. The string is usually opaque to		the client by the resource owner. The string is usually opaque to
	the client. The token may denote an identifier used to retrieve the		the client. The token may denote an identifier used to retrieve the
	authorization information, or self-contain the authorization		authorization information, or self-contain the authorization
	information in a verifiable manner.		information in a verifiable manner.
	The refresh token can be used to obtain a new access token when the		The refresh token can be used to obtain a new access token when the
	current access token expires (access tokens may have a shorter		current access token expires (access tokens may have a shorter
	lifetime than authorized by the resource owner), or to obtain		lifetime than authorized by the resource owner), or to obtain
	additional access tokens with identical or narrower scope.		additional access tokens with identical or narrower scope.
	+--------+ Access Grant & +---------------+		+--------+ Authorization Grant & +---------------+
	| |--(A)-------- Client Credentials --------->| |		| |--(A)-------- Client Credentials --------->| |
	| | | |		| | | |
	| |<-(B)----------- Access Token -------------| |		| |<-(B)----------- Access Token -------------| |
	| | & Refresh Token | |		| | & Refresh Token | |
	| | | |		| | | |
	| | +----------+ | |		| | +----------+ | |
	| |--(C)---- Access Token ---->| | | |		| |--(C)---- Access Token ---->| | | |
	| | | | | |		| | | | | |
	| |<-(D)- Protected Resource --| Resource | | Authorization |		| |<-(D)- Protected Resource --| Resource | | Authorization |
	| Client | | Server | | Server |		| Client | | Server | | Server |
	skipping to change at page 9, line 15 ¶		skipping to change at page 10, line 4 ¶
	(D) The resource server validates the access token, and if valid,		(D) The resource server validates the access token, and if valid,
	serves the request.		serves the request.
	(E) Steps (C) and (D) repeat until the access token expires. If the		(E) Steps (C) and (D) repeat until the access token expires. If the
	client knows the access token expired, it skips to step (G),		client knows the access token expired, it skips to step (G),
	otherwise it makes another protected resource request.		otherwise it makes another protected resource request.
	(F) Since the access token is invalid (expired), the resource server		(F) Since the access token is invalid (expired), the resource server
	returns an invalid token error.		returns an invalid token error.
	(G) The client requests a new access token by authenticating with		(G) The client requests a new access token by authenticating with
	the authorization server using its client credentials, and		the authorization server using its client credentials, and
	presenting the refresh token.		presenting the refresh token.
	(H) The authorization server validates the client credentials and		(H) The authorization server validates the client credentials and
	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.5. Notational Conventions		1.6. Document Structure
			This specification is organized into the following sections:
			o Section 2 - describes the two endpoints used to obtain and utilize
			the various authorization grant types.
			o Section 3 - describes client identification and authentication in
			general, and provides one such method for client authentication
			using password credentials.
			o Section 4 - describes the complete flow for each authorization
			grant type, including requesting authorization, authorization
			response, and requesting an access token.
			o Section 5 - describes the common access token response used for
			all non-implicit authorization grant types.
			o Section 6 - describes the use of a refresh token to obtain
			additional access tokens using the same resource owner
			authorization.
			o Section 7 - describes how access tokens are used to access
			protected resources.
			o Section 8 - describes how to extend certain elements of the
			protocol.
			o Section 9 - provides a security analysis of the protocol.
			1.7. 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', 'MAY', and 'OPTIONAL' in this		'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
	specification are to be interpreted as described in [RFC2119].		specification are to be interpreted as described in [RFC2119].
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [I-D.ietf-httpbis-p1-messaging]. Additionally, the		notation of [RFC5234].
	following rules are included from [RFC3986]: URI-reference; and from
	[I-D.ietf-httpbis-p1-messaging]: OWS, RWS, and quoted-string.
	Unless otherwise noted, all the protocol parameter names and values		Unless otherwise noted, all the protocol parameter names and values
	are case sensitive.		are case sensitive.
	2. Client Authentication		2. Protocol Endpoints
	Client credentials are used to identify and authenticate the client.
	The client credentials include a client identified - a unique string
	issued to the client to identify itself to the authorization server.
	The methods through which the client obtains its client credentials
	are beyond the scope of this specification.
	Due to the nature of some clients, the authorization server SHOULD
	NOT make assumptions about the confidentiality of client credentials
	without establishing trust with the client. The authorization server
	SHOULD NOT issue client credentials to clients incapable of keeping
	their secrets confidential.
	2.1. Client Password Authentication
	The client password authentication uses a shared symmetric secret to
	authenticate the client. The client identifier and password are
	included in the request using the following parameters:
	client_id
	REQUIRED. The client identifier.
	client_secret
	REQUIRED. The client password.
	For example (line breaks are for display purposes only):
	POST /token HTTP/1.1
	Host: server.example.com
	Content-Type: application/x-www-form-urlencoded
	grant_type=authorization_code&client_id=s6BhdRkqt3&
	client_secret=gX1fBat3bV&code=i1WsRn1uB1&
	redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	2.2. Other Client Authentication Methods
	In cases where client password authentication is not suitable or
	sufficient, the authorization server MAY support other existing HTTP
	authentication schemes or define new methods. In addition, the
	authorization server MAY allow unauthenticated access token requests
	when the client identity does not matter (e.g. anonymous client) or
	when the client identity is established via other means.
	For example, the authorization server MAY support using the HTTP
	Basic authentication scheme as defined in [RFC2617] to include the
	client identifier as the username and client password as the password
	(line breaks are for display purposes only):
	POST /token HTTP/1.1
	Host: server.example.com
	Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
	Content-Type: application/x-www-form-urlencoded
	grant_type=authorization_code&code=i1WsRn1uB1&
	redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	When using a method other than client password authentication to
	exchange an authorization code grant type, the authorization server
	MUST define a method for mapping the client credentials to the client
	identifier used to obtain the authorization code.
	3. Protocol Endpoints
	The authorization process utilizes two endpoints:		The authorization process utilizes two endpoints:
	o Authorization endpoint - used to obtain authorization from the		o Authorization endpoint - used to obtain authorization from the
	resource owner via user-agent redirection.		resource owner via user-agent redirection.
	o Token endpoint - used to exchange an authorization grant for an		o Token endpoint - used to exchange an authorization grant for an
	access token, typically with client authentication.		access token, typically with client authentication.
	Not every authorization grant flow utilizes both endpoints.		Not every authorization grant type utilizes both endpoints.
	Extension grant types MAY define additional endpoints as needed.		Extension grant types MAY define additional endpoints as needed.
	3.1. Authorization Endpoint		2.1. Authorization Endpoint
	The authorization endpoint is used to interact with the resource		The authorization endpoint is used to interact with the resource
	owner and obtain authorization which is expressed explicitly as an		owner and obtain authorization which is expressed explicitly as an
	authorization code (exchanged for an access token), or implicitly by		authorization code (exchanged for an access token), or implicitly by
	direct issuance of an access token.		direct issuance of an access token.
	The authorization server MUST first verify the identity of the		The authorization server MUST first verify the identity of the
	resource owner. The way in which the authorization server		resource owner. The way in which the authorization server
	authenticates the resource owner (e.g. username and password login,		authenticates the resource owner (e.g. username and password login,
	session cookies) is beyond the scope of this specification.		session cookies) is beyond the scope of this specification.
	skipping to change at page 12, line 5 ¶		skipping to change at page 11, line 45 ¶
	its security requirements.		its security requirements.
	The authorization server MUST support the use of the HTTP "GET"		The authorization server MUST support the use of the HTTP "GET"
	method for the authorization endpoint, and MAY support the use of the		method for the authorization endpoint, and MAY support the use of the
	"POST" method as well.		"POST" method as well.
	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 SHOULD ignore		omitted from the request. The authorization server SHOULD ignore
	unrecognized request parameters.		unrecognized request parameters.
	3.1.1. Redirection URI		2.1.1. Redirection URI
	The client directs the resource owner's user-agent to the		The client directs the resource owner's user-agent to the
	authorization endpoint and includes a redirection URI to which the		authorization endpoint and includes a redirection URI to which the
	authorization server will redirect the user-agent back once		authorization server will redirect the user-agent back once
	authorization has been obtained (or denied). The client MAY omit the		authorization has been obtained (or denied). The client MAY omit the
	redirection URI if one has been established between the client and		redirection URI if one has been established between the client and
	authorization server via other means, such as during the client		authorization server via other means, such as during the client
	registration process.		registration process.
	The redirection URI MUST be an absolute URI and MAY include a query		The redirection URI MUST be an absolute URI and MAY include a query
	skipping to change at page 12, line 31 ¶		skipping to change at page 12, line 22 ¶
	scheme, host, port and path. If a redirection URI was registered,		scheme, host, port and path. If a redirection URI was registered,
	the authorization server MUST compare any redirection URI received at		the authorization server MUST compare any redirection URI received at
	the authorization endpoint with the registered URI.		the authorization endpoint with the registered URI.
	The authorization server SHOULD NOT redirect the user-agent to		The authorization server SHOULD NOT redirect the user-agent to
	unregistered or untrusted URIs to prevent the endpoint from being		unregistered or untrusted URIs to prevent the endpoint from being
	used as an open redirector. If no valid redirection URI is		used as an open redirector. If no valid redirection URI is
	available, the authorization server SHOULD inform the resource owner		available, the authorization server SHOULD inform the resource owner
	directly of the error.		directly of the error.
	3.2. Token Endpoint		2.2. Token Endpoint
	The token endpoint is used by the client to obtain an access token by		The token endpoint is used by the client to obtain an access token by
	authenticating with the authorization server and presenting its		authenticating with the authorization server and presenting its
	authorization grant. The token endpoint is used with every		authorization grant. The token endpoint is used with every
	authorization grant except for the implicit grant type (since an		authorization grant except for the implicit grant type (since an
	access token is issued directly).		access token is issued directly).
	The location of the token endpoint can be found in the service		The location of the token endpoint can be found in the service
	documentation. The endpoint URI MAY include a query component, which		documentation. The endpoint URI MAY include a query component, which
	MUST be retained when adding additional query parameters.		MUST be retained when adding additional query parameters.
	Since requests to the token endpoint result in the transmission of		Since requests to the token endpoint result in the transmission of
	clear-text credentials (in the HTTP request and response), the		clear-text credentials (in the HTTP request and response), the
	authorization server MUST require the use of a transport-layer		authorization server MUST require the use of a transport-layer
	security mechanism when sending requests to the token endpoints. The		security mechanism when sending requests to the token endpoints. The
	authorization server MUST support TLS 1.2 as defined in [RFC5246],		authorization server MUST support TLS 1.2 as defined in [RFC5246],
	and MAY support additional transport-layer mechanisms meeting its		and MAY support additional transport-layer mechanisms meeting its
	security requirements.		security requirements.
	The token endpoint requires client authentication as described in		The token endpoint requires client authentication as described in
	Section 2 . The authorization server MAY accept any form of client		Section 3. The authorization server MAY accept any form of client
	authentication meeting its security requirements. The client MUST		authentication meeting its security requirements. The client MUST
	NOT use more than one authentication method in each request.		NOT use more than one authentication method in each request.
	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 SHOULD ignore		omitted from the request. The authorization server SHOULD ignore
	unrecognized request parameters.		unrecognized request parameters.
	4. Requesting an Access Token		3. Client Authentication
	The client obtains an access token by requesting authorization from		Client credentials are used to identify and authenticate the client.
	the resource owner. The authorization is expressed in the form of an		The client credentials include a client identifier - a unique string
	authorization grant which the client exchanges for an access token.		issued to the client to identify itself to the authorization server.
	OAuth defines four grant types: authorization code, implicit,		The methods through which the client obtains its client credentials
	resource owner password credentials, and client credentials, as well		are beyond the scope of this specification.
	as an extension mechanism for defining additional grant types.
			Due to the nature of some clients, the authorization server should
			not make assumptions about the confidentiality of client credentials
			without establishing trust with the client. The authorization server
			SHOULD NOT issue client credentials to clients incapable of keeping
			their secrets confidential.
			3.1. Client Password Authentication
			The client password authentication uses a shared symmetric secret to
			authenticate the client. The client identifier and password are
			included in the request using the following parameters:
			client_id
			REQUIRED. The client identifier.
			client_secret
			REQUIRED. The client password.
			For example (line breaks are for display purposes only):
			POST /token HTTP/1.1
			Host: server.example.com
			Content-Type: application/x-www-form-urlencoded
			grant_type=authorization_code&client_id=s6BhdRkqt3&
			client_secret=gX1fBat3bV&code=i1WsRn1uB1&
			redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
			3.2. Other Client Authentication Methods
			In cases where client password authentication is not suitable or
			sufficient, the authorization server MAY support other existing HTTP
			authentication schemes or define new methods. In addition, the
			authorization server MAY allow unauthenticated access token requests
			when the client identity does not matter (e.g. anonymous client) or
			when the client identity is established via other means.
			For example, the authorization server MAY support using the HTTP
			Basic authentication scheme as defined in [RFC2617] to include the
			client identifier as the username and client password as the password
			(line breaks are for display purposes only):
			POST /token HTTP/1.1
			Host: server.example.com
			Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
			Content-Type: application/x-www-form-urlencoded
			grant_type=authorization_code&code=i1WsRn1uB1&
			redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
			When using a method other than client password authentication to
			exchange an authorization code grant type, the authorization server
			MUST define a method for mapping the client credentials to the client
			identifier used to obtain the authorization code.
			4. Obtaining Authorization
			To request an access token, the client obtains authorization from the
			resource owner. The authorization is expressed in the form of an
			authorization grant which the client uses to requesting the access
			token. OAuth defines four grant types: authorization code, implicit,
			resource owner password credentials, and client credentials. It also
			provides an extension mechanism for defining additional grant types.
	4.1. Authorization Code		4.1. Authorization Code
	The authorization code flow is suitable for clients capable of		The authorization code grant type is suitable for clients capable of
	maintaining their client credentials confidential (for authenticating		maintaining their client credentials confidential (for authenticating
	with the authorization server) such as a client implemented on a		with the authorization server) such as a client implemented on a
	secure server. As a redirection-based profile, the client must be		secure server. As a redirection-based flow, the client must be
	capable of interacting with the resource owner's user-agent		capable of interacting with the resource owner's user-agent
	(typically a web browser) and capable of receiving incoming requests		(typically a web browser) and capable of receiving incoming requests
	(via redirection) from the authorization server.		(via redirection) from the authorization server.
	+----------+		+----------+
	| resource |		| resource |
	| owner |		| owner |
	| |		| |
	+----------+		+----------+
	^		^
	skipping to change at page 15, line 23 ¶		skipping to change at page 16, line 23 ¶
	4.1.1. Authorization Request		4.1.1. 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 as defined by		using the "application/x-www-form-urlencoded" format as defined by
	[W3C.REC-html401-19991224]:		[W3C.REC-html401-19991224]:
	response_type		response_type
	REQUIRED. Value MUST be set to "code".		REQUIRED. Value MUST be set to "code".
	client_id		client_id
	REQUIRED. The client identifier as described in Section 2.		REQUIRED. The client identifier as described in Section 3.
	redirect_uri		redirect_uri
	REQUIRED, unless a redirection URI has been established between		REQUIRED, unless a redirection URI has been established between
	the client and authorization server via other means. Described		the client and authorization server via other means. Described
	in Section 3.1.1.		in Section 2.1.1.
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope.		adds an additional access range to the requested scope.
	state		state
	OPTIONAL. An opaque value used by the client to maintain state		OPTIONAL. An opaque value used by the client to maintain state
	between the request and callback. The authorization server		between the request and callback. The authorization server
	includes this value when redirecting the user-agent back to the		includes this value when redirecting the user-agent back to the
	skipping to change at page 16, line 47 ¶		skipping to change at page 17, line 47 ¶
	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=i1WsRn1uB1		Location: https://client.example.com/cb?code=i1WsRn1uB1
	The client SHOULD ignore unrecognized response parameters. The		The client SHOULD ignore unrecognized response parameters. The
	authorization code string size is left undefined by this		authorization code string size is left undefined by this
	specification. The clients should avoid making assumptions about		specification. The clients should avoid making assumptions about
	code value sizes. The authorization server should document the size		code value sizes. The authorization server should document the size
	of any value is issues.		of any value it issues.
	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, the authorization server SHOULD inform the resource		redirection URI, or if the client identifier provided is invalid, the
	owner of the error, and MUST NOT redirect the user-agent to the		authorization server SHOULD inform the resource owner of the error,
	invalid redirection URI.		and MUST NOT redirect the user-agent to the invalid redirection URI.
	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 redirection URI,
	the authorization server informs the client by adding the following		the 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 redirection URI using the
	"application/x-www-form-urlencoded" format:		"application/x-www-form-urlencoded" format:
	error		error
	REQUIRED. A single error code from the following:		REQUIRED. A single error code from the following:
	invalid_request		invalid_request
	The request is missing a required parameter, includes an		The request is missing a required parameter, includes an
	unsupported parameter or parameter value, or is otherwise		unsupported parameter or parameter value, or is otherwise
	malformed.		malformed.
	invalid_client
	The client identifier provided is invalid.
	unauthorized_client		unauthorized_client
	The client is not authorized to request an authorization		The client is not authorized to request an authorization
	code using this method.		code using this method.
	access_denied		access_denied
	The resource owner or authorization server denied the		The resource owner or authorization server denied the
	request.		request.
	unsupported_response_type		unsupported_response_type
	The authorization server does not support obtaining an		The authorization server does not support obtaining an
	authorization code using this method.		authorization code using this method.
	invalid_scope		invalid_scope
	skipping to change at page 18, line 23 ¶		skipping to change at page 19, line 18 ¶
	The client makes a request to the token endpoint by adding the		The client makes a request to the token endpoint by adding the
	following parameter using the "application/x-www-form-urlencoded"		following parameter using the "application/x-www-form-urlencoded"
	format in the HTTP request entity-body:		format in the HTTP request entity-body:
	grant_type		grant_type
	REQUIRED. Value MUST be set to "authorization_code".		REQUIRED. Value MUST be set to "authorization_code".
	code		code
	REQUIRED. The authorization code received from the		REQUIRED. The authorization code received from the
	authorization server.		authorization server.
	redirect_uri		redirect_uri
	REQUIRED. The redirection URI used in the initial request.		REQUIRED. The redirection URI used by the authorization server
			to return the authorization response in the previous step.
	The client includes its authentication credentials as described in		The client includes its authentication credentials as described in
	Section 2		Section 3
	For example, the client makes the following HTTP request by including		For example, the client makes the following HTTP request by including
	its client credentials via the "client_id" and "client_secret"		its client credentials via the "client_id" and "client_secret"
	parameters, and using transport-layer security (line breaks are for		parameters, and using transport-layer security (line breaks are for
	display purposes only):		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=authorization_code&client_id=s6BhdRkqt3&		grant_type=authorization_code&client_id=s6BhdRkqt3&
	client_secret=gX1fBat3bV&code=i1WsRn1uB1&		client_secret=gX1fBat3bV&code=i1WsRn1uB1&
	redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb		redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
	The authorization server MUST:		The authorization server MUST:
	o Validate the client credentials and ensure they match the		o Validate the client credentials and ensure they match the
	authorization code.		authorization code.
	o Verify that the authorization code and redirection URI are valid		o Verify that the authorization code is valid, and that the
	and match its stored association.		redirection URI matches the redirection URI used by the
			authorization server to deliver the authorization code.
	If the request is valid and authorized, the authorization server		4.1.4. Access Token Response
	issues an access token and optional refresh token, and responds as
	described in Section 5.		If the access token request is valid and authorized, the
			authorization server issues an access token and optional refresh
			token as described in Section 5.1. If the request failed client
			authentication or is invalid, the authorization server return an
			error response as described in Section 5.2.
			An example successful response:
			HTTP/1.1 200 OK
			Content-Type: application/json
			Cache-Control: no-store
			{
			"access_token":"SlAV32hkKG",
			"token_type":"example",
			"expires_in":3600,
			"refresh_token":"8xLOxBtZp8",
			"example_parameter":"example-value"
			}
	4.2. Implicit Grant		4.2. Implicit Grant
	The implicit grant flow is suitable for clients incapable of		The implicit grant type is suitable for clients incapable of
	maintaining their client credentials confidential (for authenticating		maintaining their client credentials confidential (for authenticating
	with the authorization server) such as client applications residing		with the authorization server) such as client applications residing
	in a user-agent, typically implemented in a browser using a scripting		in a user-agent, typically implemented in a browser using a scripting
	language such as JavaScript, or native applications. These clients		language such as JavaScript, or native applications. These clients
	cannot keep client secrets confidential and the authentication of the		cannot keep client secrets confidential and the authentication of the
	client is based on the user-agent's same-origin policy.		client is based on the user-agent's same-origin policy.
	As a redirection-based profile, the client must be capable of		As a redirection-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.
	Unlike the authorization code flow in which the client makes separate		Unlike the authorization code grant type in which the client makes
	requests for authorization and access token, the client receives the		separate requests for authorization and access token, the client
	access token as the result of the authorization request.		receives the access token as the result of the authorization request.
	The implicit grant flow does not utilize the client credentials since		Using the implicit grant type does not include client authentication
	the client is unable to maintain their confidentiality (the client		since the client is unable to maintain their credential
	resides on the resource owner's computer or device which makes the		confidentiality (the client resides on the resource owner's computer
	client credentials accessible and exploitable). Because the access		or device which makes the client credentials accessible and
	token is encoded into the redirection URI, it may be exposed to the		exploitable). Because the access token is encoded into the
	resource owner and other applications residing on its computer or		redirection URI, it may be exposed to the resource owner and other
	device.		applications residing on its computer or device.
	+----------+		+----------+
	| Resource |		| Resource |
	| Owner |		| Owner |
	| |		| |
	+----------+		+----------+
	^		^
	|		|
	(B)		(B)
	+----|-----+ Client Identifier +---------------+		+----|-----+ Client Identifier +---------------+
	skipping to change at page 21, line 30 ¶		skipping to change at page 22, line 30 ¶
	4.2.1. Authorization Request		4.2.1. 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:		using the "application/x-www-form-urlencoded" format:
	response_type		response_type
	REQUIRED. Value MUST be set to "token".		REQUIRED. Value MUST be set to "token".
	client_id		client_id
	REQUIRED. The client identifier as described in Section 2.		REQUIRED. The client identifier as described in Section 3.
	Due to lack of client authentication, the client identifier		Due to lack of client authentication, the client identifier
	alone MUST NOT be relied upon for client identification.		alone MUST NOT be relied upon for client identification.
	redirect_uri		redirect_uri
	REQUIRED, unless a redirection URI has been established between		REQUIRED, unless a redirection URI has been established between
	the client and authorization server via other means. Described		the client and authorization server via other means. Described
	in Section 3.1.1.		in Section 2.1.1.
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope.		adds an additional access range to the requested scope.
	state		state
	OPTIONAL. An opaque value used by the client to maintain state		OPTIONAL. An opaque value used by the client to maintain state
	between the request and callback. The authorization server		between the request and callback. The authorization server
	includes this value when redirecting the user-agent back to the		includes this value when redirecting the user-agent back to the
	skipping to change at page 23, line 26 ¶		skipping to change at page 24, line 26 ¶
	token_type=example&expires_in=3600		token_type=example&expires_in=3600
	The client SHOULD ignore unrecognized response parameters. The		The client SHOULD ignore unrecognized response parameters. The
	access token string size is left undefined by this specification.		access token string size is left undefined by this specification.
	The client should avoid making assumptions about value sizes. The		The client should avoid making assumptions about value sizes. The
	authorization server should document the size of any value it issues.		authorization server should document the size of any value it issues.
	4.2.2.1. Error Response		4.2.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, the authorization server SHOULD inform the resource		redirection URI, or if the client identifier provided is invalid, the
	owner of the error, and MUST NOT redirect the user-agent to the		authorization server SHOULD inform the resource owner of the error,
	invalid redirection URI.		and MUST NOT redirect the user-agent to the invalid redirection URI.
	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 redirection URI,
	the authorization server informs the client by adding the following		the authorization server informs the client by adding the following
	parameters to the fragment component of the redirection URI using the		parameters to the fragment component of the redirection URI using the
	"application/x-www-form-urlencoded" format:		"application/x-www-form-urlencoded" format:
	error		error
	REQUIRED. A single error code from the following:		REQUIRED. A single error code from the following:
	invalid_request		invalid_request
	The request is missing a required parameter, includes an		The request is missing a required parameter, includes an
	unsupported parameter or parameter value, or is otherwise		unsupported parameter or parameter value, or is otherwise
	malformed.		malformed.
	invalid_client
	The client identifier provided is invalid.
	unauthorized_client		unauthorized_client
	The client is not authorized to request an access token		The client is not authorized to request an access token
	using this method.		using this method.
	access_denied		access_denied
	The resource owner or authorization server denied the		The resource owner or authorization server denied the
	request.		request.
	unsupported_response_type		unsupported_response_type
	The authorization server does not support obtaining an		The authorization server does not support obtaining an
	access token using this method.		access token using this method.
	invalid_scope		invalid_scope
	The requested scope is invalid, unknown, or malformed.		The requested scope is invalid, unknown, or malformed.
	error_description		error_description
	OPTIONAL. A human-readable text providing additional		OPTIONAL. A human-readable text providing additional
	information, used to assist in the understanding and resolution		information, used to assist in the understanding and resolution
	of the error occurred.		of the error occurred.
	error_uri		error_uri
	skipping to change at page 24, line 34 ¶		skipping to change at page 25, line 31 ¶
	the client.		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#error=access_denied		Location: https://client.example.com/cb#error=access_denied
	4.3. Resource Owner Password Credentials		4.3. Resource Owner Password Credentials
	The resource owner password credentials flow is suitable in cases		The resource owner password credentials grant type is suitable in
	where the resource owner has a trust relationship with the client,		cases where the resource owner has a trust relationship with the
	such as its computer operating system or a highly privileged		client, such as its computer operating system or a highly privileged
	application. The authorization server should take special care when		application. The authorization server should take special care when
	enabling the flow, and only when other flows are not viable.		enabling the grant type, and only when other flows are not viable.
	The flow is suitable for clients capable of obtaining the resource		The grant type is suitable for clients capable of obtaining the
	owner credentials (username and password, typically using an		resource owner credentials (username and password, typically using an
	interactive form). It is also used to migrate existing clients using		interactive form). It is also used to migrate existing clients using
	direct authentication schemes such as HTTP Basic or Digest		direct authentication schemes such as HTTP Basic or Digest
	authentication to OAuth by converting the stored credentials with an		authentication to OAuth by converting the stored credentials with an
	access token.		access token.
	The method through which the client obtains the resource owner
	credentials is beyond the scope of this specification. The client
	MUST discard the credentials once an access token has been obtained.
	+----------+		+----------+
	| Resource |		| Resource |
	| Owner |		| Owner |
	| |		| |
	+----------+		+----------+
	v		v
	|		|
	(A) Password Credentials		(A) Password Credentials
	|		|
	v		v
	skipping to change at page 25, line 38 ¶		skipping to change at page 26, line 38 ¶
	(A) The resource owner provides the client with its username and		(A) The resource owner provides the client with its username and
	password.		password.
	(B) The client requests an access token from the authorization		(B) The client requests an access token from the authorization
	server's token endpoint by authenticating using its client		server's token endpoint by authenticating using its client
	credentials, and includes the credentials received from the		credentials, and includes the credentials received from the
	resource owner.		resource owner.
	(C) The authorization server validates the resource owner		(C) The authorization server validates the resource owner
	credentials and the client credentials and issues an access		credentials and the client credentials and issues an access
	token.		token.
	4.3.1. Access Token Request		4.3.1. Authorization Request and Response
			The method through which the client obtains the resource owner
			credentials is beyond the scope of this specification. The client
			MUST discard the credentials once an access token has been obtained.
			4.3.2. Access Token Request
	The client makes a request to the token endpoint by adding the		The client makes a request to the token endpoint by adding the
	following parameter using the "application/x-www-form-urlencoded"		following parameter using the "application/x-www-form-urlencoded"
	format in the HTTP request entity-body:		format in the HTTP request entity-body:
	grant_type		grant_type
	REQUIRED. Value MUST be set to "password".		REQUIRED. Value MUST be set to "password".
	username		username
	REQUIRED. The resource owner username.		REQUIRED. The resource owner username.
	password		password
	REQUIRED. The resource owner password.		REQUIRED. The resource owner password.
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope.		adds an additional access range to the requested scope.
	The client includes its authentication credentials as described in		The client includes its authentication credentials as described in
	Section 2		Section 3
	[[ add internationalization consideration for username and password		[[ add internationalization consideration for username and password
	]]		]]
	For example, the client makes the following HTTP request by including		For example, the client makes the following HTTP request by including
	its client credentials via the "client_id" and "client_secret"		its client credentials via the "client_id" and "client_secret"
	parameters, and using transport-layer security (line breaks are for		parameters, and using transport-layer security (line breaks are for
	display purposes only):		display purposes only):
	POST /token HTTP/1.1		POST /token HTTP/1.1
	skipping to change at page 26, line 37 ¶		skipping to change at page 27, line 41 ¶
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	grant_type=password&client_id=s6BhdRkqt3&		grant_type=password&client_id=s6BhdRkqt3&
	client_secret=47HDu8s&username=johndoe&password=A3ddj3w		client_secret=47HDu8s&username=johndoe&password=A3ddj3w
	The authorization server MUST:		The authorization server MUST:
	o Validate the client credentials.		o Validate the client credentials.
	o Validate the resource owner password credentials.		o Validate the resource owner password credentials.
	If the request is valid and authorized, the authorization server		4.3.3. Access Token Response
	issues an access token and optional refresh token, and responds as
	described in Section 5.		If the access token request is valid and authorized, the
			authorization server issues an access token and optional refresh
			token as described in Section 5.1. If the request failed client
			authentication or is invalid, the authorization server return an
			error response as described in Section 5.2.
			An example successful response:
			HTTP/1.1 200 OK
			Content-Type: application/json
			Cache-Control: no-store
			{
			"access_token":"SlAV32hkKG",
			"token_type":"example",
			"expires_in":3600,
			"refresh_token":"8xLOxBtZp8",
			"example_parameter":"example-value"
			}
	4.4. Client Credentials		4.4. Client Credentials
	The client can request an access token using only its client		The client can request an access token using only its client
	credentials when the client is requesting access to the protected		credentials when the client is requesting access to the protected
	resources under its control, or those of another resource owner which		resources under its control, or those of another resource owner which
	has been previously arranged with the authorization server (the		has been previously arranged with the authorization server (the
	method of which is beyond the scope of this specification).		method of which is beyond the scope of this specification).
	+---------+ +---------------+		+---------+ +---------------+
	skipping to change at page 27, line 22 ¶		skipping to change at page 28, line 44 ¶
	Figure 6: Client Credentials Flow		Figure 6: Client Credentials Flow
	The flow illustrated in Figure 6 includes the following steps:		The flow illustrated in Figure 6 includes the following steps:
	(A) The client requests an access token from the token endpoint by		(A) The client requests an access token from the token endpoint by
	authenticating using its client credentials.		authenticating using its client credentials.
	(B) The authorization server validates the client credentials and		(B) The authorization server validates the client credentials and
	issues an access token.		issues an access token.
	4.4.1. Access Token Request		4.4.1. Authorization Request and Response
			Since the client credentials are used as the authorization grant, no
			additional authorization request is needed as the client is already
			in the possession of its client credentials.
			4.4.2. Access Token Request
	The client makes a request to the token endpoint by adding the		The client makes a request to the token endpoint by adding the
	following parameter using the "application/x-www-form-urlencoded"		following parameter using the "application/x-www-form-urlencoded"
	format in the HTTP request entity-body:		format in the HTTP request entity-body:
	grant_type		grant_type
	REQUIRED. Value MUST be set to "client_credentials".		REQUIRED. Value MUST be set to "client_credentials".
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope.		adds an additional access range to the requested scope.
	The client includes its authentication credentials as described in		The client includes its authentication credentials as described in
	Section 2		Section 3
	For example, the client makes the following HTTP request by including		For example, the client makes the following HTTP request by including
	its client credentials via the "client_id" and "client_secret"		its client credentials via the "client_id" and "client_secret"
	parameters, and using transport-layer security (line breaks are for		parameters, and using transport-layer security (line breaks are for
	display purposes only):		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=client_credentials&client_id=s6BhdRkqt3&		grant_type=client_credentials&client_id=s6BhdRkqt3&
	client_secret=47HDu8s		client_secret=47HDu8s
	The authorization server MUST validate the client credentials.		The authorization server MUST validate the client credentials.
	If the request is valid and authorized, the authorization server		4.4.3. Access Token Response
	issues an access token and optional refresh token, and responds as
	described in Section 5.		If the access token request is valid and authorized, the
			authorization server issues an access token and optional refresh
			token as described in Section 5.1. If the request failed client
			authentication or is invalid, the authorization server return an
			error response as described in Section 5.2.
			An example successful response:
			HTTP/1.1 200 OK
			Content-Type: application/json
			Cache-Control: no-store
			{
			"access_token":"SlAV32hkKG",
			"token_type":"example",
			"expires_in":3600,
			"refresh_token":"8xLOxBtZp8",
			"example_parameter":"example-value"
			}
	4.5. Extensions		4.5. Extensions
	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 SAML 2.0 assertion		For example, to request an access token using a SAML 2.0 assertion
	grant type, the client makes the following HTTP request using		grant type as defined by [I-D.ietf-oauth-saml2-bearer], the client
	transport-layer security (line breaks are for display purposes only):		makes the following HTTP request using transport-layer security (line
			breaks are 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=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F		grant_type=http%3A%2F%2Foauth.net%2Fgrant_type%2Fassertion%2F
	saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ		saml%2F2.0%2Fbearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ
	[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-		[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
	Client authentication and the scope of the grant are obtained via the
	assertion as defined by [I-D.ietf-oauth-saml2-bearer].
	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
	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 return an		authentication or is invalid, the authorization server return an
	error response as described in Section 5.2.		error response as described in Section 5.2.
	5.1. Successful Response		5.1. Successful Response
	skipping to change at page 29, line 29 ¶		skipping to change at page 31, line 35 ¶
	scope		scope
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope. The		adds an additional access range to the requested scope. The
	authorization server SHOULD include the parameter if the		authorization server SHOULD include the parameter if the
	requested scope is different from the one requested by the		requested scope is different from the one requested by the
	client.		client.
	The parameters are including in the entity body of the HTTP response		The parameters are included in the entity body of the HTTP response
	using the "application/json" media type as defined by [RFC4627]. The		using the "application/json" media type as defined by [RFC4627]. The
	parameters are serialized into a JSON structure by adding each		parameters are serialized into a JSON structure by adding each
	parameter at the highest structure level. Parameter names and string		parameter at the highest structure level. Parameter names and string
	values are included as JSON strings. Numerical values are included		values are included as JSON strings. Numerical values are included
	as JSON numbers.		as JSON numbers.
	The authorization server MUST include the HTTP "Cache-Control"		The authorization server MUST include the HTTP "Cache-Control"
	response header field with a value of "no-store" in any response		response header field with a value of "no-store" in any response
	containing tokens, secrets, or other sensitive information.		containing tokens, secrets, or other sensitive information.
	skipping to change at page 30, line 4 ¶		skipping to change at page 32, line 17 ¶
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-store		Cache-Control: no-store
	{		{
	"access_token":"SlAV32hkKG",		"access_token":"SlAV32hkKG",
	"token_type":"example",		"token_type":"example",
	"expires_in":3600,		"expires_in":3600,
	"refresh_token":"8xLOxBtZp8",		"refresh_token":"8xLOxBtZp8",
	"example_parameter":"example-value"		"example_parameter":"example-value"
	}		}
	The client SHOULD ignore unrecognized response parameters. The sizes		The client SHOULD ignore unrecognized response parameters. The sizes
	of tokens and other values received from the authorization server are		of tokens and other values received from the authorization server are
	left undefined. The client should avoid making assumptions about		left undefined. The client should avoid making assumptions about
	value sizes. The authorization server should document the size of		value sizes. The authorization server should document the size of
	any value it issues.		any value it issues.
	5.2. Error Response		5.2. Error Response
	If the client provided invalid credentials using an HTTP		The authorization server responds with an HTTP 400 (Bad Request)
	authentication scheme via the "Authorization" request header field,		status code and includes the following parameters with the response:
	the authorization server MUST respond with a HTTP 401 (Unauthorized)
	status code, and include the "WWW-Authenticate" response header field
	matching the authentication scheme used by the client. Otherwise,
	the authorization server MUST respond with the HTTP 400 (Bad Request)
	status code.
	The authorization server constructs the response by adding the
	following parameter to the response:
	error		error
	REQUIRED. A single error code from the following:		REQUIRED. A single error code from the following:
	invalid_request		invalid_request
	The request is missing a required parameter, includes an		The request is missing a required parameter, includes an
	unsupported parameter or parameter value, repeats a		unsupported parameter or parameter value, repeats a
	parameter, includes multiple credentials, utilizes more		parameter, includes multiple credentials, utilizes more
	than one mechanism for authenticating the client, or is		than one mechanism for authenticating the client, or is
	otherwise malformed.		otherwise malformed.
	invalid_client		invalid_client
	Client authentication failed (e.g. unknown client, no		Client authentication failed (e.g. unknown client, no
	client credentials included, multiple client credentials		client credentials included, multiple client credentials
	included, or unsupported credentials type).		included, or unsupported credentials type). The
			authorization server MAY return an HTTP 401
			(Unauthorized) status code to indicate which HTTP
			authentication schemes are supported. If the client
			attempted to authenticate via the "Authorization" request
			header field, the authorization server MUST respond with
			an HTTP 401 (Unauthorized) status code, and include the
			"WWW-Authenticate" response header field matching the
			authentication scheme used by the client.
	invalid_grant		invalid_grant
	The provided authorization grant is invalid, expired,		The provided authorization grant is invalid, expired,
	revoked, or does not match the redirection URI used in		revoked, or does not match the redirection URI used in
	the authorization request.		the authorization request.
	unauthorized_client		unauthorized_client
	The authenticated client is not authorized to use this		The authenticated client is not authorized to use this
	authorization grant type.		authorization grant type.
	unsupported_grant_type		unsupported_grant_type
	The authorization grant type is not supported by the		The authorization grant type is not supported by the
	authorization server.		authorization server.
	skipping to change at page 31, line 4 ¶		skipping to change at page 33, line 15 ¶
	invalid_grant		invalid_grant
	The provided authorization grant is invalid, expired,		The provided authorization grant is invalid, expired,
	revoked, or does not match the redirection URI used in		revoked, or does not match the redirection URI used in
	the authorization request.		the authorization request.
	unauthorized_client		unauthorized_client
	The authenticated client is not authorized to use this		The authenticated client is not authorized to use this
	authorization grant type.		authorization grant type.
	unsupported_grant_type		unsupported_grant_type
	The authorization grant type is not supported by the		The authorization grant type is not supported by the
	authorization server.		authorization server.
	invalid_scope		invalid_scope
	The requested scope is invalid, unknown, malformed, or		The requested scope is invalid, unknown, malformed, or
	exceeds the previously granted scope.		exceeds the previously granted scope.
	error_description		error_description
	OPTIONAL. A human-readable text providing additional		OPTIONAL. A human-readable text providing additional
	information, used to assist in the understanding and resolution		information, used to assist in the understanding and resolution
	of the error occurred.		of the error occurred.
	error_uri		error_uri
	OPTIONAL. A URI identifying a human-readable web page with		OPTIONAL. A URI identifying a human-readable web page with
	information about the error, used to provide the resource owner		information about the error, used to provide the resource owner
	with additional information about the error.		with additional information about the error.
	The parameters are including in the entity body of the HTTP response		The parameters are included in the entity body of the HTTP response
	using the "application/json" media type as defined by [RFC4627]. The		using the "application/json" media type as defined by [RFC4627]. The
	parameters are serialized into a JSON structure by adding each		parameters are serialized into a JSON structure by adding each
	parameter at the highest structure level. Parameter names and string		parameter at the highest structure level. Parameter names and string
	values are included as JSON strings. Numerical values are included		values are included as JSON strings. Numerical values are included
	as JSON numbers.		as JSON numbers.
	For example:		For example:
	HTTP/1.1 400 Bad Request		HTTP/1.1 400 Bad Request
	Content-Type: application/json		Content-Type: application/json
	skipping to change at page 32, line 10 ¶		skipping to change at page 34, line 21 ¶
	OPTIONAL. The scope of the access request expressed as a list		OPTIONAL. The scope of the access request expressed as a list
	of space-delimited strings. The value is defined by the		of space-delimited strings. The value is defined by the
	authorization server. If the value contains multiple space-		authorization server. If the value contains multiple space-
	delimited strings, their order does not matter, and each string		delimited strings, their order does not matter, and each string
	adds an additional access range to the requested scope. The		adds an additional access range to the requested scope. The
	requested scope MUST be equal or lesser than the scope		requested scope MUST be equal or lesser than the scope
	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 previously approved scope.		treated as equal to the previously approved scope.
	The client includes its authentication credentials as described in		The client includes its authentication credentials as described in
	Section 2		Section 3
	For example, the client makes the following HTTP request by including		For example, the client makes the following HTTP request by including
	its client credentials via the "client_id" and "client_secret"		its client credentials via the "client_id" and "client_secret"
	parameters, and using transport-layer security (line breaks are for		parameters, and using transport-layer security (line breaks are for
	display purposes only):		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=refresh_token&client_id=s6BhdRkqt3&		grant_type=refresh_token&client_id=s6BhdRkqt3&
	client_secret=8eSEIpnqmM&refresh_token=n4E9O119d		client_secret=8eSEIpnqmM&refresh_token=n4E9O119d
	The authorization server MUST validate the client credentials, the		The authorization server MUST validate the client credentials, the
	refresh token, and verify that the resource owner's authorization is		refresh token, and verify that the resource owner's authorization is
	still valid. If valid, the authorization server issues an access		still valid. If valid and authorized, the authorization server
	token response as described in Section 5.		issues an access token as described in Section 5.1. If the request
			failed verification or is invalid, the authorization server return an
			error response as described in Section 5.2.
	The authorization server MAY issue a new refresh token, in which		The authorization server MAY issue a new refresh token, in which
	case, the client MUST discard the old refresh token and replace it		case, the client MUST discard the old refresh token and replace it
	with the new refresh token.		with the new refresh token.
	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 it has not expired and that its scope covers		access token and ensure it has not expired and that its scope covers
	skipping to change at page 33, line 41 ¶		skipping to change at page 36, line 11 ¶
	(if any) sent to the client together with the "access_token" response		(if any) sent to the client together with the "access_token" response
	parameter. It also defines the HTTP authentication method used to		parameter. It also defines the HTTP authentication method used to
	include the access token when making a protected resource request.		include the access token when making a protected resource request.
	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 type registry (following the procedures in		the access token type registry (following the procedures in
	Section 10.1), or use the "x_" type name prefix.		Section 10.1), or use a unique absolute URI as its name.
	Types utilizing the "x_" name prefix MUST be limited to vendor-		Types utilizing a URI name SHOULD be limited to vendor-specific
	specific implementations that are not commonly applicable, and are		implementations that are not commonly applicable, and are specific to
	specific to the implementation details of the resource server where		the implementation details of the resource server where they are
	they are used. If a vendor-specific type requires additional vendor-		used.
	specific token response parameters, they MUST also use the "x_" name
	prefix.
	All other types MUST be registered, and MUST NOT use the "x_" type		All other types MUST be registered. Type names MUST conform to the
	name prefix. Type names MUST conform to the type-name ABNF. If the		type-name ABNF. If the type definition includes a new HTTP
	type definition includes a new HTTP authentication scheme, the type		authentication scheme, the type name SHOULD be identical to the HTTP
	name SHOULD be identical to the authentication scheme name (as		authentication scheme name (as defined by [RFC2617]).
	defined by [RFC2617]).
	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 can be added in one of two ways:		endpoint or the token endpoint are defined and registered in the
	registered in the parameters registry (following the procedures in		parameters registry following the procedure in Section 10.2.
	Section 10.2), or use the "x_" parameter name prefix.
	Parameters utilizing the "x_" parameter name prefix MUST be limited
	to vendor-specific extensions that are not commonly applicable, and
	are specific to the implementation details of the authorization
	server where they are used. All other new parameters MUST be
	registered, and MUST NOT use the "x_" parameter name prefix.
	Parameter names MUST conform to the param-name ABNF, and parameter		Parameter names MUST conform to the param-name ABNF, MUST NOT use the
	values syntax MUST be well-defined (e.g., using ABNF, or a reference		"x_" parameter name prefix, and parameter values syntax MUST be well-
	to the syntax of an existing parameter).		defined (e.g., using ABNF, or a reference 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
			Vendor-specific parameter extensions that are not commonly
			applicable, and are specific to the implementation details of the
			authorization server where they are used SHOULD utilize the "x_"
			parameter name prefix if they are not registered.
	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 URI for use with the "grant_type" parameter. If the extension		unique absolute URI for use with the "grant_type" parameter. If the
	grant type requires additional token endpoint parameters, they MUST		extension grant type requires additional token endpoint parameters,
	be registered in the OAuth parameters registry as described by		they MUST be registered in the OAuth parameters registry as described
	Section 10.2.		by Section 10.2.
	9. Security Considerations		9. Security Considerations
	[[ TBD ]]		[[ TBD ]]
	10. IANA Considerations		10. IANA Considerations
	10.1. The OAuth Access Token Type Registry		10.1. The OAuth Access Token Type Registry
	This specification establishes the OAuth access token type registry.		This specification establishes the OAuth access token type registry.
	skipping to change at page 39, line 5 ¶		skipping to change at page 41, line 11 ¶
	o Parameter name: password		o Parameter name: password
	o Parameter usage location: token request		o Parameter usage location: token request
	o Change controller: IETF		o Change controller: IETF
	o Specification document(s): [[ this document ]]		o Specification document(s): [[ this document ]]
	o Parameter name: refresh_token		o Parameter name: refresh_token
	o Parameter usage location: token request, token response		o Parameter usage location: token request, token response
	o Change controller: IETF		o Change controller: IETF
	o Specification document(s): [[ this document ]]		o Specification document(s): [[ this document ]]
	Appendix A. Examples		Appendix A. Contributors
	[[ TBD ]]
	Appendix B. Contributors
	The following people contributed to preliminary versions of this		The following people contributed to preliminary versions of this
	document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland		document: Blaine Cook (BT), Brian Eaton (Google), Yaron Goland
	(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),		(Microsoft), Brent Goldman (Facebook), Raffi Krikorian (Twitter),
	Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and		Luke Shepard (Facebook), and Allen Tom (Yahoo!). The content and
	concepts within are a product of the OAuth community, WRAP community,		concepts within are a product of the OAuth community, WRAP community,
	and the OAuth Working Group.		and the OAuth Working Group.
	The OAuth Working Group has dozens of very active contributors who		The OAuth Working Group has dozens of very active contributors who
	proposed ideas and wording for this document, including:		proposed ideas and wording for this document, including:
	Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah		Michael Adams, Andrew Arnott, Dirk Balfanz, Brian Campbell, Leah
	Culver, Bill de hOra, Brian Ellin, Igor Faynberg, George Fletcher,		Culver, Bill de hOra, Brian Ellin, Igor Faynberg, George Fletcher,
	Tim Freeman, Evan Gilbert, Kristoffer Gronowski, Justin Hart, Phil		Tim Freeman, Evan Gilbert, Kristoffer Gronowski, Justin Hart, Phil
	Hunt, Mike Jones, John Kemp, Chasen Le Hara, Torsten Lodderstedt,		Hunt, Michael B. Jones, John Kemp, Mark Kent, Chasen Le Hara, Rasmus
	Alastair Mair, Eve Maler, James Manger, Laurence Miao, Chuck		Lerdorf, Torsten Lodderstedt, Alastair Mair, Eve Maler, James Manger,
	Mortimore, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre,		Laurence Miao, Chuck Mortimore, Justin Richer, Peter Saint-Andre, Nat
	Marius Scurtescu, Naitik Shah, Justin Smith, Jeremy Suriel, Christian		Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith,
	Stuebner, Paul Tarjan, Franklin Tse, and Nick Walker.		Jeremy Suriel, Christian Stuebner, Paul Tarjan, Franklin Tse, Nick
			Walker, Skylar Woodward.
	Appendix C. Acknowledgements		Appendix B. Acknowledgements
	[[ Add OAuth 1.0a authors + WG contributors ]]		[[ Add OAuth 1.0a authors + WG contributors ]]
	Appendix D. Document History		Appendix C. Document History
	[[ to be removed by RFC editor before publication as an RFC ]]		[[ to be removed by RFC editor before publication as an RFC ]]
	-12		-13
	o Complete restructure with lots of new prose.
	o Removed terminology and expanded terms in overview.
	o Changed assertions to extensions and added informative reference
	to the SAML 2.0 extension.
	o Renamed access grant to authorization grant.
	o Clarified 'token_type' as case insensitive.
	o Authorization endpoint requires TLS when an access token is
	issued.
	o Removed client assertion credentials, mandatory HTTP Basic
	authentication support for client credentials, WWW-Authenticate
	header, and the OAuth2 authentication scheme.
	o Changed implicit grant (aka user-agent flow) error response from
	query to fragment.
	o Removed the 'redirect_uri_mismatch' error code since in such a
	case, the authorization server must not send the error back to the
	client.
	o Added parameter registration for all parameters in this
	specification.
	o Defined access token type registry.
	-11
	o Many editorial changes. Fixed user authorization section
	structure. Removed unused normative references. Adjusted
	language regarding single use of authorization codes.
	o Fixed header ABNF.
	o Change access token description from shared symmetric secret to
	password.
	o Moved access grant 'none' to a separate section, renamed to
	'client_credentials'.
	o Demoted the HTTP status code requirement from MUST to SHOULD in
	protected resource response error.
	o Removed 'expired_token' error code.
	o Moved all the 'code_and_token' parameter to the fragment (from
	code being in the query).
	o Removed 'assertion_type' parameter (moved to 'grant_type').
	o Added note about redirecting to invalid redirection URIs (open
	redirectors).
	o Removed bearer token section, added new required 'token_type'
	parameter with extensibility.
	o 'error-uri' parameter value changed to absolute URI.
	o OAuth 2.0 HTTP authentication scheme name changed to 'OAuth2'.
	o Dropped the 'WWW-Authenticate' header field 'realm' parameter.
	o Removed definition of access token characters.
	o Added instructions for dealing with error and an invalid
	redirection URI.
	-10
	o Fixed typos. Many editorial changes. Rewrote introduction.
	removed terminology grouping.
	o Allowed POST for resource owner authorization endpoint.
	o Fixed token endpoint to not require client authentication.
	o Made URI query and POST body 'oauth_token' parameter optional.
	o Moved all parameter names and values to use underscores.
	o Changed 'basic_credentials' to 'password',
	'invalid_client_credentials' and 'invalid_client_id' to
	'invalid_client'.
	o Added note that access token requests without an access grant
	should not include a refresh token.
	o Changed scheme name from 'Token' to 'OAuth', simplified request
	format to simple string for token instead of key=value pair (still
	supported for extensions).
	o Defined permitted access token string characters (suitable for
	inclusion in an HTTP header).
	o Added a note about conflicts with previous versions.
	o Moved 'client_id' definition from client authentication to access
	token endpoint.
	o Added definition for 'access grant'.
	-09
	o Fixed typos, editorial changes.
	o Added token expiration example.
	o Added scope parameter to resource owner authorization endpoint
	response.
	o Added note about parameters with empty values (same as omitted).
	o Changed parameter values to use '-' instead of '_'. Parameter
	names still use '_'.
	o Changed authorization endpoint client type to response type with
	values: code, token, and both.
	o Complete cleanup of error codes. Added support for error
	description and URI.
	o Add initial extensibility support.
	-08
	o Renamed verification code to authorization code.
	o Revised terminology, structured section, added new terms.
	o Changed flows to profiles and moved to introduction.
	o Added support for access token rescoping.
	o Cleaned up client credentials section.
	o New introduction overview.
	o Added error code for invalid username and password, and renamed
	error code to be more consistent.
	o Added access grant type parameter to token endpoint.
	-07
	o Major rewrite of entire document structure.
	o Removed device profile.
	o Added verification code support to user-agent flow.
	o Removed multiple formats support, leaving JSON as the only format.
	o Changed assertion "assertion_format" parameter to
	"assertion_type".
	o Removed "type" parameter from token endpoint.
	-06
	o Editorial changes, corrections, clarifications, etc.
	o Removed conformance section.
	o Moved authors section to contributors appendix.
	o Added section on native applications.
	o Changed error response to use the requested format. Added support
	for HTTP "Accept" header.
	o Flipped the order of the web server and user-agent flows.
	o Renamed assertion flow "format" parameter name to
	"assertion_format" to resolve conflict.
	o Removed the term identifier from token definitions. Added a
	cryptographic token definition.
	o Added figure titles.
	o Added server response 401 when client tried to authenticate using
	multiple credentials.
	o Clarified support for TLS alternatives, and added requirement for
	TLS 1.2 support for token endpoint.
	o Removed all signature and cryptography.
	o Removed all discovery.
	o Updated HTML4 reference.
	-05
	o Corrected device example.
	o Added client credentials parameters to the assertion flow as
	OPTIONAL.
	o Added the ability to send client credentials using an HTTP
	authentication scheme.
	o Initial text for the "WWW-Authenticate" header (also added scope
	support).
	o Change authorization endpoint to resource owner endpoint.
	o In the device flow, change the "user_uri" parameter to
	"verification_uri" to avoid confusion with the resource owner
	endpoint.
	o Add "format" request parameter and support for XML and form-
	encoded responses.
	-04
	o Changed all token endpoints to use "POST"
	o Clarified the authorization server's ability to issue a new
	refresh token when refreshing a token.
	o Changed the flow categories to clarify the autonomous group.
	o Changed client credentials language not to always be server-
	issued.
	o Added a "scope" response parameter.
	o Fixed typos.
	o Fixed broken document structure.
	-03
	o Fixed typo in JSON error examples.
	o Fixed general typos.
	o Moved all flows sections up one level.
	-02
	o Removed restriction on "redirect_uri" including a query.
	o Added "scope" parameter.
	o Initial proposal for a JSON-based token response format.
	-01
	o Editorial changes based on feedback from Brian Eaton, Bill Keenan,
	and Chuck Mortimore.
	o Changed device flow "type" parameter values and switch to use only
	the token endpoint.
	-00		o Small editorial changes.
			o Split introduction 'Roles' into 'Roles' and 'Protocol Flow'.
			o Changes section name 'Requesting an Access Token' to 'Obtaining
			Authorization'.
	o Initial draft based on a combination of WRAP and OAuth 1.0a.		o Added explicit authorization request and access token response
			sub-sections for each grant type.
			o Added document overview in the introduction.
			o Reduced the use of 'x_' prefix to SHOULD.
			o Removed unused references and updated others.
			o Dropped 'invalid_client' error from authorization endpoint
			responses.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-httpbis-p1-messaging]
	Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
	Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
	"HTTP/1.1, part 1: URIs, Connections, and Message
	Parsing", draft-ietf-httpbis-p1-messaging-09 (work in
	progress), March 2010.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
	May 2000.
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4627] Crockford, D., "The application/json Media Type for		[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.		JavaScript Object Notation (JSON)", RFC 4627, July 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
	April 2010.
	[W3C.REC-html401-19991224]		[W3C.REC-html401-19991224]
	Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01		Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
	Specification", World Wide Web Consortium		Specification", World Wide Web Consortium
	Recommendation REC-html401-19991224, December 1999,		Recommendation REC-html401-19991224, December 1999,
	<http://www.w3.org/TR/1999/REC-html401-19991224>.		<http://www.w3.org/TR/1999/REC-html401-19991224>.
	11.2. Informative References		11.2. Informative References
	[I-D.hammer-oauth-v2-mac-token]		[I-D.hammer-oauth-v2-mac-token]
	Hammer-Lahav, E., "HTTP Authentication: MAC		Hammer-Lahav, E., "HTTP Authentication: MAC
	Authentication", draft-hammer-oauth-v2-mac-token-01 (work		Authentication", draft-hammer-oauth-v2-mac-token-02 (work
	in progress), January 2011.		in progress), January 2011.
	[I-D.ietf-oauth-saml2-bearer]		[I-D.ietf-oauth-saml2-bearer]
	Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion		Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion
	Grant Type Profile for OAuth 2.0",		Grant Type Profile for OAuth 2.0",
	draft-ietf-oauth-saml2-bearer-00 (work in progress),		draft-ietf-oauth-saml2-bearer-03 (work in progress),
	December 2010.		February 2011.
	[I-D.ietf-oauth-v2-bearer]		[I-D.ietf-oauth-v2-bearer]
	Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0		Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
	Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-01		Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-02
	(work in progress), December 2010.		(work in progress), January 2011.
	[OASIS.saml-core-2.0-os]		[OASIS.saml-core-2.0-os]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	"Assertions and Protocol for the OASIS Security Assertion		"Assertions and Protocol for the OASIS Security Assertion
	Markup Language (SAML) V2.0", OASIS Standard saml-core-		Markup Language (SAML) V2.0", OASIS Standard saml-core-
	2.0-os, March 2005.		2.0-os, March 2005.
	Authors' Addresses		Authors' Addresses
	Eran Hammer-Lahav (editor)		Eran Hammer-Lahav (editor)
End of changes. 93 change blocks.
	474 lines changed or deleted		351 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/