Sender Constrained Token

From MgmtWiki
Jump to: navigation, search

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.
  • On 2019-12-09, 1 & 1 Telecommunications was fined €9.55 million ($10.6 million) by Germany's Federal Commissioner for Data Protection and Freedom of Information, or BfDI, for its failure to put in place "sufficient technical and organizational measures" to protect customer data in its call center environments.[1] Perhaps it is time to increase security of user data?

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.

References

  1. Matthew Schwartz, GDPR Violation: German Privacy Regulator Fines 1&1 Telecom (2019-12-09) Bank Info Security. https://www.bankinfosecurity.com/gdpr-breach-german-privacy-regulator-fines-11-telecom-a-13482