Difference between revisions of "Bound Token"
(→Structure) |
(→Solution) |
||
| Line 33: | Line 33: | ||
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. | 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 | ||
==Reference== | ==Reference== | ||
Revision as of 13:01, 5 November 2018
Contents
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 (call 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.
- 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:
- JWT - preferably (or mandatory?) JWS signed by the issuer
- 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
Reference
- Bound Tokens, unlike Late Binding Tokens or Bearer Tokens cannot be re-purposed after they are created.
