In “Attention, IT Pros: You Can Help Evolve a Secure Cloud, Too,” I emphasized how important it is for businesses to support open Internet identity standards and to require their vendors to support them. I'm long overdue to bring a couple of relatively new, very important identity frameworks to your attention. Why should you care? These new frameworks—OAuth 2.0 and OpenID Connect—are the “Kerberos of the cloud.” As with Kerberos, even if you don't explicitly develop code using them, you must at least know how they work in order to support your users: Those users are utilizing mobile and cloud apps with increasing frequency.
We all know the problem with passwords. In case you've just come back from a dogsled run to the North Pole, all you need to do is ask your family … or friends … or neighbors … or a random stranger on the street. We have far too many user IDs and passwords. We can't keep track of them, and so we make them very simple so we can remember them. Then we reuse these simple passwords across many websites in an effort to lessen the confusion. (Be honest: How many of you have perfect password hygiene? If you can't do it, how can you possibly expect Aunt Sally to get it right?) This situation is made worse by what's known as the "password anti-pattern," in which we've been conditioned to uncritically enter our user ID and password whenever we see a credentials prompt. This makes it easy for malware to prompt the unsuspecting user, and thus get identity information. In May, Google developer evangelist Tim Bray got on his knees and pounded the floor, pleading with developers not to require him to create yet another user ID and password for every new website.
This situation is made worse with mobile devices. The difficulties of entering credentials are magnified on the smaller form factor; it's harder to type in passwords on small keyboards (and if you're old enough, without putting glasses on). Thus, it's much more difficult to type in the strong passwords you're supposed to be using. Once inputted, these passwords are often stored insecurely on the device. Then devices get lost. And how many people use PIN codes or some other kind of lock on their devices? A 2011 survey by Confident Technologies found that fewer than half of mobile device users lock their device.
Fortunately, OAuth 2.0 is available to help with your password pain, especially for mobile apps. An IETF proposed standard, OAuth 2.0 is technically an "authorization framework." But a better description I've heard is that it's an "authorization-centric," flexible protocol that also supports authentication.
Generally speaking, OAuth 2.0 uses the Get a token, use a token methodology, as you see in Figure 1. A user (more specifically, an application on a user's full or mobile client) wants to gain access to a resource protected by the resource server. To authenticate to the resource server, the client must include an access token in its communication to the server. This token is provided by the authorization server. In other words, the client gets a token from the authorization server, then uses the token to authenticate to the resource server, thus gaining access to the resource. You can see how the OAuth 2.0 client credentials flow bears a passing resemblance to the Kerberos credentials flow.
My Standard Is Better Than Your Standard: Open Standards Confusion
A number of very visible OAuth 2.0 examples are at work today. If you choose to log on to a web app (e.g., Twitter, Tripit) using your account from an identity provider (e.g., Google), watch the authentication process carefully and you’ll see URLs that contain oauth. The OAuth logo itself might even briefly pop up. In his hilariously titled “Is that a token in your phone in your pocket, or are you just happy to see me?” slide deck, Brian Campbell explains how OAuth 2.0 works with mobile clients, and Ping Identity offers a white paper entitled "The Essentials Of OAuth" (registration required) that provides a very clear overview.
I mentioned that OAuth 2.0 is more flexible than Kerberos. It's also more complicated to implement. The It's an authorization protocol!/It's an authentication protocol! debate is just one aspect of the confusion. That’s where OpenID Connect comes in.
OpenID Connect is a simple identity layer on top of OAuth 2.0. It's a specification that organizes how identity providers and relying parties can use OAuth 2.0 to communicate identity data to one another, without having to fill in the blanks of many OAuth implementation details. The spec adds identity details and inserts a number of default values, which makes the OAuth implementation easier. It also standardizes OAuth configurations across different implementations, which aids interoperability between vendors. By easing developer pain, the hope (and it seems to have been borne out in practice) is that more developers will use OAuth 2.0 to provide secure authentication. In her article “OpenID Connect: New, groovy and full of promise,” Pamela Dingle provides a good overview of how it works, and Oliver Pfaff delves into the details in his “OpenID Connect—An Emperor Or Just New [Clothes]?” slide deck.
Good to Know
In February, Gartner predicted that half of new identities on retail sites will be based on social network identities (e.g., Facebook, Google, Twitter, Microsoft) rather than identities created directly on the retail site. This can only happen with a common method to easily and securely provide identities from IdPs to SPs to authenticate with, and OAuth 2.0 and OpenID Connect seem to be the most popular.
If your daily job doesn't require you to work with external identities, learning about OAuth 2.0 and OpenID Connect is simply a good idea—a bit of knowledge to tuck away for future use. If your company works at all with consumer identities, these two identity frameworks will have some part in your future. Take this introduction and related links, and dig deep enough so that you can judge how they'll impact or empower your job.