New Standards Emerging for HoK Tokens

Back
January 20, 2015

 

Web SSO protocols like SAML and OpenID Connect define how an assertion as to a user's authentication status can be created by one party (called Identity Provider or Authorization Server in SAML and OpenID Connect, respectively) and delivered via the browser for consumption and validation by a relying party (called Service Provider or Client in the two protocols). It is by presenting the assertion or token to the relying party that the user effectively authenticates there, rather than directly providing a password or equivalent. 4FB4D858-C296-3582-5051E0B640F9D9B3.jpg

The security of web SSO protocols depends greatly on being able to prevent some malicious actor from gaining possession of the assertion/token and presenting it to the relying party in order to impersonate the valid user.

By default, the assertions in SAML web SSO, and the tokens in Connect-based web SSO are 'bearer tokens.' These 'bearer tokens' can be used any actor who gains possession of the assertion/token since the RP makes no additional check to ensure that it is being presented by the valid user to whom it was issued.  

Conversely, a Holder-of-Key (HoK) token would require that, in addition to possession of the token, knowledge of a cryptographic key associated with that token would also be required for the token to be presented to the RP. HoK models (sometimes referred to as 'proof of possession', as the presenter must demonstrate they possess some secret) can improve the overall security of web SSO models compared to bearer tokens. HoK can significantly mitigate the risk of an attacker stealing the token and using it to impersonate the user to whom it was issued.

Arguably, the most straightforward model for HoK would be for the token to be issued with a public key contained within itself (the token signed so that the public key couldn't be swapped out for another). To use the token, the presenting party would digitally sign something (the message, or perhaps a challenge string) in order to demonstrate they do indeed have the associated private key. In theory, the browser could use an installed X.509 certificate (and associated private key) for this HoK mechanism. However, in practice, doing so results in the user being presented with confusing confirmation dialogs for certificate selection. Additionally, the burden of managing the lifecycle of these browser certificates has limited the numbers of deployments (implying the weight & cost of a PKI).

An alternative option is to leverage the SSL keys that protect the messages passed between the actors and that are established between the browser and the servers in a web SSO flow. If a token carries within itself a key related to the keys of the SSL session that protects the channel over which the token is presented, then that token is cryptographically bound to that channel. Even if an attacker were somehow able to gain possession of the token, they would not have the corresponding SSL keys and could not use that token at the RP.

A number of related specifications are emerging that together will enable a HoK model for Connect-based web SSO.

 

  • The Token Binding Protocol Version 1.0
    • https://tools.ietf.org/html/draft-popov-token-binding-00
  • Token Binding over HTTP
    • http://tools.ietf.org/html/draft-balfanz-https-token-binding-00
  • Proof-Of-Possession Semantics for JSON Web Tokens (JWTs)
    • https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-00

A complete description of the details authored by my Ping Identity colleague, John Bradley, who is actively contributing to the above specs, can be read here. The Reader's Digest version is as follows:

 

  1. Client & Browser establish a public key via the SSL negotiation
  2. Browser sends public key to AS with Authz request
  3. AS includes public key in Connect id_token
  4. AS returns id_token to Browser
  5. Browser sends id_token to Client over SSL session using same public key
  6. Client verifies that the public keys match

This emerging HoK mechanism promises to mitigate man-in-the-middle (MITM) and man-in-the-browser (MITB) attacks that Connect-based web SSO would otherwise be vulnerable to. As such, it promises to provide a noteworthy and significant security enhancement to OpenID Connect when applied to web SSO.