Give me a JWT, I’ll give you an Access Token

January 4, 2013

One of the common misconceptions about OAuth is that it provides identity federation by itself. Although supporting OAuth with federated identities is a valid pattern and is essential to many API providers, it does require the combination of OAuth with an additional federated authentication mechanism. Note that I’m not talking about leveraging OAuth for federation (that’s OpenID Connect), but rather, an OAuth handshake in which the OAuth Authorization Server (AS) federates the authentication of the user.

There are different ways to federate the authentication of an end user as part of an OAuth handshake. One approach is to simply incorporate it as part of the authorization server’s interaction with the end user (handshake within handshake). This is only possible with grant types where the user is redirected to the authorization server in the first place, such as implicit or autz code. In that case, the user is redirected from the app, to the authorization server, to the idp, back to the authorization server and finally back to the application. The federated authentication is transparent to the client application participating in the OAuth handshake. The OAuth spec (which describes the interaction between the client application and the OAuth Authorization Server) does not get involved.


Another approach is for the client application to request the access token using an existing proof of authentication in the form of a signed claims (handshake after handshake). In this type of OAuth handshake, the redirection of the user (if any) is outside the scope of the OAuth handshake and is driven by the application. However, the exchange of the existing claim for an OAuth access token is the subject of a number of extension grant types.

One such extension grant type is defined in SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification according to which a client application presents a SAML assertion to the OAuth authorization server in exchange for an OAuth access token. The Layer 7 OAuth Toolkit has implemented and provided samples for this extension grant type since its inception.


Because of the prevalence of SAML in many environments and its support by many identity providers, this grant type has the potential to be leveraged in lots of ways in the Enterprise and across partners. There is however an alternative to bloated, verbose SAML assertions emerging, one that is more ‘API-friendly’, based on JSON: JSON Web Token (JWT). JWT allows the representation of claims in a compact, JSON format and the signing of such claims using JWS. For example, OpenID Connect’s ID Tokens are based on the JWT standard. The same way that a SAML assertion can be exchanged for an access token, a JWT can also be exchanged for an access token. The details of such a handshake is defined as part of another extension grant type defined as part of JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.

Give me a JWT, I’ll give you an access token. Although I expect templates for this extension grant type to be featured as part of an upcoming revision of the OAuth Toolkit, the recent addition of JWT and JSON primitives enables me to extend the current OAuth authorization server template to support JWT Bearer Grants with the Layer 7 Gateway today.

The first thing I need for this exercise is to simulate an application getting a JWT claim issued on behalf of a user. For this, I create a simple endpoint on the Gateway that authenticates a user and issues a JWT returned as part of the response.


Pointing my browser to this endpoint produces the following output:


Then, I extend the Authorization Server token endpoint policy to accept and support the JWT bearer grant type. The similarities between the SAML bearer and the JWT bearer grant types are most obvious in this step. I was able to copy the policy branch and substitute the SAML and XPath policy constructs for JWT and JSON path ones instead. I can also base trust on HMAC type signatures that involve a share secret instead of a PKI based signature validation if desired.


I can test this new grant type using REST client calling the OAuth Authorization Server’s token endpoint. I inject in this request the JWT issued by the JWT issuer endpoint and specify the correct grant type.


I can now authorize an API call based on this new access token as I would any other access token. The original JWT claim is saved as part of the OAuth session and is available throughout the lifespan of this access token. This JWT can later be consulted at runtime when API calls are authorized inside the API runtime policy.

Returning from #CIS2012

July 20, 2012

Cloud Identity Summit was definitely worth the trip. The talks were great, the audience was great, and the venue was outstanding. Sign me up for next year in Napa.

It’s beautiful and quiet at Vail Cascade this morning. As I stepped outside, I’m pretty sure I saw SAML scurrying away in the trees. This is weird given this week’s proclamations that SAML was dead. Although we’re not rid of SAML anytime soon, I do look forward to adoption in the enterprise for the new kid on the block: OpenID Connect. Easier federation, OpenID Connect style is already common for consumer identity providers; enterprise identity providers should take note and follow suit.  As a vendor of API management infrastructure, it’s up to us to enable the enterprise to better reach out to its target audience. I see support for OpenID Connect as a key component in achieving this today.

My favorite proclamation of the week goes to Patrick Harding who declared in his talk titled “The Platiformication of the Enterprise is Upon us Again and they Forgot Security (Again)” that API Tokens are going to be “the currency of the API Economy”. The management of tokens and their lifecycle is indeed a crucial component of API management. Consider the case of a mobile application consuming an Enterprise API using an OAuth token. Such tokens are associated with the API provider, the user (subscriber), the mobile application and the mobile device. Each live token is potentially associated with multiple parties and one of the challenges of API token management is to enable control of the right tokens by the right parties.