Difference between revisions of "Bound Token"

Latest revision as of 13:33, 18 December 2019

Full Title or Meme

A data structure that passes strongly purpose-bound Authorization grants to a Resource server.

Context

RFC 6750 "The OAuth 2.0 Authorization Framework: Bearer Token Usage" defines the Bearer Token.

Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.

The Bound Token is specifically designed to overcome several of the problems of a Bearer Token.

User Cases

• A user want to allow a Web Site to access some Resource (often data, or even User Private Information) that they own (or control access). The Web Site (called the Client in OAuth 2.0) needs to prove to an Authorization Server that they have User Consent to acquire an Access Code from the Authorization Server. Then that service will provide the Client with the Access Code. In cases where the Resource is a high value target (e.g. a bank account) the Resource Server demands more security than that offered by a Bearer Token.

Problem

• Attacks against Bearer Tokens are common now but the existing solutions try to overcome the limitations rather than by opposing, end them.
• Distributed Identity has the feature of collecting User Claims from a variety of sources, not all of which have a relationship with the OP used to Authenticate the User.

Problems left over with Bearer Tokens

• Any party in possession of a Bearer Token can use it to get access to the associated Resources. To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.
• Bearer Tokens are valid only for as short time as possible. These tokens work like passwords, and if intercepted can be used immediately by an attacker. Therefore the OAuth2 (with bearer token) specification requires that all communication takes place over SSL - since no cryptography is built into the specification. Typically access tokens have a short validity, which can be refreshed with a "refresh token" which has longer validity but is only transferred when the initial bearer token is received by the consumer, and when a bearer token is refreshed.
• Token reuse: OAuth 2.0 or OpenID Connect use of bearer tokens raises the risk of token theft. For years architects have been waiting for Token Binding to get ratified so there would be transparent mechanism to close this gap. As feature gets dropped from Chrome, any enterprise use case doesn't go away and only Microsoft Browsers support the feature.
• Bearer Tokens Considered Harmful is a paper that discusses the limitations of Channel Binding or other half-way measures to fix a broken security measure.

Solution

• While there are other solutions to the vulnerabilities of the Bearer Token (e.g. Token Binding. This solution is proposed as a simpler, cleaner solution.
• Since this solution was proposed the Sender Constrained Token has been described, but not defined in any canonical manner.
• This wiki page creates a new type of structure to address the problems noted above. It is currently just a draft proposal to get the conversation about the complete solution started.

Structure

Unlike the Bearer Token, this proposal is for a structured token that carries binding with it. It is expected that the following will apply:

1. JWT - preferably (or mandatory?) JWS signed by the issuer
2. JOSE - whenever private information is included in the token it must be encrypted with the public key of the receiver (aka the aud).

Identifier

All trusted entities need to be identified. In the current federation document it is proposed that the the SID, IIS, etc. be a URL rather than a URI, since we know what a URL is, but a URI seems to be too unbounded for practical use. As a tentative solution we propose a new schema, the trusted ID or tid://.

Note that the most important attribute of a TID that offers up metadata is a URL pointing to the authority. But in the case of a native app, the URL might need to be somewhere else to be useful. Of course such a url could include fragment or sub-directory components that identified the particular instance of the app.

Google Instance Identity

https://cloud.google.com/compute/docs/instances/verifying-instance-identity

Payload

The payload contains the aud audience claim. If the instance specified format=full when it requested the token, the payload also includes claims about the virtual machine instance and its project.

{
   "iss": "[TOKEN_ISSUER]",
   "iat": [ISSUED_TIME],
   "exp": [EXPIRED_TIME],
   "aud": "[AUDIENCE]",
   "sub": "[SUBJECT]",
   "azp": "[AUTHORIZED_PARTY]",
   "google": {
    "compute_engine": {
      "project_id": "[PROJECT_ID]",
      "project_number": [PROJECT_NUMBER],
      "zone": "[ZONE]",
      "instance_id": [INSTANCE_ID],
      "instance_name": "[INSTANCE_NAME]"
      "instance_creation_timestamp": [CREATION_TIMESTAMP]
    }
  }
}

where:

• [TOKEN_ISSUER] is a URL identifying who issued the token. For Compute Engine, this value is https://accounts.google.com.
• [ISSUED_TIME] is a unix timestamp indicating when the token was issued. This value updates each time the instance requests a token from the metadata server.
• [EXPIRED_TIME] is a unix timestamp indicating when the token expires.
• [AUDIENCE] is the unique URI agreed upon by both the instance and the system verifying the instance's identity. For example, the audience could be a URL for the connection between the two systems.
• [SUBJECT] is the subject of the token, which is the unique ID for the service account that you associated with your instance.
• [AUTHORIZED_PARTY] is the party to which the ID Token was issued which is the unique ID for the service account that you associated with your instance.
• [PROJECT_ID] is the ID for the project where you created the instance.
• [PROJECT_NUMBER] is the unique number for the project where you created the instance.
• [ZONE] is the zone where the instance is located.
• [INSTANCE_ID] is the unique ID for the instance to which this token belongs. This ID is unique and never reused.
• [INSTANCE_NAME] is the name of the instance to which this token belongs. This name can be reused by several instances over time, so use the instance_id value to identify a unique instance ID.
• [CREATION_TIMESTAMP] is a unix timestamp indicating when you created the instance.

Reference

• Bound Tokens, unlike Late Binding Tokens or Bearer Tokens cannot be re-purposed after they are created.