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 | + | * 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== | ==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. | ||
| + | * The most commonly accessed protected resource is [[User Private Information]], which has had low value in the view of the web sites heretofore. | ||
| + | |||
==Solutions== | ==Solutions== | ||
* Add a cryptographic binding between the token a some credential that is known to be in the secured possession of the [[Subject]]] | * 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. | ||
==References== | ==References== | ||
[[Category:Authorization]] | [[Category:Authorization]] | ||
Revision as of 13:30, 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 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.
