OAuth 2.0 Token BindingMicrosoftmbj@microsoft.comhttp://self-issued.info/Ping Identityve7jtb@ve7jtb.comhttp://www.thread-safe.com/Ping Identitybrian.d.campbell@gmail.comhttps://twitter.com/__b_cGoogle1600 Amphitheatre PkwyMountain ViewCA94043USAwdenniss@google.comhttp://wdenniss.com/
Security
OAuth Working GroupOAuthToken BindingProof-of-PossessionPoP
This specification enables OAuth 2.0 implementations to apply
Token Binding to Access Tokens, Authorization Codes, and Refresh Tokens.
This cryptographically binds these tokens to a client's Token Binding 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 protects these tokens
from man-in-the-middle and token export and replay attacks.
This specification enables OAuth 2.0 implementations to apply
Token Binding (
TLS Extension for Token Binding Protocol Negotiation,
The Token Binding Protocol Version 1.0
and Token Binding over HTTP)
to Access Tokens, Authorization Codes, and Refresh Tokens.
This cryptographically binds these tokens to a client's Token Binding 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 protects these tokens
from man-in-the-middle and token export and replay attacks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
This specification uses the terms "Access Token", "Authorization Code",
"Authorization Endpoint", "Authorization Server",
"Client", "Protected Resource", "Refresh Token",
and "Token Endpoint"
defined by OAuth 2.0,
the terms "Claim" and "JSON Web Token (JWT)"
defined by JSON Web Token (JWT),
the term "User Agent" defined by RFC 7230,
and
the terms "Provided", "Referred", "Token Binding" and "Token Binding ID"
defined by Token Binding over HTTP.
Token Binding of refresh tokens is a straightforward first-party scenario,
applying term "first-party" as used in
Token Binding over HTTP.
It cryptographically binds the refresh token to the client's Token Binding key
pair, possession of which is proven on the TLS connections between the
client and the token endpoint.
This case is straightforward because the refresh token is
both retrieved by the client from the token endpoint
and sent by the client to the token endpoint.
Unlike the federated scenarios described in
Section 4 (Federation Use Cases) of
Token Binding over HTTP
and the access token case described in the next section,
only a single TLS connection is involved in the refresh token case.
Token Binding a refresh token requires that the authorization server do two things.
First, when refresh token is sent to the client, the authorization server needs to
remember the Provided Token Binding ID
and remember its association with the issued refresh token.
Second, when a token request containing a refresh token is received at the token endpoint,
the authorization server needs to verify that
the Provided Token Binding ID for the request
matches the remembered Token Binding ID associated with the refresh token.
If the Token Binding IDs do not match,
the authorization server should return an error in response to the request.
How the authorization server remembers the association
between the refresh token and the Token Binding ID
is an implementation detail that beyond the scope of this specification.
Some authorization servers will choose to store the Token Binding ID
(or a cryptographic hash of it, such a SHA-256 hash )
in the refresh token itself, provided it is integrity-protected,
thus reducing the amount of state to be kept by the server.
Other authorization servers will add the Token Binding ID value (or a hash of it)
to an internal data structure also containing other information about the refresh token,
such as grant type information.
These choices make no difference to the client, since the refresh token is opaque to it.
This section provides an example of what the interactions around a
Token Bound refresh token might look like, along with some details of
the involved processing. Token Binding of refresh tokens is most useful
for native application clients so the example has protocol elements typical
of a native client flow.
Extra line breaks in all examples are for
display purposes only.
A native application client makes the following access token request with an
authorization code using a TLS connection where Token
Binding has been negotiated. A PKCE code_verifier is
included because use of PKCE is considered best practice for native
application clients .
The base64url-encoded representation of
the exported keying material (EKM) from that TLS connection is
p6ZuSwfl6pIe8es5KyeV76T4swZmQp0_awd27jHfrbo, which is
needed to validate the Token Binding Message.
A refresh token is issued in response to the prior request. Although it
looks like a typical response to the client, the authorization server
has bound the refresh token to the Provided Token Binding ID from the
encoded Token Binding message in the Sec-Token-Binding
header of the request. In this example,
that binding is done by saving the Token Binding
ID alongside other information about the refresh token in some server
side persistent storage.
The base64url-encoded representation of that Token Binding ID is
AgBBQGto7hHRR0Y5nkOWqc9KNfwW95dEFmSI_tCZ_Cbl7LWlt6Xjp3DbjiDJavGFiKP2HV_2JSE42VzmKOVVV8m7eqA.
When the access token expires, the client requests a new one with
a refresh request to the token endpoint. In this example, the request is made on a new
TLS connection so the EKM (base64url-encoded:
va-84Ukw4Zqfd7uWOtFrAJda96WwgbdaPDX2knoOiAE)
and signature in the Token Binding Message are different than in the
initial request.
However, because the Token Binding ID is long-lived and may span multiple TLS
sessions and connections, it is the same as in the 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 a new access token.
Token Binding for access tokens cryptographically binds the access token
to the client's Token Binding key
pair, possession of which is proven on the TLS connections between the
client and the protected resource.
Token Binding is applied to access tokens in a similar manner to that
described in Section 4 (Federation Use Cases) of
Token Binding over HTTP.
It also builds upon the mechanisms for Token Binding of ID Tokens defined in
OpenID Connect Token Bound Authentication 1.0.
In the OpenID Connect use case,
HTTP redirects are used to pass information
between the identity provider and the relying party;
this HTTP redirect makes the Token Binding ID of the relying party
available to the identity provider as the Referred Token Binding ID,
information about which is then added to the ID Token.
No such redirect occurs between the authorization server and the protected resource
in the access token case;
therefore, information about the Token Binding ID for the TLS connection
between the client and the protected resource needs to be explicitly
communicated by the client to the authorization server to achieve Token Binding
of the access token.
This information is passed to the authorization server
using the Referred Token Binding ID, just as in the ID Token case.
The only difference is that the client needs to explicitly
communicate the Token Binding ID of
the TLS connection between the client and the protected resource
to the Token Binding implementation so that it is sent as
the Referred Token Binding ID in the request to the authorization server.
This functionality provided by Token Binding implementations is described in
Section 5 (Implementation Considerations) of
Token Binding over HTTP.
Note that to obtain this Token Binding ID,
the client may need to establish a TLS connection between itself and the protected resource
prior to making the request to the authorization server so that the Provided Token Binding ID
for the TLS connection to the protected resource can be obtained.
How the client retrieves this Token Binding ID
from the underlying Token Binding API is implementation and operating system specific.
An alternative, if supported, is for 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 that key when the TLS connection to the protected resource is established.
For access tokens returned directly from the authorization endpoint,
such as with the implicit grant defined in Section 4.2 of
OAuth 2.0, the Token Binding ID of
the client's TLS channel to the protected resource is sent with
the authorization request as the Referred Token Binding ID in the
Sec-Token-Binding header,
and is used to Token Bind the access token.
Upon receiving the Referred Token Binding ID
in an authorization request,
the authorization server associates (Token Binds) the ID with the access token
in a way that can be accessed by the protected resource.
Such methods include embedding the Referred Token Binding ID
(or a cryptographic hash of it) in the issued access token itself,
possibly using the syntax described in ,
or through token introspection as described in .
The method for associating the referred token binding ID with the access token
is determined by the authorization server and the protected resource,
and is beyond the scope for this specification.
This section provides an example of what the interactions around a
Token Bound access token issued from the authorization endpoint might look
like, along with some details of the involved processing.
Extra line breaks in all examples are for display purposes only.
The client directs the user-agent to make the following HTTP request to the
authorization endpoint. It is a typical authorization request that,
because Token Binding was negotiated on the underlying TLS connection and the
user-agent was signaled to reveal the Referred Token Binding, also includes
the Sec-Token-Binding header with a Token Binding Message
that contains both a Provided and Referred Token Binding. The base64url-encoded EKM
from the TLS connection over which the request was made is
jI5UAyjs5XCPISUGQIwgcSrOiVIWq4fhLVIFTQ4nLxc.
The authorization
server issues an access token and delivers it to the client
by redirecting the user-agent with the following HTTP response:
The access token is bound to the Referred Token Binding ID from
the authorization request, which when
represented as a JWT, as described in ,
contains the SHA-256 hash of the
Token Binding ID as the value of the tbh (token binding hash)
member of the cnf (confirmation) claim. The confirmation claim
portion of the JWT Claims Set is shown in the following figure.
For access tokens returned from the token endpoint,
the Token Binding ID of the client's TLS channel to the protected resource
is sent as the Referred Token Binding ID in the Sec-Token-Binding header,
and is used to Token Bind the access token.
This applies to all the grant types from OAuth 2.0 using the token endpoint,
including, but not limited to the refresh and authorization code token requests,
as well as some extension grants, such as JWT assertion authorization grants .
Upon receiving the Referred Token Binding ID
in a token request,
the authorization server associates (Token Binds) the ID with the access token
in a way that can be accessed by the protected resource.
Such methods include embedding the Referred Token Binding ID
(or a cryptographic hash of it) in the issued access token itself,
possibly using the syntax described in ,
or through token introspection as described in .
The method for associating the referred token binding ID with the access token
is determined by the authorization server and the protected resource,
and is beyond the scope for this specification.
Note that if the request results in a new refresh token being generated,
it can be Token bound using the Provided Token Binding ID,
per .
This section provides an example of what the interactions around a
Token Bound access token issued from the token endpoint might look
like, along with some details of the involved processing.
Extra line breaks in all examples are for display purposes only.
The client makes an access token request to the token endpoint
and includes the Sec-Token-Binding header
with a Token Binding Message
that contains both Provided and Referred Token Binding IDs.
The Provided Token Binding ID is used to validate the token binding of the refresh token
in the request (and to Token Bind a new refresh token, if one is issued),
and the Referred Token Binding ID is used to Token Bind the access token that is generated.
The base64url-encoded EKM
from the TLS connection over which the access token request was made is
4jTc5e1QpocqPTZ5l6jsb6pRP18IFKdwwPvasYjn1-E.
The authorization
server issues an access token bound to the
Referred Token Binding ID and delivers it in a response the client.
The access token is bound to the Referred Token Binding ID of the
access token request, which when
represented as a JWT, as described in ,
contains the SHA-256 hash of the
Token Binding ID as the value of the tbh (token binding hash)
member of the cnf (confirmation) claim. The confirmation claim portion
of the JWT Claims Set of the access token is shown in the following figure.
Upon receiving a token bound access token, the protected resource validates the binding
by comparing the Provided Token Binding ID
to the Token Binding ID for the access token.
Alternatively, cryptographic hashes of these Token Binding ID values can be compared.
If the values do not match, the resource access attempt MUST be rejected with an error.
For example, a protected resource request using the access token from
would look something like the following.
The base64url-encoded EKM
from the TLS connection over which the request was made is
7LsNP3BT1aHHdXdk6meEWjtSkiPVLb7YS6iHp-JXmuE.
The protected resource validates the binding
by comparing the Provided Token Binding ID from the
Sec-Token-Binding header to the token binding hash
confirmation of the access token. Extra line breaks in the example are for
display purposes only.
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 bound OpenID Connect ID Tokens
.
That specification defines the new JWT Confirmation Method
RFC 7800
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 member is the
base64url encoding of the SHA-256 hash of the Token Binding ID.
The following example demonstrates the JWT Claims Set of an access token
containing the base64url encoding of the SHA-256 hash of a Token Binding ID
as the value of the tbh (token binding hash)
element in the cnf (confirmation) claim:
OAuth 2.0 Token Introspection defines a
method for a protected resource to query
an authorization server about the active state of an
access token as well as to determine meta-information about the token.
For a token bound access token, the hash of the
Token Binding ID to which the token is bound
is conveyed to the protected resource as meta-information
in a token introspection response. The hash is conveyed using same structure as the
token binding hash confirmation method, described in
, as a top-level member of the introspection response JSON.
The protected resource compares
that token binding hash to a hash of the provided Token Binding ID
and rejects the request, if they do not match.
The following is an example of an introspection response for an active token bound access token with
an tbh token binding hash confirmation method.
There are two variations for Token Binding of an authorization code.
One is appropriate for native application clients and the other for web server clients.
The nature of where the various components reside for the different client types
demands different methods of Token Binding the authorization code so that it is bound to a Token Binding
key on the end user's device. This ensures that a lost or stolen authorization code cannot be successfully
utilized from a different device.
For native application clients, the code is bound to a Token Binding key pair
that the native client itself possesses.
For web server clients, the code is bound to a Token Binding key pair on the end user's
browser.
Both variations utilize the extensible framework of
Proof Key for Code Exchange (PKCE), which enables the
client to show possession of a certain key when exchanging the authorization code for tokens.
The following subsections individually describe each of the two PKCE methods respectively.
This section describes a PKCE method suitable for native application clients
that cryptographically binds the authorization code to a Token Binding key pair on the client,
which the client proves possession of on the TLS connection during the access token request
containing the authorization code.
The authorization code is bound to the Token Binding ID that the native application
client uses to resolve the authorization code at the token endpoint. This binding ensures that
the client that made the authorization request is the same client that
is presenting the authorization code.
As defined in Proof Key for Code Exchange,
the client sends the code challenge as part of the OAuth 2.0
authorization request with the two additional parameters:
code_challenge and code_challenge_method.
For this Token Binding method of PKCE, TB-S256
is used as the value of the code_challenge_method parameter.
The value of the code_challenge parameter is the base64url encoding
(per Section 5 of with all trailing padding ('=')
characters omitted and without the inclusion of any line breaks or whitespace)
of the SHA-256 hash of the Provided Token Binding ID
that the client will use when calling the authorization server's
token endpoint. Note that, prior to making the authorization request, the client may need to
establish a TLS connection between itself and the authorization server's token endpoint in order to establish
the appropriate Token Binding ID.
When the authorization server issues the authorization code in the authorization
response, it associates the code challenge and method values
with the authorization code so they can be verified later when the authorization code is
presented in the access token request.
For example, a native application client sends an authorization request by
sending the user's browser to the authorization endpoint. The resulting HTTP
request looks something like the following (with extra line breaks for display purposes only).
Upon receipt of the authorization code, the client sends the access
token request to the token endpoint. The Token Binding Protocol
is negotiated on the TLS connection between the client and the authorization server and the
Sec-Token-Binding header, as defined in
Token Binding over HTTP,
is included in the access token request. The authorization server extracts the
Provided Token Binding ID from the header value, hashes it with SHA-256, and compares
it to the code_challenge value previously associated with the authorization code.
If the values match, the token endpoint continues processing
as normal (as defined by OAuth 2.0). If the values do not
match, an error response indicating "invalid_grant" MUST be returned.
The Sec-Token-Binding header contains sufficient information for verification of the
authorization code and its association to the original authorization request. However, PKCE
requires that a code_verifier parameter be
sent with the access token request, so the static value provided_tb is used to meet that
requirement and indicate that the Provided Token Binding ID is used for the verification.
An example access token request, correlating to the authorization request in the previous example,
to the token endpoint over a TLS connection for which
Token Binding has been negotiated would look like the following (with extra line breaks for display purposes only).
The base64url-encoded EKM
from the TLS connection over which the request was made is
pNVKtPuQFvylNYn000QowWrQKoeMkeX9H32hVuU71Bs.
This section describes a PKCE method suitable for web server clients,
which cryptographically binds the authorization code to a Token Binding
key pair on the browser.
The authorization code is bound to the Token Binding ID that the browser
uses to deliver the authorization code to a web server client, which is sent to the
authorization server as the Referred Token Binding ID during the authorization request.
The web server client
conveys the Token Binding ID to the authorization server when making
the access token request containing the authorization code.
This binding ensures that the authorization code cannot successfully be played or replayed to the
web server client from a different browser than the one that made the authorization request.
As defined in Proof Key for Code Exchange,
the client sends the code challenge as part of the OAuth 2.0
Authorization Request with the two additional parameters:
code_challenge and code_challenge_method.
The client must send the authorization request through the browser such that
the Token Binding ID established between the browser and itself is revealed
to the authorization server's authorization endpoint as the Referred Token Binding ID.
Typically, this is done with an HTTP redirection response and the
Include-Referred-Token-Binding-ID header, as defined in
Section 5.3 of Token Binding over HTTP.
For this Token Binding method of PKCE, referred_tb
is used for the value of the code_challenge_method parameter.
The value of the code_challenge parameter is
referred_tb. The static value for the required PKCE
parameter indicates that the authorization code is to be bound to the
Referred Token Binding ID from the Token Binding Message sent in the
Sec-Token-Binding header of the authorization request.
When the authorization server issues the authorization code in the authorization
response, it associates the Token Binding ID (or hash thereof) and code challenge method
with the authorization code so they can be verified later when the authorization code is
presented in the access token request.
For example, the web server client sends the authorization request by
redirecting the browser to the authorization endpoint. That HTTP redirection
response looks like the following (with extra line breaks for display purposes only).
The redirect includes the Include-Referred-Token-Binding-ID
response header field that signals to the user-agent that it
should reveal, to the authorization server, the Token Binding ID used
on the connection to the web server client. The resulting HTTP request to the
authorization server looks something like the following
(with extra line breaks for display purposes only). The base64url-encoded EKM
from the TLS connection over which the request was made is
7gOdRzMhPeO-1YwZGmnVHyReN5vd2CxcsRBN69Ue4cI.
The web server client receives the authorization code from the browser and
extracts the Provided Token Binding ID from the
Sec-Token-Binding header of the request.
The client sends the base64url-encoded
(per Section 5 of with all trailing padding ('=')
characters omitted and without the inclusion of any line breaks or whitespace)
Provided Token Binding ID as the value of the
code_verifier parameter in the access token request
to the authorization server's token endpoint.
The authorization server compares the value of the
code_verifier parameter
to the Token Binding ID value previously associated with the authorization code.
If the values match, the token endpoint continues processing
as normal (as defined by OAuth 2.0). If the values do not
match, an error response indicating "invalid_grant" MUST be returned.
Continuing the example from the previous section, the authorization server
sends the code to the web server client by redirecting the browser to
the client's redirect_uri, which results in the browser
making a request like the following (with extra line breaks for display purposes only)
to the web server client over a TLS channel for which Token Binding has been established.
The base64url-encoded EKM
from the TLS connection over which the request was made is
EzW60vyINbsb_tajt8ij3tV6cwy2KH-i8BdEMYXcNn0.
The web server client takes the Provided Token Binding ID from the
above request from the browser and sends it, base64url encoded, to the
authorization server in the code_verifier
parameter of the authorization code grant type request.
Extra line breaks in the example request are for display purposes only.
Many OAuth implementations will be deployed in situations in which
not all participants support Token Binding.
Any of combination of the client, the authorization server, the protected resource,
and the user agent may not yet support Token Binding,
in which case it will not work end-to-end.
It is a context-dependent deployment choice whether to allow
interactions to proceed in which Token Binding is not supported
or whether to treat Token Binding failures at any step as fatal errors.
Particularly in dynamic deployment environments in which End Users have choices
of clients, authorization servers, protected resources, and/or user agents,
it is RECOMMENDED that authorizations using one or more components
that do not implement Token Binding be allowed to successfully proceed.
This enables different components to be upgraded to supporting Token Binding
at different times, providing a smooth transition path for
phasing in Token Binding.
However, when Token Binding has been performed,
any Token Binding key mismatches MUST be treated as fatal errors.
If all the participants in an authorization interaction
support Token Binding and yet one or more of them does not use it,
this is likely evidence of a downgrade attack.
In this case, the authorization SHOULD be aborted with an error.
For instance, if the protected resource knows that the authorization server and the user agent both
support Token Binding and yet the access token received does not contain
Token Binding information, this is almost certainly a sign of an attack.
The authorization server, client, and protected resource
can determine whether the others support Token Binding
using the metadata values defined in the next section.
They can determine whether the user agent supports Token Binding
by whether it negotiated Token Binding for the TLS connection.
Clients supporting Token Binding that also support
the OAuth 2.0 Dynamic Client Registration Protocol
use these metadata values to declare their support for Token Binding
of access tokens and refresh tokens:
OPTIONAL.
Boolean value specifying whether the client supports Token Binding of access tokens.
If omitted, the default value is false.
OPTIONAL.
Boolean value specifying whether the client supports Token Binding of refresh tokens.
If omitted, the default value is false.
Authorization servers supporting Token Binding that also support
OAuth 2.0 Authorization Server Metadata
use these metadata values to declare their support for Token Binding
of access tokens and refresh tokens:
OPTIONAL.
Boolean value specifying whether the authorization server supports Token Binding of access tokens.
If omitted, the default value is false.
OPTIONAL.
Boolean value specifying whether the authorization server supports Token Binding of refresh tokens.
If omitted, the default value is false.
Protected resources supporting Token Binding that also support
the OAuth 2.0 Protected Resource Metadata
use this metadata value to declare their support for Token Binding
of access tokens:
OPTIONAL.
Boolean value specifying whether the protected resource supports Token Binding of access tokens.
If omitted, the default value is false.
If a refresh request is received by the authorization server containing a
Referred Token Binding ID and the refresh token in the request
is not itself token bound, then it is not clear that token binding
the access token adds significant value.
This situation should be considered an open issue for discussion by the working group.
This specification registers the following client metadata definitions
in the IANA "OAuth Dynamic Client Registration Metadata" registry
established by :
Client Metadata Name: client_access_token_token_binding_supported
Client Metadata Description:
Boolean value specifying whether the client supports Token Binding of access tokens
Change Controller: IESG
Specification Document(s): of [[ this specification ]]
Client Metadata Name: client_refresh_token_token_binding_supported
Client Metadata Description:
Boolean value specifying whether the client supports Token Binding of refresh tokens
Change Controller: IESG
Specification Document(s): of [[ this specification ]]
This specification registers the following metadata definitions
in the IANA "OAuth Authorization Server Metadata" registry
established by :
Metadata Name: as_access_token_token_binding_supported
Metadata Description:
Boolean value specifying whether the authorization server supports Token Binding of access tokens
Change Controller: IESG
Specification Document(s): of [[ this specification ]]
Metadata Name: as_refresh_token_token_binding_supported
Metadata Description:
Boolean value specifying whether the authorization server supports Token Binding of refresh tokens
Change Controller: IESG
Specification Document(s): of [[ this specification ]]
This specification registers the following client metadata definition
in the IANA "OAuth Protected Resource Metadata" registry
established by :
Resource Metadata Name: resource_access_token_token_binding_supported
Resource Metadata Description:
Boolean value specifying whether the protected resource supports Token Binding of access tokens
Change Controller: IESG
Specification Document(s): of [[ this specification ]]
This specification requests registration of the following
Code Challenge Method Parameter Names
in the IANA "PKCE Code Challenge Methods" registry
established by .
Code Challenge Method Parameter Name: TB-S256Change controller: IESGSpecification document(s): of [[ this specification ]]Code Challenge Method Parameter Name: referred_tbChange controller: IESGSpecification document(s): of [[ this specification ]]OpenID Connect Token Bound Authentication 1.0MicrosoftPing IdentityPing IdentityOAuth 2.0 Authorization Server MetadataMicrosoftmbj@microsoft.comhttp://self-issued.info/Nomura Research Institute, Ltd.n-sakimura@nri.co.jphttp://nat.sakimura.org/Ping Identityve7jtb@ve7jtb.comhttp://www.thread-safe.com/OAuth 2.0 Protected Resource MetadataMicrosoftmbj@microsoft.comhttp://self-issued.info/Oraclephil.hunt@yahoo.comJSON Web Token (JWT)MicrosoftPing IdentityNomura Research Institute, Ltd.Secure Hash Standard (SHS)National Institute of Standards and
TechnologyOAuth ParametersIANA
The authors would like to thank the following people for their contributions to the specification:
Dirk Balfanz,
Andrei Popov,
Justin Richer,
and
Nat Sakimura.
What should we do in the case that a refresh request for a token bound access token
is received when the refresh token used in the request is not token bound?
Currently the only way to request a token bound access token is via the referred token binding.
By definition the referred token binding also comes with the provided token binding and the provided token binding
is what is used to bind the refresh token. However,
web server clients will typically be distributed/clustered and very likely will not
want to, or be capable of, dealing with token bound refresh tokens. Such clients will have
credentials established with the AS for authenticating to the token endpoint and refresh tokens
are already bound to the client. So token binding the refresh tokens doesn't add much, if anything, in this case.
But accessing private token binding keys in a distributed system will be cumbersome or even impossible.
Tracking and properly utilizing the association of a token binding key with each individual
refresh token would also be exceptionally cumbersome (whereas client credentials are
for the client and decoupled from individual refresh tokens) but without some such mechanism
the token binding key cannot be changed without implicitly invalidating all the bound refresh tokens
the web server client has stored for that AS.
It seems necessary to provide some mechanism for a client to opt-out of having refresh tokens
token bound while still allowing for token binding of access tokens.
Should the scope of this document include standardization or guidance on token binding
of JWT Client Authentication and/or Authorization Grants from RFC 7523?
The Metadata and
what can and cannot be reliably inferred from it
need additional evaluation and work.
OAuth 2.0 Protected Resource Metadata
is no longer a going concern, but is currently referenced herein.
Boolean values do not adequately convey Token Binding support, as different components may support
different key parameters types.
And successful negotiation likely doesn't provide the application layer info about
all the supported key parameters types but rather just the one that was negotiated.
[[ to be removed by the RFC Editor before publication as an RFC ]]
-04
Define how to convey token binding information of an access token via
RFC 7662 OAuth 2.0 Token Introspection (note that the Introspection Response
Registration request for cnf/Confirmation is in
https://tools.ietf.org/html/draft-ietf-oauth-mtls-02#section-4.3 which will
likely be published and registered prior to this document).
Minor editorial fixes.
Added an open issue about needing to allow for web server clients to opt-out of having refresh tokens
bound while still allowing for binding of access tokens
(following from mention of the problem on slide 16 of the presentation
from Chicago https://www.ietf.org/proceedings/98/slides/slides-98-oauth-sessb-token-binding-00.pdf).
-03
Fix a few mistakes in and around the examples that were noticed preparing the slides for IETF 98 Chicago.
-02
Added a section on Token Binding for authorization codes with one variation for native clients and one for web server clients.Updated language to reflect that the binding is to the token binding key pair and that proof-of-possession of that key is done on the TLS connection.Added a bunch of examples.Added a few Open Issues so they are tracked in the document.Updated the Token Binding and OAuth Metadata references.Added William Denniss as an author.
-01
Changed Token Binding for access tokens to use the Referred Token Binding ID,
now that the Implementation Considerations in the Token Binding HTTPS specification
make it clear that implementations will enable using the Referred Token Binding ID.
Defined Protected Resource Metadata value.
Changed to use the more specific term "protected resource" instead of "resource server".
-00
Created the initial working group version from draft-jones-oauth-token-binding-00.