July 30th, 2012

Why I Still Like OAuth

Written by
 

OAuth 2.0 ControversyThat sound of a door slamming last week was Eran Hammer storming out of the OAuth standardization process, declaring once and for all that the technology was dead and that he would no longer be a part of it. Tantrums and controversy make great social media copy, so it didn’t take long before everyone seemed to be talking about this one. In some quarters, you’d hardly know the London Olympics had begun.

So what are we to really make of all this? Is OAuth dead or at least on “the road to Hell”, as Eran now-famously put it? Certainly, my inbox is full of emails from people asking if they should stop building their security architecture around such a tainted specification.

I think Tim Bray, who has vast experience with the relative ups and downs of technology standardization, offered the best answer in his own blog:

“It’s done. Stick a fork in it. Ship the RFCs.”

Which is to say sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done. And hopefully, right across the street from me here in Vancouver, where the IETF is holding it’s meetings all this week, this is what will happen.

In the end, OAuth is something we all need and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.

In the past, we’ve been shackled by the centralization of control around identity and entitlements (a fancy term which really just describes the set of actions your identity is allowed, such as writing to a particular file system). This has led to a status quo in nearly every organization that is maintained first because it is hard to do otherwise but also because this equals power, which is something that is rarely surrendered without a fight.

The problem is that centralized identity admin can never effectively scale, at least from an administrative perspective. With OAuth, we can finally scale authentication and authorization by leveraging the user population itself — and this is the one thing that stands a chance of shattering the monopoly on centralized identity and access management (IAM). OAuth undermined the castle and the real noise we are hearing isn’t infighting on the spec but the enterprise walls falling down.

Here is the important insight of OAuth 2.0: delegated authorization also solves that basic security sessioning problem of all apps running over stateless protocols like HTTP. Think about this for a minute: The basic Web architecture provides for complete authentication on every transaction. This is dumb, so we have come up with all sorts of security context tracking mechanisms, using cookies, proprietary tokens etc. The problem with many of these is that they don’t constrain entitlements at all; a cookie is as good as a password because it really just linearly maps back to an original act of authentication.

OAuth formalizes this process but adds in the idea of constraint with informed user consent. And this, ladies and gentlemen, is why OAuth matters. In OAuth, you exchange a password (or other primary security token) for a time-bound access token with a limited set of capabilities to which you have explicitly agreed. In other words, the token expires fast and is good for one thing only. So you can pass it off to something else (like Twitter) and reduce your risk profile or — and this is the key insight of OAuth 2.0 — you can just use it yourself as a better security session tracker.

The problem with OAuth 2.0 is that it’s surprisingly hard to get to this simple idea from the explosion of protocol in OAuth 1.0a. Both specs too-quickly reduce to an exercise in swim lane diagram detail, which ironically runs counter to the movement towards simplicity and accessibility that drives today’s Web. And therein lies the rub. OAuth is more a victim of poor marketing than bad specsmanship. I have yet to see a good, simple explanation of why, followed by how. (I don’t think OAuth 1.0 was well served by the valet key analogy, which distracts from too many important insights.) As it stands today, OAuth 2.0 makes Kerberos specs seem like grade school primer material.

It doesn’t have to be this way. OAuth is actually deceptively simple; it is the mechanics that remain potentially complex (particularly those of the classic 1.0a, three-legged scenario). But the same can be said of SSL/TLS, which we all use daily with few problems. What OAuth needs is a set of dead simple (but nonetheless solid) libraries on the client side and equally simple, scalable support on the server. This is a tractable problem and it is coming. It also needs much better interpretation, so that people can understand it fast.

Personally, I agree in part with Eran Hammer’s wish buried in the conclusion of his blog entry:

“I’m hoping someone will take 2.0 and produce a 10-page profile that’s useful for the vast majority of Web providers, ignoring the enterprise.”

OAuth absolutely does need simple profiling for interop. But don’t ignore the enterprise. The enterprise really needs the profile too because the enterprise badly needs OAuth.

July 20th, 2012

Returning from #CIS2012

Francois Lascelles at Cloud Identity SummitCloud 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 into the trees. This is weird given this week’s proclamations that SAML was dead. Although we won’t be rid of SAML anytime soon, I do look forward to enterprise adoption of 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 Platformication 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.

July 6th, 2012

OpenID Connect: Live Tech Talk July 10 9am PDT

OpenID ConnectOur Tech Talks strive to focus on the most interesting and relevant API Management topics for both developers and publishers. And as new and evolving protocols emerge, we want to provide a forum for developers and publishers alike to discuss these protocols in an open discussion forum. So with that in mind, our next Tech Talk will focus on OpenID Connect.

OpenID Connect is an emerging standard that adds federated authentication to OAuth 2.0-enabled systems. It’s a suite of lightweight specifications that provide a framework for identity interactions via RESTful APIs. And in its simplest deployment, OpenID Connect allows all types of clients including browser-based, mobile and javascript to request and receive information about identities and currently authenticated sessions.

So, it’s a relatively simple protocol that helps make authenticating complicated scenarios easier. And let’s be honest – simple and easy are always welcome when it comes to securing RESTful APIs. Authorization and authentication are now available using only one technology. This makes life easier for anyone looking to secure their APIs.

But of course, questions always arise when discussing the various implementation scenarios for OpenID Connect. That’s why we’re excited to welcome Senior Software Developer Sascha Preibisch as our special guest for our July 10 Tech Talk Tuesday. He will answer any OpenID Connect questions you may have – so get those questions ready and join us on July 10 at 9am PDT.

Here’s how to join the discussion:

Click here to get a reminder in your calendar.

On the day of the event, join on Livestream or Facebook:
»  livestream.com/layer7live
»  facebook.com/layer7

Tuesday, July 10 | 9am PDT | 12pm EDT | 5pm BST

Submit your questions:
Tweet using the tag #Layer7Live
Email techtalk@layer7.com
Check in & Chat through Facebook

June 21st, 2012

Mobile-Friendly Federated Identity: Part 2 – OpenID Connect

 

The idea of delegating the authentication of a user to a third-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 the provider exposes an API that returns information about the 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 that takes an OAuth access token as its input and returns a simple JSON structure containing attributes about the user, authenticated as part of the OAuth handshake.

Request:
GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG

Response:
200 OK
content-type: application/json
{
“user_id”: “248289761001″,
“name”: “Jane Doe”,
“given_name”: “Jane”,
“family_name”: “Doe”,
“email”: “janedoe@example.com”,
“picture”: “http://example.com/janedoe.jpg”
}

In Layer 7′s SecureSpan Mobile Access Gateway OpenID Connect implementation, 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 the variable ${session.subscriber_id} as its input. This variable is automatically set by the Layer 7 OAuth Toolkit as part of the OAuth access token validation. You could easily look up 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, at the time of writing, OpenID Connect is a moving target and the specification is subject to change before finalization.

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.