0

When is a bearer token not a bearer token? ……. when its bound

Share this content:
LinkedIn
Facebook
RSS

Ok not funny, but possibly true. With the ratification of the IETF Token Binding base specifications so close, the next step would be the submission of the OAuth2 and OpenID Connect Token Binding specification.

This will then add additional security around tokens that are deemed valid just because you posses it (ie Bearer). I don’t know how many times I have seen bad implementations where these tokens are present in server logs, allowing any administrators to impersonate the user and perform transactions on the target API. Well with Token binding and more importantly the Oauth 2.0 Token Binding speceification this issue will be eliminated. So no longer will it be a “Bearer” token it will be a Proof of Possession Bearer Token, you will not only need to have the Bearer token you will need to prove that that particular Bearer token was minted for your particular TLS Session. As mentioned by Alex and Pam in their blog post the whole Proof of Posession (I guess Proof of Ownership wasn’t the best Acronym 😜) has been a long time coming, but now the base specifications are just over the horizon hopefully the additional specs for OIDC, Oauth and Reverse Proxies will be right behind them. And not to mention it will then need to be implemented into the underpinning Trust Engine of Azure AD / Azure AD B2C.

As a bit of an overview I have done up a simple “Hypothetical” OpenID Connect Implicit flow diagram which explains the flow within the OIDC Token Bound Authentication spec;

  1. The user tries to access a site protected by OpenID Connect, the site also allows for token binding so the Sec-Token-Binding Header will be in the request.
  2. The RP then redirects the user to the Authorization server (Azure B2C in My example). Included in the 302 redirect is the Include-Referred-Token-Binding-ID header with a value of True.
  3. B2C will then recieve the Authentication request but it will also receive two token binding messages within the SEC-Token-Binding Header. 1 for the Current connection form Client to B2C and the other for the initial Client to RP connection.
  4. The user is then authenticated using whatever means (Username / Passwword etc). B2C will then generate a an ID_Token but will also include the Token Binding Hash (TBH) value to the Confirmation (CNF) claim. The value to TBH will be a base64 encoded SHA 256 Hash of the Token Binding ID from the Client to RP connection (not the Client to B2C connection)
  5. The ID_Token is then supplied via the browser to the RP and in turn the client also supplies the Sec-Token-Binding Header
  6. The RP then validates the ID_Token using the usual means, then also validates that the hash value supplied in the TBH value of the ID_Token matches the the ID of the provided token binding message within the Sec-Token-Binding Header.
  7. If so the user is then allowed access.

For more Information see Alex’s Blog post or for more details on the Spec’s see the links below;

BASE

Token Binding Protocolhttps://tools.ietf.org/html/draft-ietf-tokbind-protocol-14

Token Binding over HTTPhttps://tools.ietf.org/html/draft-ietf-tokbind-https-09

TLS Extension for Token Binding Protocol Negotiationhttps://tools.ietf.org/html/draft-ietf-tokbind-negotiation-08

And the others

OAUTH2 Token Binding: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-03

OIDC Token Bound Authenticationhttp://openid.net/specs/openid-connect-token-bound-authentication-1_0.html

Reverse Proxieshttps://tools.ietf.org/html/draft-ietf-tokbind-ttrp-00

Phil Whipps

I am a senior practitioner with sixteen years experience in the IT industry within the Identity and Access Management area. My Current focus is implementation and design of Azure based products - mainly focusing on B2C.

Leave a Reply

Your email address will not be published. Required fields are marked *