Difference between revisions of "Token Binding"

From MgmtWiki
Jump to: navigation, search
(Problem)
(Problem)
Line 9: Line 9:
 
*Attempts to make a trusted connection from a user to [[Web Site]] have included [[EV Cert]]s 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.
 
*Attempts to make a trusted connection from a user to [[Web Site]] have included [[EV Cert]]s 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.
 
*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]].
  
 
==Solution==
 
==Solution==

Revision as of 17:16, 13 November 2018

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.

Solution

Look to other solutions like:

  1. Bound Tokens
  2. trusted URIs.

Reference