|By Francois Lascelles||
|June 12, 2012 12:22 PM EDT||
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 strava.com 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.
- JSON Schema Validation for RESTful Web Services
- WS Security Performance
- Flexible Identity Federation XML Gateways to The Rescue
- REST JSON to SOAP Conversion Tutorial
- Standardize HMAC, OAuth RESTful Authentication Schemes
- The Importance of Threat Protection for RESTful Web Services
- RESTful SAML?
- How Cloud, Mobile & APIs Change the Way We Broker Identity
- SOA Gateway Trends for 2011 and Beyond
- OAuth Token Management