< draft-ietf-oauth-v2-bearer-20.txt		draft-ietf-oauth-v2-bearer-21.txt >
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track D. Hardt		Intended status: Standards Track D. Hardt
	Expires: December 10, 2012 independent		Expires: December 21, 2012 independent
	D. Recordon		D. Recordon
	Facebook		Facebook
	June 8, 2012		June 19, 2012
	The OAuth 2.0 Authorization Framework: Bearer Token Usage		The OAuth 2.0 Authorization Framework: Bearer Token Usage
	draft-ietf-oauth-v2-bearer-20		draft-ietf-oauth-v2-bearer-21
	Abstract		Abstract
	This specification describes how to use bearer tokens in HTTP		This specification describes how to use bearer tokens in HTTP
	requests to access OAuth 2.0 protected resources. Any party in		requests to access OAuth 2.0 protected resources. Any party in
	possession of a bearer token (a "bearer") can use it to get access to		possession of a bearer token (a "bearer") can use it to get access to
	the associated resources (without demonstrating possession of a		the associated resources (without demonstrating possession of a
	cryptographic key). To prevent misuse, bearer tokens need to be		cryptographic key). To prevent misuse, bearer tokens need to be
	protected from disclosure in storage and in transport.		protected from disclosure in storage and in transport.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 December 10, 2012.		This Internet-Draft will expire on December 21, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 23 ¶
	Tokens are issued to clients by an authorization server with the		Tokens are issued to clients by an authorization server with the
	approval of the resource owner. The client uses the access token to		approval of the resource owner. The client uses the access token to
	access the protected resources hosted by the resource server. This		access the protected resources hosted by the resource server. This
	specification describes how to make protected resource requests when		specification describes how to make protected resource requests when
	the OAuth access token is a bearer token.		the OAuth access token is a bearer token.
	This specification defines the use of bearer tokens over HTTP/1.1		This specification defines the use of bearer tokens over HTTP/1.1
	[I-D.ietf-httpbis-p1-messaging] using TLS [RFC5246] to access		[I-D.ietf-httpbis-p1-messaging] using TLS [RFC5246] to access
	protected resources. TLS is mandatory to implement and use with this		protected resources. TLS is mandatory to implement and use with this
	specification; other specifications may extend this specification for		specification; other specifications may extend this specification for
	use with other transport protocols. While designed for use with		use with other protocols. While designed for use with access tokens
	access tokens resulting from OAuth 2.0 Authorization		resulting from OAuth 2.0 Authorization [I-D.ietf-oauth-v2] flows to
	[I-D.ietf-oauth-v2] flows to access OAuth protected resources, this		access OAuth protected resources, this specification actually defines
	specification actually defines a general HTTP authorization method		a general HTTP authorization method that can be used with bearer
	that can be used with bearer tokens from any source to access any		tokens from any source to access any resources protected by those
	resources protected by those bearer tokens. The Bearer		bearer tokens. The Bearer authentication scheme is intended
	authentication scheme is intended primarily for server authentication		primarily for server authentication using the WWW-Authenticate and
	using the WWW-Authenticate and Authorization HTTP headers, but does		Authorization HTTP headers, but does not preclude its use for proxy
	not preclude its use for proxy authentication.		authentication.
	1.1. Notational Conventions		1.1. 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
	document are to be interpreted as described in Key words for use in		document are to be interpreted as described in Key words for use in
	RFCs to Indicate Requirement Levels [RFC2119].		RFCs to Indicate Requirement Levels [RFC2119].
	This document uses the Augmented Backus-Naur Form (ABNF) notation of		This document uses the Augmented Backus-Naur Form (ABNF) notation of
	[RFC5234]. Additionally, the following rules are included from		[RFC5234]. Additionally, the following rules are included from
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	grant from the resource owner and then exchange the authorization		grant from the resource owner and then exchange the authorization
	grant for an access token. The access token represents the grant's		grant for an access token. The access token represents the grant's
	scope, duration, and other attributes granted by the authorization		scope, duration, and other attributes granted by the authorization
	grant. The client accesses the protected resource by presenting the		grant. The client accesses the protected resource by presenting the
	access token to the resource server. In some cases, a client can		access token to the resource server. In some cases, a client can
	directly present its own credentials to an authorization server to		directly present its own credentials to an authorization server to
	obtain an access token without having to first obtain an		obtain an access token without having to first obtain an
	authorization grant from a resource owner.		authorization grant from a resource owner.
	The access token provides an abstraction, replacing different		The access token provides an abstraction, replacing different
	authorization constructs (e.g. username and password, assertion) for		authorization constructs (e.g., username and password, assertion) for
	a single token understood by the resource server. This abstraction		a single token understood by the resource server. This abstraction
	enables issuing access tokens valid for a short time period, as well		enables issuing access tokens valid for a short time period, as well
	as removing the resource server's need to understand a wide range of		as removing the resource server's need to understand a wide range of
	authentication schemes.		authentication schemes.
	+--------+ +---------------+		+--------+ +---------------+
	| |--(A)- Authorization Request ->| Resource |		| |--(A)- Authorization Request ->| Resource |
	| | | Owner |		| | | Owner |
	| |<-(B)-- Authorization Grant ---| |		| |<-(B)-- Authorization Grant ---| |
	| | +---------------+		| | +---------------+
	skipping to change at page 7, line 50 ¶		skipping to change at page 7, line 50 ¶
	success (2XX status) responses to these requests SHOULD contain a		success (2XX status) responses to these requests SHOULD contain a
	Cache-Control header with the "private" option.		Cache-Control header with the "private" option.
	Because of the security weaknesses associated with the URI method		Because of the security weaknesses associated with the URI method
	(see Section 5), including the high likelihood that the URL		(see Section 5), including the high likelihood that the URL
	containing the access token will be logged, it SHOULD NOT be used		containing the access token will be logged, it SHOULD NOT be used
	unless it is impossible to transport the access token in the		unless it is impossible to transport the access token in the
	"Authorization" request header field or the HTTP request entity-body.		"Authorization" request header field or the HTTP request entity-body.
	Resource servers MAY support this method.		Resource servers MAY support this method.
	This method is included to document current use; its use is NOT		This method is included to document current use; its use is not
	RECOMMENDED, both due to its security deficiencies (see Section 5)		recommended, both due to its security deficiencies (see Section 5)
	and because it uses a reserved query parameter name, which is counter		and because it uses a reserved query parameter name, which is counter
	to URI namespace best practices, per the Architecture of the World		to URI namespace best practices, per the Architecture of the World
	Wide Web [W3C.REC-webarch-20041215].		Wide Web [W3C.REC-webarch-20041215].
	3. The WWW-Authenticate Response Header Field		3. The WWW-Authenticate Response Header Field
	If the protected resource request does not include authentication		If the protected resource request does not include authentication
	credentials or does not contain an access token that enables access		credentials or does not contain an access token that enables access
	to the protected resource, the resource server MUST include the HTTP		to the protected resource, the resource server MUST include the HTTP
	"WWW-Authenticate" response header field; it MAY include it in		"WWW-Authenticate" response header field; it MAY include it in
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 19 ¶
	request a new access token and retry the protected resource		request a new access token and retry the protected resource
	request.		request.
	insufficient_scope		insufficient_scope
	The request requires higher privileges than provided by the		The request requires higher privileges than provided by the
	access token. The resource server SHOULD respond with the HTTP		access token. The resource server SHOULD respond with the HTTP
	403 (Forbidden) status code and MAY include the "scope"		403 (Forbidden) status code and MAY include the "scope"
	attribute with the scope necessary to access the protected		attribute with the scope necessary to access the protected
	resource.		resource.
	If the request lacks any authentication information (i.e. the client		If the request lacks any authentication information (e.g., the client
	was unaware authentication is necessary or attempted using an		was unaware authentication is necessary or attempted using an
	unsupported authentication method), the resource server SHOULD NOT		unsupported authentication method), the resource server SHOULD NOT
	include an error code or other error information.		include an error code or other error information.
	For example:		For example:
	HTTP/1.1 401 Unauthorized		HTTP/1.1 401 Unauthorized
	WWW-Authenticate: Bearer realm="example"		WWW-Authenticate: Bearer realm="example"
	4. Example Access Token Response		4. Example Access Token Response
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 42 ¶
	draft-ietf-httpbis-p1-messaging-19 (work in progress),		draft-ietf-httpbis-p1-messaging-19 (work in progress),
	March 2012.		March 2012.
	[I-D.ietf-httpbis-p7-auth]		[I-D.ietf-httpbis-p7-auth]
	Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part		Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part
	7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in		7: Authentication", draft-ietf-httpbis-p7-auth-19 (work in
	progress), March 2012.		progress), March 2012.
	[I-D.ietf-oauth-v2]		[I-D.ietf-oauth-v2]
	Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0		Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0
	Authorization Framework", draft-ietf-oauth-v2-27 (work in		Authorization Framework", draft-ietf-oauth-v2-28 (work in
	progress), June 2012.		progress), June 2012.
	[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.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	skipping to change at page 18, line 47 ¶		skipping to change at page 18, line 47 ¶
	Reschke, Rob Richards, Justin Richer, Peter Saint-Andre, Nat		Reschke, Rob Richards, Justin Richer, Peter Saint-Andre, Nat
	Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith,		Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Justin Smith,
	Jeremy Suriel, Christian Stuebner, Doug Tangren, Paul Tarjan, Hannes		Jeremy Suriel, Christian Stuebner, Doug Tangren, Paul Tarjan, Hannes
	Tschofenig, Franklin Tse, Sean Turner, Paul Walker, Shane Weeden,		Tschofenig, Franklin Tse, Sean Turner, Paul Walker, Shane Weeden,
	Skylar Woodward, and Zachary Zeltsan.		Skylar Woodward, and Zachary Zeltsan.
	Appendix B. Document History		Appendix B. Document History
	[[ to be removed by the RFC editor before publication as an RFC ]]		[[ to be removed by the RFC editor before publication as an RFC ]]
			-21
			o Changed "NOT RECOMMENDED" to "not recommended" in caveat about the
			URI Query Parameter method.
			o Changed "other specifications may extend this specification for
			use with other transport protocols" to "other specifications may
			extend this specification for use with other protocols".
			o Changed Acknowledgements to use only ASCII characters, per the RFC
			style guide.
	-20		-20
	o Added caveat about using a reserved query parameter name being		o Added caveat about using a reserved query parameter name being
	counter to URI namespace best practices.		counter to URI namespace best practices.
	o Specified use of Cache-Control options when using the URI Query		o Specified use of Cache-Control options when using the URI Query
	Parameter method.		Parameter method.
	o Changed title to "The OAuth 2.0 Authorization Framework: Bearer		o Changed title to "The OAuth 2.0 Authorization Framework: Bearer
	Token Usage".		Token Usage".
	o Referenced syntax definitions for the "scope", "error",		o Referenced syntax definitions for the "scope", "error",
End of changes. 11 change blocks.
	18 lines changed or deleted		30 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/