Part 1 - What are they?

A lot of people are at least somewhat familiar with OAuth 2.0 and possibly OpenID Connect, an alternative to SAML for communicating identities and information about a user between identity providers and service or resource providers.

Many people are also familiar with JSON Web Tokens (JWT), which is a standard way for building a signed and if desired, encrypted token that can contain arbitrary key-value pairs of information.

It’s the combination of these three technologies that is truly powerful and I believe will be the dominant way that Web Access Management (WAM) products will produce, consume, and transform identities and claims around those identities.

The rest of this blog will focus on a vision of how those technologies fit together and solve a wide variety of current and upcoming use cases.  I’ve tried to err on the side of understand-ability and conciseness so many of the underlying protocol details have been skipped.

Note that this is one architects vision - none of what is described here should be construed as official commitment for new product development.

OpenID Connect Tokens and Endpoints

Below is a diagram that shows the components, endpoints, and typical flow for OpenID Connect. In OAuth 2.0 and OpenID connect there are three parties to the interaction (excluding the actual users). They are the client, the authorization server, and the resource server. This is different than SAML which only has two actors, the Identity Provider and the Service Provider.

OAuth and OpenID Tokens

The format of the OAuth 2.0 access and refresh tokens are officially opaque to the client and to the resource server.

The access token is the token that the client uses to request resources from the resource server on behalf of the user. It is expected to be a short lived token (minutes or hours).

The refresh token is the token that the client uses to get a new access token from the authorization server when the current access token expires, without the user being re-challenged. Its lifetime is typically hours or days.

One of the weaknesses of OAuth 2.0 is that there is no prescribed way for the resource server to validate the access token or to use the access token to establish the identity of the user.

This was not a problem when the resource server and the authorization server were closely linked. The access token could just be a lookup key that the resource server checked via an internal API. What should we do if the authorization server and resource server are separate entities?

Google and other OAuth 2.0 providers solved this problem by providing a TokenInfo Endpoint. Resource servers could pass the access token to this endpoint and get back a JSON object that tells you whether or not the token is valid, user identity, token scope, and expiration time.

The Introspection or TokenInfo endpoint has now been formalized by RFC 7662 and is implemented by most OAuth 2.0 and OpenID connect providers. It provides a secure way for resource servers to get metadata about access and refresh tokens from the authorization server.

Although access and refresh tokens are defined to be opaque values, some OAuth 2.0 implementations allowed the tokens to be signed JWT tokens, which would allow the client and resource server to extract information directly from the token without having to make additional calls to the OpenID Provider UserInfo endpoint

This concept was expanded in OpenID Connect with the introduction of the ID token. The ID token is a signed and potentially encrypted JWT token which contains the user’s identity and any claims that were in scope.

This gives client applications and resource servers the ability to securely get information about the user directly without having to contact the authorization server every time.

There is still debate within the OpenID Connect implementer and user community as to whether the ID token is for use solely by the client, or can also be sent to the resource server.

Next Post

  In the next post I will describe why all of this is important and how it can be combined and used to solve real world application issues.