< draft-ietf-oauth-token-binding-07.txt   draft-ietf-oauth-token-binding-08.txt >
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: December 23, 2018 Ping Identity Expires: April 22, 2019 Ping Identity
J. Bradley J. Bradley
Yubico Yubico
W. Denniss W. Denniss
Google Google
June 21, 2018 October 19, 2018
OAuth 2.0 Token Binding OAuth 2.0 Token Binding
draft-ietf-oauth-token-binding-07 draft-ietf-oauth-token-binding-08
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, Refresh Tokens, JWT Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT
Authorization Grants, and JWT Client Authentication. This Authorization Grants, and JWT Client Authentication. This
cryptographically binds these tokens to a client's Token Binding key cryptographically binds these tokens to a client's Token Binding key
pair, possession of which is proven on the TLS connections over which pair, possession of which is proven on the TLS connections over which
the tokens are intended to be used. This use of Token Binding 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
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2018. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 22 skipping to change at page 2, line 22
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. Requirements Notation and Conventions . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Token Binding for Refresh Tokens . . . . . . . . . . . . . . 4 2. Token Binding for Refresh Tokens . . . . . . . . . . . . . . 4
2.1. Example Token Binding for Refresh Tokens . . . . . . . . 4 2.1. Example Token Binding for Refresh Tokens . . . . . . . . 4
3. Token Binding for Access Tokens . . . . . . . . . . . . . . . 7 3. Token Binding for Access Tokens . . . . . . . . . . . . . . . 6
3.1. Access Tokens Issued from the Authorization Endpoint . . 8 3.1. Access Tokens Issued from the Authorization Endpoint . . 7
3.1.1. Example Access Token Issued from the Authorization 3.1.1. Example Access Token Issued from the Authorization
Endpoint . . . . . . . . . . . . . . . . . . . . . . 8 Endpoint . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Access Tokens Issued from the Token Endpoint . . . . . . 9 3.2. Access Tokens Issued from the Token Endpoint . . . . . . 9
3.2.1. Example Access Token Issued from the Token Endpoint . 10 3.2.1. Example Access Token Issued from the Token Endpoint . 9
3.3. Protected Resource Token Binding Validation . . . . . . . 12 3.3. Protected Resource Token Binding Validation . . . . . . . 11
3.3.1. Example Protected Resource Request . . . . . . . . . 12 3.3.1. Example Protected Resource Request . . . . . . . . . 11
3.4. Representing Token Binding in JWT Access Tokens . . . . . 12 3.4. Representing Token Binding in JWT Access Tokens . . . . . 11
3.5. Representing Token Binding in Introspection Responses . . 13 3.5. Representing Token Binding in Introspection Responses . . 12
4. Token Binding Metadata . . . . . . . . . . . . . . . . . . . 14 4. Token Binding Metadata . . . . . . . . . . . . . . . . . . . 13
4.1. Token Binding Client Metadata . . . . . . . . . . . . . . 14 4.1. Token Binding Client Metadata . . . . . . . . . . . . . . 13
4.2. Token Binding Authorization Server Metadata . . . . . . . 14 4.2. Token Binding Authorization Server Metadata . . . . . . . 13
5. Token Binding for Authorization Codes . . . . . . . . . . . . 15 5. Token Binding for Authorization Codes . . . . . . . . . . . . 14
5.1. Native Application Clients . . . . . . . . . . . . . . . 15 5.1. Native Application Clients . . . . . . . . . . . . . . . 14
5.1.1. Code Challenge . . . . . . . . . . . . . . . . . . . 15 5.1.1. Code Challenge . . . . . . . . . . . . . . . . . . . 14
5.1.1.1. Example Code Challenge . . . . . . . . . . . . . 16 5.1.1.1. Example Code Challenge . . . . . . . . . . . . . 15
5.1.2. Code Verifier . . . . . . . . . . . . . . . . . . . . 16 5.1.2. Code Verifier . . . . . . . . . . . . . . . . . . . . 15
5.1.2.1. Example Code Verifier . . . . . . . . . . . . . . 17 5.1.2.1. Example Code Verifier . . . . . . . . . . . . . . 16
5.2. Web Server Clients . . . . . . . . . . . . . . . . . . . 17 5.2. Web Server Clients . . . . . . . . . . . . . . . . . . . 16
5.2.1. Code Challenge . . . . . . . . . . . . . . . . . . . 18 5.2.1. Code Challenge . . . . . . . . . . . . . . . . . . . 17
5.2.1.1. Example Code Challenge . . . . . . . . . . . . . 18 5.2.1.1. Example Code Challenge . . . . . . . . . . . . . 17
5.2.2. Code Verifier . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Code Verifier . . . . . . . . . . . . . . . . . . . . 18
5.2.2.1. Example Code Verifier . . . . . . . . . . . . . . 19 5.2.2.1. Example Code Verifier . . . . . . . . . . . . . . 18
6. Token Binding JWT Authorization Grants and Client 6. Token Binding JWT Authorization Grants and Client
Authentication . . . . . . . . . . . . . . . . . . . . . . . 20 Authentication . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. JWT Format and Processing Requirements . . . . . . . . . 20 6.1. JWT Format and Processing Requirements . . . . . . . . . 19
6.2. Token Bound JWTs for Client Authentication . . . . . . . 21 6.2. Token Bound JWTs for Client Authentication . . . . . . . 20
6.3. Token Bound JWTs for as Authorization Grants . . . . . . 21 6.3. Token Bound JWTs for as Authorization Grants . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Phasing in Token Binding . . . . . . . . . . . . . . . . 22 7.1. Phasing in Token Binding . . . . . . . . . . . . . . . . 21
7.2. Binding of Refresh Tokens . . . . . . . . . . . . . . . . 22 7.2. Binding of Refresh Tokens . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. OAuth Dynamic Client Registration Metadata Registration . 23 8.1. OAuth Dynamic Client Registration Metadata Registration . 22
8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 23 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 22
8.2. OAuth Authorization Server Metadata Registration . . . . 24 8.2. OAuth Authorization Server Metadata Registration . . . . 23
8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 24 8.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 23
8.3. PKCE Code Challenge Method Registration . . . . . . . . . 24 8.3. PKCE Code Challenge Method Registration . . . . . . . . . 23
8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 24 8.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 23
9. Token Endpoint Authentication Method Registration . . . . . . 24 9. Token Endpoint Authentication Method Registration . . . . . . 23
9.1. Registry Contents . . . . . . . . . . . . . . . . . . . . 25 9.1. Registry Contents . . . . . . . . . . . . . . . . . . . . 24
10. Sub-Namespace Registrations . . . . . . . . . . . . . . . . . 25 10. Sub-Namespace Registrations . . . . . . . . . . . . . . . . . 24
10.1. Registry Contents . . . . . . . . . . . . . . . . . . . 25 10.1. Registry Contents . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix B. Document History . . . . . . . . . . . . . . . . . . 28 Appendix B. Document History . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This specification enables OAuth 2.0 [RFC6749] implementations to This specification enables OAuth 2.0 [RFC6749] implementations to
apply Token Binding (TLS Extension for Token Binding Protocol apply Token Binding (TLS Extension for Token Binding Protocol
Negotiation [I-D.ietf-tokbind-negotiation], The Token Binding Negotiation [RFC8472], The Token Binding Protocol Version 1.0
Protocol Version 1.0 [I-D.ietf-tokbind-protocol] and Token Binding [RFC8471] and Token Binding over HTTP [RFC8473]) to Access Tokens,
over HTTP [I-D.ietf-tokbind-https]) to Access Tokens, Authorization Authorization Codes, Refresh Tokens, JWT Authorization Grants, and
Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client JWT Client Authentication. This cryptographically binds these tokens
Authentication. This cryptographically binds these tokens to a to a client's Token Binding key pair, possession of which is proven
client's Token Binding key pair, possession of which is proven on the on the TLS connections over which the tokens are intended to be used.
TLS connections over which the tokens are intended to be used. This This use of Token Binding protects these tokens from man-in-the-
use of Token Binding protects these tokens from man-in-the-middle and middle and token export and replay attacks.
token export and replay attacks.
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
This specification uses the terms "Access Token", "Authorization This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Server", "Client", Code", "Authorization Endpoint", "Authorization Server", "Client",
"Protected Resource", "Refresh Token", and "Token Endpoint" defined "Protected Resource", "Refresh Token", and "Token Endpoint" defined
by OAuth 2.0 [RFC6749], the terms "Claim" and "JSON Web Token (JWT)" by OAuth 2.0 [RFC6749], the terms "Claim" and "JSON Web Token (JWT)"
defined by JSON Web Token (JWT) [JWT], the term "User Agent" defined defined by JSON Web Token (JWT) [JWT], the term "User Agent" defined
by RFC 7230 [RFC7230], and the terms "Provided", "Referred", "Token by RFC 7230 [RFC7230], and the terms "Provided", "Referred", "Token
Binding" and "Token Binding ID" defined by Token Binding over HTTP Binding" and "Token Binding ID" defined by Token Binding over HTTP
[I-D.ietf-tokbind-https]. [RFC8473].
2. Token Binding for Refresh Tokens 2. Token Binding for Refresh Tokens
Token Binding of refresh tokens is a straightforward first-party Token Binding of refresh tokens is a straightforward first-party
scenario, applying term "first-party" as used in Token Binding over scenario, applying term "first-party" as used in Token Binding over
HTTP [I-D.ietf-tokbind-https]. It cryptographically binds the HTTP [RFC8473]. It cryptographically binds the refresh token to the
refresh token to the client's Token Binding key pair, possession of client's Token Binding key pair, possession of which is proven on the
which is proven on the TLS connections between the client and the TLS connections between the client and the token endpoint. This case
token endpoint. This case is straightforward because the refresh is straightforward because the refresh token is both retrieved by the
token is both retrieved by the client from the token endpoint and client from the token endpoint and sent by the client to the token
sent by the client to the token endpoint. Unlike the federation use endpoint. Unlike the federation use cases described in Token Binding
cases described in Token Binding over HTTP [I-D.ietf-tokbind-https], over HTTP [RFC8473], Section 4, and the access token case described
Section 4, and the access token case described in the next section, in the next section, only a single TLS connection is involved in the
only a single TLS connection is involved in the refresh token case. refresh token case.
Token Binding a refresh token requires that the authorization server Token Binding a refresh token requires that the authorization server
do two things. First, when refresh token is sent to the client, the do two things. First, when refresh token is sent to the client, the
authorization server needs to remember the Provided Token Binding ID authorization server needs to remember the Provided Token Binding ID
and remember its association with the issued refresh token. Second, and remember its association with the issued refresh token. Second,
when a token request containing a refresh token is received at the when a token request containing a refresh token is received at the
token endpoint, the authorization server needs to verify that the token endpoint, the authorization server needs to verify that the
Provided Token Binding ID for the request matches the remembered Provided Token Binding ID for the request matches the remembered
Token Binding ID associated with the refresh token. If the Token Token Binding ID associated with the refresh token. If the Token
Binding IDs do not match, the authorization server should return an Binding IDs do not match, the authorization server should return an
skipping to change at page 7, line 23 skipping to change at page 6, line 48
} }
Figure 4: Successful Response Figure 4: Successful Response
3. Token Binding for Access Tokens 3. Token Binding for Access Tokens
Token Binding for access tokens cryptographically binds the access Token Binding for access tokens cryptographically binds the access
token to the client's Token Binding key pair, possession of which is token to the client's Token Binding key pair, possession of which is
proven on the TLS connections between the client and the protected proven on the TLS connections between the client and the protected
resource. Token Binding is applied to access tokens in a similar resource. Token Binding is applied to access tokens in a similar
manner to that described in Token Binding over HTTP manner to that described in Token Binding over HTTP [RFC8473],
[I-D.ietf-tokbind-https], Section 4 (Federation Use Cases). It also Section 4 (Federation Use Cases). It also builds upon the mechanisms
builds upon the mechanisms for Token Binding of ID Tokens defined in for Token Binding of ID Tokens defined in OpenID Connect Token Bound
OpenID Connect Token Bound Authentication 1.0 [OpenID.TokenBinding]. Authentication 1.0 [OpenID.TokenBinding].
In the OpenID Connect [OpenID.Core] use case, HTTP redirects are used In the OpenID Connect [OpenID.Core] use case, HTTP redirects are used
to pass information between the identity provider and the relying to pass information between the identity provider and the relying
party; this HTTP redirect makes the Token Binding ID of the relying party; this HTTP redirect makes the Token Binding ID of the relying
party available to the identity provider as the Referred Token party available to the identity provider as the Referred Token
Binding ID, information about which is then added to the ID Token. Binding ID, information about which is then added to the ID Token.
No such redirect occurs between the authorization server and the No such redirect occurs between the authorization server and the
protected resource in the access token case; therefore, information protected resource in the access token case; therefore, information
about the Token Binding ID for the TLS connection between the client about the Token Binding ID for the TLS connection between the client
and the protected resource needs to be explicitly communicated by the and the protected resource needs to be explicitly communicated by the
skipping to change at page 7, line 48 skipping to change at page 7, line 25
access token. access token.
This information is passed to the authorization server using the This information is passed to the authorization server using the
Referred Token Binding ID, just as in the ID Token case. The only Referred Token Binding ID, just as in the ID Token case. The only
difference is that the client needs to explicitly communicate the difference is that the client needs to explicitly communicate the
Token Binding ID of the TLS connection between the client and the Token Binding ID of the TLS connection between the client and the
protected resource to the Token Binding implementation so that it is protected resource to the Token Binding implementation so that it is
sent as the Referred Token Binding ID in the request to the sent as the Referred Token Binding ID in the request to the
authorization server. This functionality provided by Token Binding authorization server. This functionality provided by Token Binding
implementations is described in Implementation Considerations of implementations is described in Implementation Considerations of
Token Binding over HTTP [I-D.ietf-tokbind-https], Section 6. Token Binding over HTTP [RFC8473], Section 6.
Note that to obtain this Token Binding ID, the client may need to Note that to obtain this Token Binding ID, the client may need to
establish a TLS connection between itself and the protected resource establish a TLS connection between itself and the protected resource
prior to making the request to the authorization server so that the prior to making the request to the authorization server so that the
Provided Token Binding ID for the TLS connection to the protected Provided Token Binding ID for the TLS connection to the protected
resource can be obtained. How the client retrieves this Token resource can be obtained. How the client retrieves this Token
Binding ID from the underlying Token Binding API is implementation Binding ID from the underlying Token Binding API is implementation
and operating system specific. An alternative, if supported, is for and operating system specific. An alternative, if supported, is for
the client to generate a Token Binding key to use for the protected the client to generate a Token Binding key to use for the protected
resource, use the Token Binding ID for that key, and then later use resource, use the Token Binding ID for that key, and then later use
skipping to change at page 12, line 44 skipping to change at page 12, line 4
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
information SHOULD be represented in the same way that it is in token information SHOULD be represented in the same way that it is in token
bound OpenID Connect ID Tokens [OpenID.TokenBinding]. That bound OpenID Connect ID Tokens [OpenID.TokenBinding]. That
specification defines the new JWT Confirmation Method RFC 7800 specification defines the new JWT Confirmation Method RFC 7800
[RFC7800] member "tbh" (token binding hash) to represent the SHA-256 [RFC7800] member "tbh" (token binding hash) to represent the SHA-256
hash of a Token Binding ID in an ID Token. The value of the "tbh" hash of a Token Binding ID in an ID Token. The value of the "tbh"
member is the base64url encoding of the SHA-256 hash of the Token member is the base64url encoding of the SHA-256 hash of the Token
Binding ID. All all trailing pad '=' characters are omitted from the Binding ID. All trailing pad '=' characters are omitted from the
encoded value and no line breaks, whitespace, or other additional encoded value and no line breaks, whitespace, or other additional
characters are included. characters are included.
The following example demonstrates the JWT Claims Set of an access The following example demonstrates the JWT Claims Set of an access
token containing the base64url encoding of the SHA-256 hash of a token containing the base64url encoding of the SHA-256 hash of a
Token Binding ID as the value of the "tbh" (token binding hash) Token Binding ID as the value of the "tbh" (token binding hash)
element in the "cnf" (confirmation) claim: element in the "cnf" (confirmation) claim:
{ {
"iss": "https://server.example.com", "iss": "https://server.example.com",
skipping to change at page 14, line 49 skipping to change at page 13, line 49
Token Binding of refresh tokens. If omitted, the default value is Token Binding of refresh tokens. If omitted, the default value is
"false". Authorization servers MUST NOT Token Bind refresh tokens "false". Authorization servers MUST NOT Token Bind refresh tokens
issued to a client that does not support Token Binding of refresh issued to a client that does not support Token Binding of refresh
tokens, but MAY reject requests completely from such clients if tokens, but MAY reject requests completely from such clients if
token binding is required by authorization server policy by token binding is required by authorization server policy by
returning an OAuth error response. returning an OAuth error response.
4.2. Token Binding Authorization Server Metadata 4.2. Token Binding Authorization Server Metadata
Authorization servers supporting Token Binding that also support Authorization servers supporting Token Binding that also support
OAuth 2.0 Authorization Server Metadata [OAuth.AuthorizationMetadata] OAuth 2.0 Authorization Server Metadata [RFC8414] use these metadata
use these metadata values to declare their support for Token Binding values to declare their support for Token Binding of access tokens
of access tokens and refresh tokens: and refresh tokens:
as_access_token_token_binding_supported as_access_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the authorization OPTIONAL. Boolean value specifying whether the authorization
server supports Token Binding of access tokens. If omitted, the server supports Token Binding of access tokens. If omitted, the
default value is "false". default value is "false".
as_refresh_token_token_binding_supported as_refresh_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the authorization OPTIONAL. Boolean value specifying whether the authorization
server supports Token Binding of refresh tokens. If omitted, the server supports Token Binding of refresh tokens. If omitted, the
default value is "false". default value is "false".
skipping to change at page 16, line 42 skipping to change at page 15, line 42
&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 14: Authorization Request with PKCE Challenge Figure 14: Authorization Request with PKCE Challenge
5.1.2. Code Verifier 5.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 [RFC8471] is negotiated on the TLS connection between the client and
between the client and the authorization server and the "Sec-Token- the authorization server and the "Sec-Token-Binding" header, as
Binding" header, as defined in Token Binding over HTTP defined in Token Binding over HTTP [RFC8473], is included in the
[I-D.ietf-tokbind-https], is included in the access token request. access token request. The authorization server extracts the Provided
The authorization server extracts the Provided Token Binding ID from Token Binding ID from the header value, hashes it with SHA-256, and
the header value, hashes it with SHA-256, and compares it to the compares it to the "code_challenge" value previously associated with
"code_challenge" value previously associated with the authorization the authorization code. If the values match, the token endpoint
code. If the values match, the token endpoint continues processing continues processing as normal (as defined by OAuth 2.0 [RFC6749]).
as normal (as defined by OAuth 2.0 [RFC6749]). If the values do not If the values do not match, an error response indicating
match, an error response indicating "invalid_grant" MUST be returned. "invalid_grant" MUST be returned.
The "Sec-Token-Binding" header contains sufficient information for The "Sec-Token-Binding" header contains sufficient information for
verification of the authorization code and its association to the verification of the authorization code and its association to the
original authorization request. However, PKCE [RFC7636] requires original authorization request. However, PKCE [RFC7636] requires
that a "code_verifier" parameter be sent with the access token that a "code_verifier" parameter be sent with the access token
request, so the static value "provided_tb" is used to meet that request, so the static value "provided_tb" is used to meet that
requirement and indicate that the Provided Token Binding ID is used requirement and indicate that the Provided Token Binding ID is used
for the verification. for the verification.
5.1.2.1. Example Code Verifier 5.1.2.1. Example Code Verifier
skipping to change at page 18, line 17 skipping to change at page 17, line 17
As defined in Proof Key for Code Exchange [RFC7636], the client sends As defined in Proof Key for Code Exchange [RFC7636], the client sends
the code challenge as part of the OAuth 2.0 Authorization Request the code challenge as part of the OAuth 2.0 Authorization Request
with the two additional parameters: "code_challenge" and with the two additional parameters: "code_challenge" and
"code_challenge_method". "code_challenge_method".
The client must send the authorization request through the browser The client must send the authorization request through the browser
such that the Token Binding ID established between the browser and such that the Token Binding ID established between the browser and
itself is revealed to the authorization server's authorization itself is revealed to the authorization server's authorization
endpoint as the Referred Token Binding ID. Typically, this is done endpoint as the Referred Token Binding ID. Typically, this is done
with an HTTP redirection response and the "Include-Referred-Token- with an HTTP redirection response and the "Include-Referred-Token-
Binding-ID" header, as defined in Token Binding over HTTP Binding-ID" header, as defined in Token Binding over HTTP [RFC8473],
[I-D.ietf-tokbind-https], Section 5.3. Section 5.3.
For this Token Binding method of PKCE, "referred_tb" is used for the For this Token Binding method of PKCE, "referred_tb" is used for the
value of the "code_challenge_method" parameter. value of the "code_challenge_method" parameter.
The value of the "code_challenge" parameter is "referred_tb". The The value of the "code_challenge" parameter is "referred_tb". The
static value for the required PKCE parameter indicates that the static value for the required PKCE parameter indicates that the
authorization code is to be bound to the Referred Token Binding ID authorization code is to be bound to the Referred Token Binding ID
from the Token Binding Message sent in the "Sec-Token-Binding" header from the Token Binding Message sent in the "Sec-Token-Binding" header
of the authorization request. of the authorization request.
skipping to change at page 21, line 20 skipping to change at page 20, line 20
the parameter values and encodings from Section 2.2 of RFC 7523 the parameter values and encodings from Section 2.2 of RFC 7523
[RFC7523] with one exception: the value of the [RFC7523] with one exception: the value of the
"client_assertion_type" is "urn:ietf:params:oauth:client-assertion- "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-
type:jwt-token-bound". type:jwt-token-bound".
The "OAuth Token Endpoint Authentication Methods" registry The "OAuth Token Endpoint Authentication Methods" registry
[IANA.OAuth.Parameters] contains values, each of which specify a [IANA.OAuth.Parameters] contains values, each of which specify a
method of authenticating a client to the authorization server. The method of authenticating a client to the authorization server. The
values are used to indicated supported and utilized client values are used to indicated supported and utilized client
authentication methods in authorization server metadata, such as authentication methods in authorization server metadata, such as
[OpenID.Discovery] and [OAuth.AuthorizationMetadata], and in OAuth [OpenID.Discovery] and [RFC8414], and in OAuth 2.0 Dynamic Client
2.0 Dynamic Client Registration Protocol [RFC7591]. The values Registration Protocol [RFC7591]. The values "private_key_jwt" and
"private_key_jwt" and "client_secret_jwt" are designated by OpenID "client_secret_jwt" are designated by OpenID Connect [OpenID.Core] as
Connect [OpenID.Core] as authentication method values for bearer JWT authentication method values for bearer JWT client authentication
client authentication using asymmetric and symmetric JWS [RFC7515] using asymmetric and symmetric JWS [RFC7515] algorithms respectively.
algorithms respectively. For Token Bound JWT for client For Token Bound JWT for client authentication, this specification
authentication, this specification defines and registers the defines and registers the following authentication method values.
following authentication method values.
private_key_token_bound_jwt private_key_token_bound_jwt
Indicates that client authentication to the authorization server Indicates that client authentication to the authorization server
will occur with a Token Bound JWT, which is signed with a client's will occur with a Token Bound JWT, which is signed with a client's
private key. private key.
client_secret_token_bound_jwt client_secret_token_bound_jwt
Indicates that client authentication to the authorization server Indicates that client authentication to the authorization server
will occur with a Token Bound JWT, which is integrity protected will occur with a Token Bound JWT, which is integrity protected
with a MAC using the octets of the UTF-8 representation of the with a MAC using the octets of the UTF-8 representation of the
skipping to change at page 24, line 9 skipping to change at page 23, line 9
o Client Metadata Name: o Client Metadata Name:
"client_refresh_token_token_binding_supported" "client_refresh_token_token_binding_supported"
o Client Metadata Description: Boolean value specifying whether the o Client Metadata Description: Boolean value specifying whether the
client supports Token Binding of refresh tokens client supports Token Binding of refresh tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.1 of [[ this specification ]] o Specification Document(s): Section 4.1 of [[ this specification ]]
8.2. OAuth Authorization Server Metadata Registration 8.2. OAuth Authorization Server Metadata Registration
This specification registers the following metadata definitions in This specification registers the following metadata definitions in
the IANA "OAuth Authorization Server Metadata" registry established the IANA "OAuth Authorization Server Metadata" registry
by [OAuth.AuthorizationMetadata]: [IANA.OAuth.Parameters] established by [RFC8414]:
8.2.1. Registry Contents 8.2.1. Registry Contents
o Metadata Name: "as_access_token_token_binding_supported" o Metadata Name: "as_access_token_token_binding_supported"
o Metadata Description: Boolean value specifying whether the o Metadata Description: Boolean value specifying whether the
authorization server supports Token Binding of access tokens authorization server supports Token Binding of access tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [[ this specification ]] o Specification Document(s): Section 4.2 of [[ this specification ]]
o Metadata Name: "as_refresh_token_token_binding_supported" o Metadata Name: "as_refresh_token_token_binding_supported"
skipping to change at page 25, line 39 skipping to change at page 24, line 39
o URN: urn:ietf:params:oauth:client-assertion-type:jwt-token-bound o URN: urn:ietf:params:oauth:client-assertion-type:jwt-token-bound
o Common Name: Token Bound JWT for OAuth 2.0 Client Authentication o Common Name: Token Bound JWT for OAuth 2.0 Client Authentication
o Change controller: IESG o Change controller: IESG
o Specification Document: Section 6 of [[ this specification ]] o Specification Document: Section 6 of [[ this specification ]]
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-tokbind-https]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
tokbind-https-17 (work in progress), June 2018.
[I-D.ietf-tokbind-negotiation]
Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
"Transport Layer Security (TLS) Extension for Token
Binding Protocol Negotiation", draft-ietf-tokbind-
negotiation-14 (work in progress), May 2018.
[I-D.ietf-tokbind-protocol]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "The Token Binding Protocol Version 1.0", draft-
ietf-tokbind-protocol-19 (work in progress), May 2018.
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://tools.ietf.org/html/rfc7519>. <http://tools.ietf.org/html/rfc7519>.
[OAuth.AuthorizationMetadata]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth-
discovery-10 (work in progress), March 2017,
<http://tools.ietf.org/html/
draft-ietf-oauth-discovery-10>.
[OpenID.TokenBinding] [OpenID.TokenBinding]
Jones, M., Bradley, J., and B. Campbell, "OpenID Connect Jones, M., Bradley, J., and B. Campbell, "OpenID Connect
Token Bound Authentication 1.0", October 2017, Token Bound Authentication 1.0", October 2017,
<http://openid.net/specs/ <http://openid.net/specs/
openid-connect-token-bound-authentication-1_0-02.html>. openid-connect-token-bound-authentication-1_0-03.html>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
skipping to change at page 27, line 28 skipping to change at page 26, line 5
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges,
"The Token Binding Protocol Version 1.0", RFC 8471,
DOI 10.17487/RFC8471, October 2018,
<https://www.rfc-editor.org/info/rfc8471>.
[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport
Layer Security (TLS) Extension for Token Binding Protocol
Negotiation", RFC 8472, DOI 10.17487/RFC8472, October
2018, <https://www.rfc-editor.org/info/rfc8472>.
[RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and
J. Hodges, "Token Binding over HTTP", RFC 8473,
DOI 10.17487/RFC8473, October 2018,
<https://www.rfc-editor.org/info/rfc8473>.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012, Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
11.2. Informative References 11.2. Informative References
[BCP212] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", [BCP212] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017,
<https://www.rfc-editor.org/info/rfc8252>. <https://www.rfc-editor.org/info/rfc8252>.
skipping to change at page 28, line 11 skipping to change at page 27, line 11
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>. <https://www.rfc-editor.org/info/rfc6755>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following people for their This specification was developed within the OAuth Working Group under
contributions to the specification: Dirk Balfanz, Andrei Popov, the chairmanship of Hannes Tschofenig and Rifaat Shekh-Yusef with
Justin Richer, and Nat Sakimura. Kathleen Moriarty, Eric Rescorla, and Benjamin Kaduk serving as
Security Area Directors. Additionally, the following individuals
contributed ideas, feedback, and wording that helped shape this
specification: Dirk Balfanz, Andrei Popov, Justin Richer, and Nat
Sakimura.
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 ]]
-08
o Update reference to -03 of openid-connect-token-bound-
authentication.
o Update the references to the core token binding specs, which are
now RFCs 8471, 8472, and 8473.
o Update reference to AS metadata, which is now RFC 8414.
o Add chairs and ADs to the Acknowledgements.
-07 -07
o Explicitly state that the base64url encoding of the tbh value o Explicitly state that the base64url encoding of the tbh value
doesn't include any trailing pad characters, line breaks, doesn't include any trailing pad characters, line breaks,
whitespace, etc. whitespace, etc.
o Update to latest references for tokbind drafts and draft-ietf- o Update to latest references for tokbind drafts and draft-ietf-
oauth-discovery. oauth-discovery.
o Update reference to Implementation Considerations in draft-ietf- o Update reference to Implementation Considerations in draft-ietf-
 End of changes. 24 change blocks. 
126 lines changed or deleted 137 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/