Token Binding over HTTP describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.HTTP server issues a Security Token such as a cookie (or similar) to a client, and expects the client to return the Security Tokens at a later time, e.g., in order to authenticate. Binding the Security Tokens to the TLS connection between client and server protects the Security Tokens from misuse since the server can detect if the security token is replayed inappropriately, e.g., over other TLS connections.
See The Token Binding Protocol Section 5 for general guidance regarding binding of security tokens and their subsequent validation.Federated token bindings, on the other hand, allow servers to cryptographically bind Security Tokens to a TLS connection that the client has with a _different_ server than the one issuing the token.
For privacy reasons, clients use different Token Binding key pairs to establish Provided Token Binding IDs with different servers. As a result, a server cannot bind a security token (such as an OAuth Access Token or an OpenID Connect Identity Token) to a TLS connection that the client has with a different server. This is, however, a common requirement in federation scenarios: For example, an Identity Provider (IDP) may wish to issue an identity token to a client and cryptographically bind that token to the TLS connection between the client and a Relying Party.
In this section we describe mechanisms to achieve this. The common idea among these mechanisms is that a server (called the _Token Consumer_ in this document) signals to the client that it should reveal the Provided Token Binding ID that is used between the client and itself, to another server (called the _Token Provider_ in this document). Also common across the mechanisms is how the Token Binding ID is revealed to the Token Provider: The client uses The Token Binding Protocol, and includes a TokenBinding structure in the Sec-Token-Binding HTTP Header Field defined above. What differs between the various mechanisms is _how_ the Token Consumer signals to the client that it should reveal the Token Binding ID to the Token Provider. Below we specify one such mechanism, which is suitable for redirect-based interactions between Token Consumers and Token Providers.
In a Federated Sign-On protocol, an Identity Provider (IDP) issues an identity token to a client, which sends the identity token to a Relying Party to authenticate itself. Examples of this include OpenID Connect (where the Identity Token is called "ID Token") and SAML (where the identity token is a SAML Assertion).
To better protect the security of the Identity Token, the Identity Provider (IDP) may wish to bind the Identity Token to the TLS connection between the client and the Relying Party, thus ensuring that only said client can use the Identity Token: The Relying Party will compare the Token Binding ID in the Identity Token with the Token Binding ID of the TLS connection between it and the client.
More Information#There might be more information for this subject on one of the following:
- OAuth 2.0 Token Binding
- RFC 8473
- Web Blog_blogentry_170816_1