Difference between revisions of "Sender Constrained Token"
From MgmtWiki
(→Context) |
|||
| Line 2: | Line 2: | ||
A [[Sender Constrained Token]] can be considered to be a token there the [[Subject]] presenting the token can prove possession of some credential that is bound to the token. | A [[Sender Constrained Token]] can be considered to be a token there the [[Subject]] presenting the token can prove possession of some credential that is bound to the token. | ||
==Context== | ==Context== | ||
| − | |||
* In common [[OpenID Connect]] code flows, the response to the user's consent is used by the relying party (confusingly called the user's client) to request an access_token (which is typically a [[Bearer Token]]) and a refresh_token (which is typically a [[Sender Constrained Token]]. | * In common [[OpenID Connect]] code flows, the response to the user's consent is used by the relying party (confusingly called the user's client) to request an access_token (which is typically a [[Bearer Token]]) and a refresh_token (which is typically a [[Sender Constrained Token]]. | ||
Revision as of 13:31, 18 December 2019
Full Title or Meme
A Sender Constrained Token can be considered to be a token there the Subject presenting the token can prove possession of some credential that is bound to the token.
Context
- In common OpenID Connect code flows, the response to the user's consent is used by the relying party (confusingly called the user's client) to request an access_token (which is typically a Bearer Token) and a refresh_token (which is typically a Sender Constrained Token.
Problems
- Bearer Tokens have proven to be susceptible to reuse by unauthorized parties.
- The most commonly accessed protected resource is User Private Information, which has had low value in the view of the web sites heretofore.
Solutions
- Add a cryptographic binding between the token a some credential that is known to be in the secured possession of the Subject]
- For any scenario where the protect resource has high value, a Sender Constrained Token is the more secure solution.
