It’s time for token binding

Howdy Folks,

The last few months have been some VERY exciting times in the world of identity and security standards. Due to the efforts of a broad set of experts across the industry, we’ve made incredible progress in finalizing a broad set of new and improved standards that will improve both the security and user experiences of a generation of cloud services and devices.

One of the most important of these improvements is the Token Binding family of specifications which is now well on its way towards final ratification at the Internet Engineering Task Force (IETF). (If you want to learn more about token binding, watch this great presentation by Brian Campbell.)

At Microsoft, we believe that the Token Binding can greatly improve the security of both enterprise and consumer scenarios by making high identity and authentication assurance broadly and simply accessible to developers around the world.

Given how positive we believe this impact can be, we have been and continue to be deeply committed to working with the community for creation and adoption of the token binding family of specifications.

Now that the specifications are close to ratification, I’d like to issue two calls to action:

1. Begin experimenting with token binding and planning your deployments.
2. Contact your browser and software vendors, asking them to ship token binding implementations soon if they aren’t already.

And I’m happy to report that Microsoft is just one of many industry voices saying that token binding is an important solution whose time has come.

For more on why token binding matters, I’ll turn things over to Pamela Dingle – a leading industry voice who many of you already know – who is now Microsoft’s Director of Identity Standards on the Azure AD team.

Best Regards,

Alex Simons (Twitter: @Alex_A_Simons)

Director of Program Management

Microsoft Identity Division

—————————————————————————————————————————–

Thanks Alex and hi everybody,

I share Alex’s excitement! Years of time and effort have been put into the specifications you will see celebrated as new RFC standards in a very short time. The time is right for architects to dig in to the specific identity and security advantages that Token Binding represents.

What is so great about token binding, you might ask? Token binding makes cookies, OAuth access tokens and refresh tokens, and OpenID Connect ID Tokens unusable outside of the client-specific TLS context in which they were issued. Normally such tokens are “bearer” tokens, meaning that whoever possesses the token can exchange the token for resources, but token binding improves on this pattern, by layering in a confirmation mechanism to test cryptographic material collected at time of token issuance against cryptographic material collected at the time of token use. Only the right client, using the right TLS channel, will pass the test. This process of forcing the entity presenting the token to prove itself, is called “proof of possession”.

It turns out that cookies and tokens can be used outside of the original TLS context in all sorts of malicious ways. It could be hijacked session cookies or leaked access tokens, or sophisticated MiTM. This is why the IETF OAuth 2 Security Best Current Practice draft recommends token binding, and why we just recently doubled the rewards on our identity bounty program. By requiring proof of possession, we turn the opportunistic or pre-meditated use of cookies or tokens in ways they were not intended into something difficult and expensive for an attacker to attempt.

Like any proof of possession mechanism, token binding grants us the ability to build defense in depth. We can work hard to never lose a token, but we can also verify just to be safe. Unlike other proof of possession mechanisms such as client certificates, token binding is self-contained and transparent to the user, with most of the heavy lifting done by the infrastructure. We hope that this eventually means anyone can choose to operate at a high level of identity assurance, but we expect to see strong demand from the government and financial verticals at the beginning, as they have immediate regulatory requirements to do proof of possession. As one example, anyone who requires NIST 800-63C AAL3 categorization requires this kind of technology.

Token binding represents a long road. We are three years in, and while the ratification of the specifications is an exciting milestone, as an ecosystem we still have a lot to build, and this specification needs to work across vendors and platforms to be successful. We are very excited over the coming months to start sharing in depth the security benefits and best practices that have come from our embrace of this functionality, and we hope you will join us in advocating for this technology wherever you need it.

Cheers,

— Pam