Difference between revisions of "Token Binding"
From MgmtWiki
(→Solution) |
(→Problem) |
||
| Line 10: | Line 10: | ||
*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 a transparent mechanism to close this gap. RFC 8471 ''The Token Binding Protocol Version 1.0'' was approved in (2018-10) by the IETF. The [[Token Binding]] feature has been dropped by the Google Chrome browser as inadequate to solve the problem at about the same time as the RFC was approved. So a different solution is required. | *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 a transparent mechanism to close this gap. RFC 8471 ''The Token Binding Protocol Version 1.0'' was approved in (2018-10) by the IETF. The [[Token Binding]] feature has been dropped by the Google Chrome browser as inadequate to solve the problem at about the same time as the RFC was approved. So a different solution is required. | ||
*HTTPS and the identity in the [[X.509]] Certificate is adequate given the uncertain nature of the [[URL]] as an [[Identifier]]. | *HTTPS and the identity in the [[X.509]] Certificate is adequate given the uncertain nature of the [[URL]] as an [[Identifier]]. | ||
| + | * Token binding requires that the key used in TLS be used at the application layer. That would require that the internet facing server have access to the signing key, or at least that the signing key be distributed to multiple servers. This is poor security practice and should be banned outright. | ||
==Solution== | ==Solution== | ||
Revision as of 10:45, 8 December 2020
Full Title or Meme
The process of binding an OpenID Connect or OAuth 2.0 interchange to a HTTPS channel that has been established between a user agent and a Web Site.
Context
- Secure web connections are dependent on HTTPS for security.
- See the page on Channel Binding about RFC 5056 for details on the use of low level security protocols to provide application level security.
Problem
- Attempts to make a trusted connection from a user to Web Site have included EV Certs and other attempt to over come the failings inherent in trusting any connection based on the URL have all failed. See the page Bearer Tokens Considered Harmful for details.
- 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 a transparent mechanism to close this gap. RFC 8471 The Token Binding Protocol Version 1.0 was approved in (2018-10) by the IETF. The Token Binding feature has been dropped by the Google Chrome browser as inadequate to solve the problem at about the same time as the RFC was approved. So a different solution is required.
- HTTPS and the identity in the X.509 Certificate is adequate given the uncertain nature of the URL as an Identifier.
- Token binding requires that the key used in TLS be used at the application layer. That would require that the internet facing server have access to the signing key, or at least that the signing key be distributed to multiple servers. This is poor security practice and should be banned outright.
Solution
Look to other solutions like:
- Bound Tokens do not need to be based on the underlying HTTPS connection, which was never designed to create trust in the identity of the Web Site.
- Create a Trusted Identifier as a URN for web sites and then bind the token to that URN.
