Difference between revisions of "Sender Constrained Token"
From MgmtWiki
(→Context) |
|||
| Line 3: | Line 3: | ||
==Context== | ==Context== | ||
* [[Bearer Token]]s have proven to be susceptible to reuse by unauthorized parties. | * [[Bearer Token]]s have proven to be susceptible to reuse by unauthorized parties. | ||
| + | * In common [[OpenID Connect]] code flows, the response to the user's consent is used by the relying party (confusingly called the user's clent) to request an access_token (which is typcially a [[Bearer Token]]) and a refresh_token (which is typically a [[Sender Constrained Token]]. | ||
| + | |||
==Problems== | ==Problems== | ||
* [[Bearer Token]]s have proven to be susceptible to reuse by unauthorized parties. | * [[Bearer Token]]s have proven to be susceptible to reuse by unauthorized parties. | ||
Revision as of 13:27, 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
- Bearer Tokens have proven to be susceptible to reuse by unauthorized parties.
- In common OpenID Connect code flows, the response to the user's consent is used by the relying party (confusingly called the user's clent) to request an access_token (which is typcially 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.
Solutions
- Add a cryptographic binding between the token a some credential that is known to be in the secured possession of the Subject]
