draft-ietf-oauth-token-binding-02.txt		draft-ietf-oauth-token-binding-03.txt
	OAuth Working Group M. Jones		OAuth Working Group M. Jones
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track J. Bradley		Intended status: Standards Track J. Bradley
	Expires: September 14, 2017 B. Campbell		Expires: September 28, 2017 B. Campbell
	Ping Identity		Ping Identity
	W. Denniss		W. Denniss
	Google		Google
	March 13, 2017		March 27, 2017
	OAuth 2.0 Token Binding		OAuth 2.0 Token Binding
	draft-ietf-oauth-token-binding-02		draft-ietf-oauth-token-binding-03
	Abstract		Abstract
	This specification enables OAuth 2.0 implementations to apply Token		This specification enables OAuth 2.0 implementations to apply Token
	Binding to Access Tokens, Authorization Codes, and Refresh Tokens.		Binding to Access Tokens, Authorization Codes, and Refresh Tokens.
	This cryptographically binds these tokens to a client's Token Binding		This cryptographically binds these tokens to a client's Token Binding
	key pair, possession of which is proven on the TLS connections over		key pair, possession of which is proven on the TLS connections over
	which the tokens are intended to be used. This use of Token Binding		which the tokens are intended to be used. This use of Token Binding
	protects these tokens from man-in-the-middle and token export and		protects these tokens from man-in-the-middle and token export and
	replay attacks.		replay attacks.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 September 14, 2017.		This Internet-Draft will expire on September 28, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	Binding Message are different than in the initial request.		Binding Message are different than in the initial request.
	POST /as/token.oauth2 HTTP/1.1		POST /as/token.oauth2 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
	Sec-Token-Binding: AIkAAgBBQGto7hHRR0Y5nkOWqc9KNfwW95dEFmSI_tCZ_Cbl		Sec-Token-Binding: AIkAAgBBQGto7hHRR0Y5nkOWqc9KNfwW95dEFmSI_tCZ_Cbl
	7LWlt6Xjp3DbjiDJavGFiKP2HV_2JSE42VzmKOVVV8m7eqAAQCpGbaG_YRf27qOra		7LWlt6Xjp3DbjiDJavGFiKP2HV_2JSE42VzmKOVVV8m7eqAAQCpGbaG_YRf27qOra
	L0UT4fsKKjL6PukuOT00qzamoAXxOq7m_id7O3mLpnb_sM7kwSxLi7iNHzzDgCAkP		L0UT4fsKKjL6PukuOT00qzamoAXxOq7m_id7O3mLpnb_sM7kwSxLi7iNHzzDgCAkP
	t3lHwAAA		t3lHwAAA
	refresh_token=ACClZEIQTjW9arT9GOJGGd7QNwqOMmUYfsJTiv8his4		refresh_token=ACClZEIQTjW9arT9GOJGGd7QNwqOMmUYfsJTiv8his4
	&grant_type=refresh_token&client_id=example-native-client-id		&grant_type=refresh_token&client_id=example-native-client-id
	Figure 3: Refresh Request		Figure 3: Refresh Request
	However, because the Token Binding ID is long-lived and may span		However, because the Token Binding ID is long-lived and may span
	multiple TLS sessions and connections, it is the same as in the		multiple TLS sessions and connections, it is the same as in the
	initial request. That Token Binding ID is what the refresh token is		initial request. That Token Binding ID is what the refresh token is
	bound to, so the authorization server is able to verify it and issue		bound to, so the authorization server is able to verify it and issue
	a new access token.		a new access token.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 44 ¶
	The authorization server issues an access token and delivers it to		The authorization server issues an access token and delivers it to
	the client by redirecting the user-agent with the following HTTP		the client by redirecting the user-agent with the following HTTP
	response:		response:
	HTTP/1.1 302 Found		HTTP/1.1 302 Found
	Location: https://client.example.org/cb#state=rM8pZxG1c3gKy6rEbsD8s		Location: https://client.example.org/cb#state=rM8pZxG1c3gKy6rEbsD8s
	&expires_in=3600&token_type=Bearer		&expires_in=3600&token_type=Bearer
	&access_token=eyJhbGciOiJFUzI[...omitted for brevity...]8xy5W5sQ		&access_token=eyJhbGciOiJFUzI[...omitted for brevity...]8xy5W5sQ
	Figure 6: Authorization Request		Figure 6: Authorization Response
	The access token is bound to the Referred Token Binding ID from the		The access token is bound to the Referred Token Binding ID from the
	authorization request, which when represented as a JWT, as described		authorization request, which when represented as a JWT, as described
	in Section 3.4, contains the SHA-256 hash of the Token Binding ID as		in Section 3.4, contains the SHA-256 hash of the Token Binding ID as
	the value of the "tbh" (token binding hash) member of the "cnf"		the value of the "tbh" (token binding hash) member of the "cnf"
	(confirmation) claim. The confirmation claim portion of the JWT		(confirmation) claim. The confirmation claim portion of the JWT
	Claims Set is shown in the following figure.		Claims Set is shown in the following figure.
	{		{
	...other claims omitted for brevity...		...other claims omitted for brevity...
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/json		Content-Type: application/json
	Cache-Control: no-cache, no-store		Cache-Control: no-cache, no-store
	{		{
	"access_token":"eyJhbGciOiJFUzI1NiIsImtp[...omitted...]1cs29j5c3",		"access_token":"eyJhbGciOiJFUzI1NiIsImtp[...omitted...]1cs29j5c3",
	"token_type":"Bearer",		"token_type":"Bearer",
	"expires_in":3600		"expires_in":3600
	}		}
	Figure 9: Authorization Request		Figure 9: Response
	The access token is bound to the Referred Token Binding ID of the		The access token is bound to the Referred Token Binding ID of the
	access token request, which when represented as a JWT, as described		access token request, which when represented as a JWT, as described
	in Section 3.4, contains the SHA-256 hash of the Token Binding ID as		in Section 3.4, contains the SHA-256 hash of the Token Binding ID as
	the value of the "tbh" (token binding hash) member of the "cnf"		the value of the "tbh" (token binding hash) member of the "cnf"
	(confirmation) claim. The confirmation claim portion of the JWT		(confirmation) claim. The confirmation claim portion of the JWT
	Claims Set of the access token is shown in the following figure.		Claims Set of the access token is shown in the following figure.
	{		{
	...other claims omitted for brevity...		...other claims omitted for brevity...
	skipping to change at page 11, line 36 ¶		skipping to change at page 11, line 36 ¶
	Section 3.2.1 would look something like the following. The		Section 3.2.1 would look something like the following. The
	base64url-encoded EKM from the TLS connection over which the request		base64url-encoded EKM from the TLS connection over which the request
	was made is "7LsNP3BT1aHHdXdk6meEWjtSkiPVLb7YS6iHp-JXmuE". The		was made is "7LsNP3BT1aHHdXdk6meEWjtSkiPVLb7YS6iHp-JXmuE". The
	protected resource validates the binding by comparing the Provided		protected resource validates the binding by comparing the Provided
	Token Binding ID from the "Sec-Token-Binding" header to the token		Token Binding ID from the "Sec-Token-Binding" header to the token
	binding hash confirmation of the access token. Extra line breaks in		binding hash confirmation of the access token. Extra line breaks in
	the example are for display purposes only.		the example are for display purposes only.
	GET /api/stuff HTTP/1.1		GET /api/stuff HTTP/1.1
	Host: resource.example.org		Host: resource.example.org
	Content-Type: application/x-www-form-urlencoded		Authorization: Bearer eyJhbGciOiJFUzI1NiIsI[...omitted...]1cs29j5c3
	Sec-Token-Binding: AIkAAgBBQLgtRpWFPN66kxhxGrtaKrzcMtHw7HV8yMk_-MdR		Sec-Token-Binding: AIkAAgBBQLgtRpWFPN66kxhxGrtaKrzcMtHw7HV8yMk_-MdR
	XJXbDMYxZCWnCASRRrmHHHL5wmpP3bhYt0ChRDbsMapfh_QAQN1He3Ftj4Wa_S_fz		XJXbDMYxZCWnCASRRrmHHHL5wmpP3bhYt0ChRDbsMapfh_QAQN1He3Ftj4Wa_S_fz
	ZVns4saLfj6aBoMSQW6rLs19IIvHze7LrGjKyCfPTKXjajebxp-TLPFZCc0JTqTY5		ZVns4saLfj6aBoMSQW6rLs19IIvHze7LrGjKyCfPTKXjajebxp-TLPFZCc0JTqTY5
	_0MBAAAA		_0MBAAAA
	Figure 11: Protected Resource Request		Figure 11: Protected Resource Request
	3.4. Representing Token Binding in JWT Access Tokens		3.4. Representing Token Binding in JWT Access Tokens
	If the access token is represented as a JWT, the token binding		If the access token is represented as a JWT, the token binding
	skipping to change at page 13, line 46 ¶		skipping to change at page 13, line 46 ¶
	request by sending the user's browser to the authorization endpoint.		request by sending the user's browser to the authorization endpoint.
	The resulting HTTP request looks something like the following (with		The resulting HTTP request looks something like the following (with
	extra line breaks for display purposes only).		extra line breaks for display purposes only).
	GET /as/authorization.oauth2?response_type=code		GET /as/authorization.oauth2?response_type=code
	&client_id=example-native-client-id&state=oUC2jyYtzRCrMyWrVnGj		&client_id=example-native-client-id&state=oUC2jyYtzRCrMyWrVnGj
	&code_challenge=rBlgOyMY4teiuJMDgOwkrpsAjPyI07D2WsEM-dnq6eE		&code_challenge=rBlgOyMY4teiuJMDgOwkrpsAjPyI07D2WsEM-dnq6eE
	&code_challenge_method=TB-S256 HTTP/1.1		&code_challenge_method=TB-S256 HTTP/1.1
	Host: server.example.com		Host: server.example.com
	Figure 13: Authorization Request		Figure 13: Authorization Request with PKCE Challenge
	4.1.2. Code Verifier		4.1.2. Code Verifier
	Upon receipt of the authorization code, the client sends the access		Upon receipt of the authorization code, the client sends the access
	token request to the token endpoint. The Token Binding Protocol		token request to the token endpoint. The Token Binding Protocol
	[I-D.ietf-tokbind-protocol] is negotiated on the TLS connection		[I-D.ietf-tokbind-protocol] is negotiated on the TLS connection
	between the client and the authorization server and the "Sec-Token-		between the client and the authorization server and the "Sec-Token-
	Binding" header, as defined in Token Binding over HTTP		Binding" header, as defined in Token Binding over HTTP
	[I-D.ietf-tokbind-https], is included in the access token request.		[I-D.ietf-tokbind-https], is included in the access token request.
	The authorization server extracts the Provided Token Binding ID from		The authorization server extracts the Provided Token Binding ID from
	skipping to change at page 14, line 49 ¶		skipping to change at page 14, line 49 ¶
	Host: server.example.com		Host: server.example.com
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	Sec-Token-Binding: AIkAAgBBQEOO9GRFP-LM0hoWw6-2i318BsuuUum5AL8bt1sz		Sec-Token-Binding: AIkAAgBBQEOO9GRFP-LM0hoWw6-2i318BsuuUum5AL8bt1sz
	lr1EFfp5DMXMNW3O8WjcIXr2DKJnI4xnuGsE6GywQd9RbD0AQJDb3xyo9PBxj8M6Y		lr1EFfp5DMXMNW3O8WjcIXr2DKJnI4xnuGsE6GywQd9RbD0AQJDb3xyo9PBxj8M6Y
	jLt-6OaxgDkyoBoTkyrnNbLc8tJQ0JtXomKzBbj5qPtHDduXc6xz_lzvNpxSPxi42		jLt-6OaxgDkyoBoTkyrnNbLc8tJQ0JtXomKzBbj5qPtHDduXc6xz_lzvNpxSPxi42
	8m7wkAAA		8m7wkAAA
	grant_type=authorization_code&code=mJAReTWKX7zI3oHUNd4o3PeNqNqxKGp6		grant_type=authorization_code&code=mJAReTWKX7zI3oHUNd4o3PeNqNqxKGp6
	&code_verifier=provided_tb&client_id=example-native-client-id		&code_verifier=provided_tb&client_id=example-native-client-id
	Figure 14: Authorization Request		Figure 14: Token Request with PKCE Verifier
	4.2. Web Server Clients		4.2. Web Server Clients
	This section describes a PKCE method suitable for web server clients,		This section describes a PKCE method suitable for web server clients,
	which cryptographically binds the authorization code to a Token		which cryptographically binds the authorization code to a Token
	Binding key pair on the browser. The authorization code is bound to		Binding key pair on the browser. The authorization code is bound to
	the Token Binding ID that the browser uses to deliver the		the Token Binding ID that the browser uses to deliver the
	authorization code to a web server client, which is sent to the		authorization code to a web server client, which is sent to the
	authorization server as the Referred Token Binding ID during the		authorization server as the Referred Token Binding ID during the
	authorization request. The web server client conveys the Token		authorization request. The web server client conveys the Token
	skipping to change at page 23, line 38 ¶		skipping to change at page 23, line 38 ¶
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-oauth-native-apps]		[I-D.ietf-oauth-native-apps]
	Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",		Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
	draft-ietf-oauth-native-apps-08 (work in progress), March		draft-ietf-oauth-native-apps-08 (work in progress), March
	2017.		2017.
	[OpenID.Core]		[OpenID.Core]
	Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and		Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
	C. Mortimore, "OpenID Connect Core 1.0", November 2014,		C. Mortimore, "OpenID Connect Core 1.0", August 2015,
	<http://openid.net/specs/openid-connect-core-1_0.html>.		<http://openid.net/specs/openid-connect-core-1_0.html>.
	[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token		[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
	(JWT) Profile for OAuth 2.0 Client Authentication and		(JWT) Profile for OAuth 2.0 Client Authentication and
	Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May		Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
	2015, <http://www.rfc-editor.org/info/rfc7523>.		2015, <http://www.rfc-editor.org/info/rfc7523>.
	[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and		[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
	P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",		P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
	RFC 7591, DOI 10.17487/RFC7591, July 2015,		RFC 7591, DOI 10.17487/RFC7591, July 2015,
	skipping to change at page 24, line 39 ¶		skipping to change at page 24, line 39 ¶
	Boolean values do not adequately convey Token Binding support, as		Boolean values do not adequately convey Token Binding support, as
	different components may support different key parameters types.		different components may support different key parameters types.
	And successful negotiation likely doesn't provide the application		And successful negotiation likely doesn't provide the application
	layer info about all the supported key parameters types but rather		layer info about all the supported key parameters types but rather
	just the one that was negotiated.		just the one that was negotiated.
	Appendix C. Document History		Appendix C. 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 ]]
			-03
			o Fix a few mistakes in and around the examples that were noticed
			preparing the slides for IETF 98 Chicago.
	-02		-02
	o Added a section on Token Binding for authorization codes with one		o Added a section on Token Binding for authorization codes with one
	variation for native clients and one for web server clients.		variation for native clients and one for web server clients.
	o Updated language to reflect that the binding is to the token		o Updated language to reflect that the binding is to the token
	binding key pair and that proof-of-possession of that key is done		binding key pair and that proof-of-possession of that key is done
	on the TLS connection.		on the TLS connection.
	o Added a bunch of examples.		o Added a bunch of examples.
End of changes. 12 change blocks.
	12 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/