Newsroom

Bearer tokens underlie the vast majority of online identity transactions engaged in by identity professionals and amateurs alike. A bearer token has the property that any party in possession of that token (i.e., the “bearer”) can use it to access any associated resources. No other proof beyond the simple possession of the token is needed in order to use it. Session cookies, OpenID Connect ID tokens, OAuth access tokens and other artifacts, SAML assertions, etc. are all (almost) always bearer tokens. Which means that if one of these tokens fall into the wrong hands, it can be used to impersonate the legitimate user or hijack their session.

Bearer tokens aren’t always the bearers of bad news, however. There are numerous protections in place to prevent theft or leakage. Bearer tokens are used every day by everyone of us, and most of the time things are just fine.

But stuff does happen (yeah, I said stuff). Over the last few years, the industry has seen the likes of CRIME, BREACH, Heartbleed, and Cloudflare’s parser bug that can expose cookies and tokens. There have been numerous published token theft attacks on OAuth implementations. And as we move away from the reliance on passwords alone for authentication, attacks aimed at stealing tokens are likely to become increasingly commonplace. Phishing attacks on systems using one-time passwords, for example, are aimed at hijacking the session established from the login rather than the login credentials themselves.

Led in large part by participants from Google and Microsoft, a working group within the Internet Engineering Task Force (IETF), an international standards development organization, has developed a suite of Token Binding standards that enable bearer tokens to level up and become proof-of-possession (PoP) tokens. PoP tokens cannot be used without demonstrating possession of private cryptographic keying material bound to the token. Token Binding enables a client or browser to prove it holds a locally generated public-private key pair by signing a unique identifier of the TLS connection and sending the signature and public key in a header on each HTTP request. Cookies and other tokens can then be bound to that key on issuance. And checking that binding on usage ensures such tokens cannot be used successfully by someone who doesn’t possess the private key. There’s also work taking place in the IETF and OpenID Foundation to standardize how Token Binding would be used in conjunction with OAuth and OpenID Connect.

When bound in this way, stolen tokens cannot be successfully replayed by an attacker. Token Binding’s value proposition is unique because it prevents the use of a token after a theft takes place, rather than trying to prevent the theft itself.

By the time you read this, it’s possible that the core Token Binding suite of specification will have been published as RFCs 8471, 8472 and 8473. This would be cause for celebration were it not for a recent development that has overshadowed the progress of the standards. Despite having early implementation support and helping to lead the IETF standards work, Google’s Chrome browser development team announced that they would be removing support for the feature[6].

The move by Chrome doesn’t necessarily deal a death blow to Token Binding but it is undoubtedly a major setback. There has been somewhat of a surge of advocacy for Token Binding since the news—see these blogs from Ping Identity and Microsoft, for example—and the FIDO Alliance has been touting the benefits of using WebAuthn and Token Binding together to establish higher levels of assurance during authentication. But at the time of writing this, Chrome had shown no indication of changing course. Without broad browser support, the incentives for other platforms and systems to develop support just isn’t the same. And as a result, the chances of Token Binding ever seeing widespread adoption are severely impacted.

The Chrome decision isn’t entirely baseless. I won’t try and do justice to their reasoning here (if you’re interested, you can review the public discussion board) but I think it’s fair to say it is largely about cost-benefit with a nuanced view on the risks Token Binding can mitigate relative to the likelihood of those and related risks.

I got involved with Token Binding because I thought it had the potential to improve the security in our industry in a fundamentally different way than had been seen before. And honestly, I was excited by what I viewed as an opportunity to contribute to something that looked poised to have a wide-reaching and meaningful impact. Token Binding is admittedly kind of a niche thing, but when working on it, I was always able to take solace knowing that two big browsers were already supporting it (supporting draft versions, anyway). Token Binding’s future seemed bright and eventual adoption inevitable. But losing the support in the biggest of the browsers (with respect to market share) changes the whole picture.

I’d like to close this article with some clean call to action. Get out and vote. Call your senator. A kickstarter maybe. But it’s not clear to me that much can be done at this point that will make a difference. So I leave you with the previously written summary of the whole situation as I understand it all. And an uncertain future for an emerging technology that I was once very bullish on. Maybe a kickstarter isn’t such a bad idea after all…