Moving Towards A Tokenized World For Access Rights

Like it or not, we are moving to a tokenized world, and where we pass tokens which are trusted to provide further information. This might…

Moving Towards A Tokenized World For Trusted Access Rights

Like it or not, we are moving to a tokenized world, and where we pass tokens which are trusted to provide further information. This might relate to a login token for a corporate infrastructure, and where an access token can be passed to give rights to applications and files. The tokens themselves — if designed properly — will not actually reveal sensitive information (such as passwords and login IDs). If a token is signed with the private key of a trusted entity, we know that we can trust the token.

If you want to do access tokens correctly we can use SAML (Security Assertion Markup Language), or OAuth 2.0. Unfortunately, SAML is complex to implement properly, and so many companies have implemented OAuth 2.0 for access control. In its original form, OAuth 2.0 tried to reduce its dependency with an HTTPs connection and on digital signatures, but this has led to the poor protection of the secrets on the token and can also lead to token stealing. This is because the token is not actually signed by the trusted entity. While this keeps things simple, the tokens themselves cannot be fully trusted. The security built in was to use an HTTPs connection to pass the token back and define a time-out for the token.

And so HTTP from its humble HTTP 1.0 roots, with GET and POST, then provided us with RESTful Web services. Now it is supporting token binding with a new RFC:

Overall it aims to remove the issue around token replay, and where a token can be copied from a valid session, and then replayed back:

At the core of the change is that the token is created with the details of the device, or the device’s configuration, integrated into the token. This makes it difficult to recreate the device conditions in order to use the token. RFC 4871 then defines the creation of a public and a private key (and which could possibly be linked into a TPM (Trusted Platform Module) and linked to the private key built into the hardware. In this way we could bind access tokens to specific hardware, and where other computers could not use the token. The private key is used to sign elements of the negotiation steps.

In this way, the private key of a client can be stored in the TPM, and thus used to sign the token. An intruder will then not be able to generate this key, and will not be able to use the token. The binding is bound to a TLS session:

  • The client generates a long-time private key for each server that it connects to.
  • The client converts the public keys into a simple unique data entity (defined as token binding ID).
  • Within a TLS connection, the client sends a token binding message. This message holds the token binding ID (the public key) and a signature that proves that the client knows the private key, along with some unique data from the TLS session.
  • The server then verifies the signature and binds this to a token with the client’s public key.

The RFC defines the linkage of HTTPS security cookies and OAuth tokens to the TLS layer. These tokens would then be difficult to recreate for replay attacks. With the TLS connection to a server, the client generates a key pair for each of the servers that they connect to. We can also now extend the time limit of the token so that they can be long-lived (as opposed to the time-limited tokens in OAuth 2.0).

The additional field within the HTTP header defines an encoded token:

Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_jaOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25GgmKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA

In a federated identity use case, such as using Facebook as an identity provider, we must provide a token signed with two private keys. RFC 8472 supports this operation, and thus overcomes the copying of federated tokens.

There are two other related RFCs:

  • RFC 8472. TLS extension using the Token Binding Protocol.
  • RFC 8473. Application of the protocol to HTTP.

The updates, it is hoped, will not affect existing implementations. If you are a .NET fan, there are token bindings here.