Beyond Bearer Tokens

Beyond Bearer Tokens?

Tuesday 3A

Convener(s): Annabelle Backman

Notes-taker(s): Darin McAdams

Tags for the session - technology discussed/ideas considered:

 OAuth, Sender Constrained Tokens, Token Binding, DPoP

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Requirements

• Sender Constrained tokens
• Authenticity/Integrity of the message, binding the request to the proof for greater assurance on the request contents sent by legit party.
• Scalability/Distributability, needs to work across highly distributed fleets, both clients, RS, AS.
• Performance, in some case single digit millisecond latency goals
• Headers or QS
• Browser Clients, Single Page Apps (SPA)
• Streaming, or traffic with large request bodies

Current Solutions

• TLS Token Binding (RIP)
• Mutual TLS
• DPoP
  • HTTP Request Signing, couple draft specs
  • One based off experience with OAuth 1.0
  • Another variant based on OAuth XYX, only signing a detached document signature, not all HTTP request contents.
  • Another one presented by Cavage, but only a presentation. Not picked up yet. Started as a way to sign headers. Can also sign a message digest, but mostly header signing.

  Discussion

• Token Binding is dead.
• MutualTLS:
  • Fails the browser use case.
  • OK when hosting your own webserver, but difficult when outsourcing your edge to a cloud provider. Lots of layers between, say, an AWS Lambda function and the caller. TLS information not always available when service is fronted by edge services.
  • Add another requirement: works with TLS offloading.
  • Should we try to fix that problem? There was a draft spec, but went nowhere. Would need to be adopted by all the reverse proxies and edge providers.
  • May come back to this…
• Okta: tried a proof-of-concept with DPoP + Request Signing.  Multiple RSA signings resulted in a performance hit. Must be mindful of the amount of signing.
• Question – do we have a viable solution for achieving authenticity and integrity at scale?
• To people in the room: what OAuth scenarios do you have which are currently unsolved by bearer tokens or mTLS?
• We have a long history of working with Smart Cards, looking for signing where keys are coming from a secure element, external element plugged in. Moving from Windows to Linux, that model changes. We want a web application, with a consistent user experience, where the browser could talk to device. That use case is being done in the WebAuthn space, but want to extend into the request.
• Humans in a browser - Increasing barriers to get access to a bearer token, but still many scenarios. Would like more protections here.
• Duo – we have our own signing approach we had to invent.
• If we have anomaly detection for bearer tokens, is that enough? All these mechanisms are complementary means to address the risks of token theft and message replay.
• Should we revive TLS Token Binding?  There is a fork in the road coming: do we want a world where TLS is end-to-end encrypted all the way, or do we want to keep man-in-the-middling ourselves.
• May see both scenarios continue playing out. Don’t need a panacea answer. May see different technologies for different scenarios.
• Don’t know it’s meaningful anymore to ask what TLS is trying to solve anymore. So much virtualization is happening in the networking stack to create a modern, identity-aware firewall, service meshes, routing across VPCs dynamically… do not assume architecture is always client through TLS to webserver. If you want to use that approach, go for it. If you don’t, we need more options.
• Increasingly, there are more hops in the chain. E.g. end-user to point to point to point. Desire to know the originating end-user and all the hops in between. That’s becoming more important than just presuming a single channel.
• Agreement that we’d like a stronger alternative to bearer tokens in places where mTLS isn’t the answer.  Don’t know what that answer is, yet.