Standards Corner: Tokens. Can You Bear It?

This week's post is all about tokens. What are the different types of tokens that may be used in RESTful services? How are they the same/different from browser cookies? What are access tokens, artifacts, bearer tokens, and MAC tokens?

If I asked you what are tokens used for, many of you would answer authentication. But there is a bit more to it than that. First, I'd like to point you to a post I wrote on my personal blog called "3 Parts to Authentication"

In this post, authentication is described as a process broken down into 3 parts:
1. Registration
2. Credential Presentation
3. Message Authentication

What's important here is that many often confuse the process of credential presentation with message authentication. Credential presentation is the process where a user or an HTTP client application demonstrate (with one or more factors), that the user or HTTP client application in question is the same one that was previously registered. Having successfully completed the credential presentation process, the authenticator issues a cookie or token which can be used for a period of time, as a means of message authentication -- creating a single-sign-on session.

Today's post focuses on step 3, using cookies or tokens to access web resources. In browsers, cookies are added to requests in order to allow web sites to perform message authentication -- in effect creating the effect of single-sign-on. HTTP client applications use tokens in much the same way. They pass tokens, given to them by an authorization server, in the HTTP Authorization header of requests to achieve the same thing cookies do for browsers. In the case of tokens issued by an OAuth2 Authorization server (as with Kerberos and others), we call these tokens "access tokens" because they are used to access web resources.

Broadly speaking, there are 2 categories of tokens web sites may accept: bearer tokens and proof tokens. Bearer tokens work very much like browser cookies. They can be a simple unique identifier (aka artifact), or they can be encoded strings that have meaning to the web sites they are intended for. However to the client, these cookies are just random (opaque) text strings that need to be passed to the web site in order to access a resource (message authentication). Because the client doesn't have to do anything but merely attach a bearer token to its request, bearer tokens are very simple for client developers to use. For more details on bearer tokens, check out RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage.

While bearer tokens are incredibly simple and easy to use, there is a downside. Any client that obtains a copy of the bearer token may use it. Simple possession is enough to access the web resource (hence the term bearer). So, a critical limitation of bearer tokens is they SHOULD NOT be used over plain HTTP since they can be sniffed and copied. Web sites, accepting tokens should consider whether there is a possibility that access tokens could be sniffed or otherwise shared and does that impose a risk. Because of this, the IETF OAuth Working Group is nowworking on requirements for Holder-of-Key tokens (aka proof tokens).This document describes in detail the kinds of problems that could be solved and attempts to get to a set of use case requirements for a final token specification.

Proof tokens require an HTTP client to perform some kind of calculation that shows that only it could have used the token (such as with a private key or other shared secret). In a HoK token, a client could be required to generate a request signature, and even add a counter in order to prevent play-back attacks in addition to simple proof of a client's right to use a token. An example of this is the MAC token draft. The OAuth2 Working Group is debating whether this specification should move forward or whether a simpler specification based on JSON Tokens (JWT) should be developed.

So, in many ways, tokens build on the experience industry has had for many years with browsers and single-sign-on cookies. Tokens wielded by HTTP clients accessing RESTful web resources achieve the same feature we've taken for granted with browsers. Bearer tokens are easy for most clients to use, but require secure connections when used to prevent sniffing. Proof/HoK tokens can be used to where web resources are either unprotected, or further proof of the right to use a token is needed.

Cross-posted from OracleIDM.