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/