June 12th, 2012

Mobile-Friendly Federated Identity: Part 1 – The Social Login Legacy

 

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

  • End user experience
  • How easy it is for a relying party to participate
  • How well it meets security requirements

I get easily frustrated when subjected to bad user experience regarding user login and Single Sign-On 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 smartphone 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 the native Facebook app on my smartphone, from which I was able to express consent.

This neat OAuth-ish handshake only required three taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. By the way, 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 that also has its own native app.

Mobile Identity Figure 1 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 could 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 has 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 would be to 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 the 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 series, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities, using standards like OAuth and OpenID Connect with the Layer 7 Gateway.

May 24th, 2012

Forrester, ProgrammableWeb & Swagger: Upcoming Webinars

Layer 7 Webinars and Tech TalksThese are eventful times for Layer 7, with staff-members appearing at trade shows across North America and Europe. Notably, our CTO Scott Morrison has been undertaking what he’s termed his APIs, Cloud & Identity Tour. Somehow, Scott is also finding time to take part in a couple of the company’s upcoming Web seminars.

On May 29, he’ll be presenting our latest Tech Talk Tuesday meet-up, titled Swagger, WADL & API ‘Scriptions. This interactive session will take a look at the relative merits of different standards for creating formalized, machine-interpretable API descriptions. For full details on how to view and join in with this event, visit the Tech talk Tuesday page.

The following day, Scott will be reprising the recent webinar Identity, Access & Privacy for the New Hybrid Enterprise, featuring Eve Maler of Forrester Research, Inc. This is a special live presentation for the Asia/Pacific region (at 11am Sydney time/9am Singapore time). For more information, take a look at the webinar registration page.

Scott gets a break when Product Manager Dana Crane takes over webinar duty on June 5 for Getting Your API Discovered: The Secret to API Promotion, featuring ProgrammableWeb Founder John Musser. This session will explore a range of best practices for building a community of API developers. Registration is open now and you can click here to sign up.

April 11th, 2012

Beyond OAuth – Emerging Standards for API Access Control

 

Beyond OAuthOAuth 2.0 seems to be on everybody’s minds these days. I can’t remember an emerging standard picking up interest so fast. The Layer 7 OAuth Toolkit evolved through three stages over the last couple of years and I’m proud to say that I was involved right from the beginning. It was first developed out of necessity, using existing elements of the Layer 7 SecureSpan Gateway platform – a testament to the flexibility of that platform. Then, leveraging precious feedback from numerous architects applying OAuth with our Gateway, the OAuth Toolkit matured; became a product of its own. Today, we’re witnessing the third evolution phase: OAuth is making its way to the very core of the SecureSpan Gateway platform.

I mention these different evolution phases because I noticed how different engineers working at these different levels – and in some cases isolated from each other (I travel a lot) – identified very similar patterns relating to implementing API access control using OAuth. I’m talking about interaction patterns between various components involved, including for example a token issuer, an API consumer, a policy enforcement point etc. These parties need to discover information at runtime relating to tokens and identities; tokens need to be stored somewhere and managed. It just seems logical that this information would be exchanged via open APIs themselves. Integrating these logical components via APIs means that you can easily separate them as needed and manage their mutual trust. For example, implement the OAuth protocol in a DMZ perimeter zone but store tokens and associated state in the trusted network. API-based integration between these different logical components also facilitates the integration of existing IT assets into a new OAuth-enabled system.

I recognize many of these patterns in emerging standards building on top of OAuth 2.0, such as OpenID Connect and User Mediated Access (UMA). Coincidence? Obviously not. I expect these emerging standards to be among the new focuses while building the next generation API management infrastructure.

March 8th, 2012

Reminder: Upcoming API Access Control Webinar

Layer 7 WebinarOAuth handshake patterns and OAuth token management are currently two of the hottest topics related to enterprise APIs. Although OAuth originated as a third-party authorization mechanism, it now addresses a multitude of patterns related to controlling access for RESTful APIs. With version 2.0 of the standard defining numerous grant types that accommodate both two and three-legged cases, OAuth is becoming the de-facto standard for any API access control.

Regardless of the specific access control scenario, any enterprise-scale OAuth implementation must leverage existing infrastructure and processes for managing and controlling identities. For example, OAuth should be implemented in a way that maintains any existing Single Sign-On user experience or it should simply reuse existing identities and their attributes as part of the authorization checks.

Next Wednesday, I’ll be joined by Steve Coplan of 451 Research for a webinar called Simplifying API Access Control with OAuth. We’ll be taking an in-depth look at just how OAuth can be integrated with existing systems for effective API access control. We’ve already had a lot of interest in the event but there are still a few free spots, so don’t hesitate to sign up for the webinar today.

February 29th, 2012

Upcoming Webinar: Simplifying API Access Control with OAuth

Extending Existing IAM Technology for Enterprise API Access Control featuring 451 ResearchAccess control is a key aspect of API management. When an enterprise launches an API, identity and access management (IAM) will be among its most pressing concerns. But access control is handled differently for APIs than it is for the Web or even Web services. This can present difficulties for an enterprise that wants to reuse its existing IAM  infrastructure to provide access control for APIs.

On March 14, I’ll be co-presenting a webinar called Simplifying API Access Control with OAuth, alongside Steve Coplan of 451 Research. We’ll be exploring a good deal of the ground around API access control and OAuth but with a particular focus on how existing IAM and Single Sign-On (SSO) systems can be extended to integrate with API-enabled applications and services.

In addition to discussing how enterprises can extend their existing IAM and SSO investments for API access, we’ll be looking at:

  • What security and management concerns are created by open APIs
  • How enterprises can address key IAM challenges when securing APIs
  • Why OAuth is becoming central to API access control

Space is limited – so, if you’re interested, sign up today!