Mobile-friendly federated identity, Part 2 – OpenID Connect

June 21, 2012

The idea of delegating the authentication of a user to a 3rd party is ancient. At some point however, a clever (or maybe lazy) developer thought to leverage an OAuth handshake to achieve this. In the first part of this blog post, I pointed out winning patterns associated with the popular social login trend. In this second part, I suggest the use of specific standards to achieve the same for your identities.

OAuth was originally conceived as a protocol allowing an application to consume an API on behalf of a user. As part of an OAuth handshake, the API provider authenticates the user. The outcome of the handshake is the application getting an access token. This access token does not directly provide useful information for the application to identify the user. However, when that provider exposes an API which returns information about that user, the application can use this as a means to close the loop on the delegated authentication.

Step 1 – User is subjected to an OAuth handshake with provider knowing its identity.

Step 2 – Application uses the access token to discover information about the user by calling an API.

As a provider enabling an application to discover the identity of a user through such a sequence, you could define your own simple API. Luckily, an emerging standard covers such semantics: OpenID Connect. Currently a draft spec, OpenID Connect defines (among other things) a “user info” endpoint which takes as input an OAuth access token and returns a simple JSON structure containing attributes about the user authenticated as part of the OAuth handshake.

GET /userinfo?schema=openid HTTP/1.1
Authorization: Bearer SlAV32hkKG

200 OK
content-type: application/json
“user_id”: “248289761001”,
“name”: “Jane Doe”,
“given_name”: “Jane”,
“family_name”: “Doe”,
“email”: “”,
“picture”: “”

In the Layer 7 Gateway OpenID Connect, a generic user info endpoint is provided which validates an incoming OAuth access token and returns user attributes for the user associated with said token. You can plug in your own identity attributes as part of this user info endpoint implementation. For example, if you are managing identities using an LDAP provider, you inject an LDAP query in the policy as illustrated below.

To get the right LDAP record, the query is configured to take as input the variable ${session.subscriber_id}. This variable is automatically set by the OAuth toolkit as part of the OAuth access token validation. You could easily lookup the appropriate identity attributes from a different source using for example a SQL query or even an API call – all the input necessary to discover these attributes is available to the manager.

Another aspect of OpenID Connect is the issuing of id tokens during the OAuth handshake. This id token is structured following the JSON Web Token specification (JWT) including JWS signatures. Layer 7’s OpenID Connect introduces the following assertions to issue and handle JWT-based id tokens:

  • Generate ID Token
  • Decode ID Token

Note that as of this writing, OpenID Connect is a moving target and the specification is subject to change before finalization.

Mobile-friendly federated identity, Part 1 – The social login legacy

June 12, 2012

If I were to measure the success of a federated identity system, I would consider the following factors:

  • End user experience (UX);
  • How easy it is for a relying party to participate (frictionless);
  • How well it meets security requirements.


I get easily frustrated when subjected to bad user experience regarding user login and SSO but I also recognize apps that get this right. In this first part of a series on the topic of mobile-friendly federated identity, I would like to identify winning patterns associated with the social login trend.


My friend Martin recently introduced me to a mobile app called Strava which tracks bike and run workouts. You start the app at the beginning of the workout, and it captures GPS data along the way – distance, speed, elevation, etc. Getting this app working on my smart phone was the easiest thing ever: download, start the app, login with facebook, ready to go. The login part was flawless; I tapped the Login with Facebook button and was redirected to my native facebook app on my smartphone from where I was able to express consent. This neat OAuth-ish handshake only required 3 taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. BTW, I don’t even know that password, it’s hidden in some encrypted file on my laptop somewhere, so at this point I move on to something else and that’s the end of the app for me. Starting such handshakes by redirecting the user through the native app is the right choice in the case of a native app relying on a social provider which also has its own native app.


Figure 1 – Create account by expressing consent on social provider native app

At this point my social identity is associated to the session that the Strava app has with the Strava API. Effectively, I have a Strava account without needing to establish a shared secret with this service. This is the part where federated identity comes in. Strava does not need to manage a shared secret with me and does not lose anything in federating my identity to a social provider. It still lets me create a profile on their service and saves data associated to me.

When I came home from my ride, I was able to get nice graphs and stats and once I accepted the fact that I have become old, fat and slow, decided to check on my laptop. Again, a friendly social login button enabled me to login in a flash and I can see the same information with a richer GUI. Of course on my laptop, I do have a session with my social provider on the same browser so this works great. The same service accessed from multiple devices each redirecting me to authenticate in the appropriate way for the device in use.

Now that we’ve established how fantastic the login user experience is, what about the effort needed on the relying party? Strava had to register an app on facebook. Once this is in place, a Strava app simply takes the user through the handshake and retrieves information about that user once the handshake is complete. In the case of facebook on an iOS device, the instructions on how to do this are available here. Even without a client library, all that would be required is implement an OAuth handshake and call an API with the resulting token to discover information about the user. There is no XML, there is no SAML, no digital signatures, and other things that would cause mobile developers to cringe.

Although a good user experience is critical to the adoption of an app, the reasons for Strava to leverage the social network for login go beyond simplifying user login. Strava also happens to rely on the social network to let users post their exploits. This in turn enhances visibility for their app and drives adoption as other users of the same social network discover Strava through these posts.

Although social login is not just about federated authentication, it creates expectations as to how federated authentication should function and what should be required to implement it. These expectations are not just from end users but also from a new breed of application developers who rely on lightweight, mobile-friendly mechanisms.

In the second part of this blog, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities using standards like OAuth, OpenID Connect and the Layer 7 Gateway.