With the latest release of OpenAM in November 2013, there has been a lot of talk about OAuth 2.0 and how OpenAM can act both as an OAuth 2.0 authorization server and as an OAuth 2.0 client for installations where the web resources are protected by OpenAM. In this post, we’ll focus on OpenAM as an OAuth 2.0 authorization server, and the business value of this implementation.
Imagine yourself pulling up to that swanky party in your $200k sports car. Now imagine handing over the keys to the 18-year-old valet tasked with driving it off to the parking lot a block away. Wish you could restrict the performance of your car a bit, do you? Allow it only to drive below a certain speed and travel a certain distance, prevent access to the trunk and glove compartment, and restrict use of the built-in communication system to make outgoing calls, perhaps?
The solution to this is of course a valet key, designed specifically for this type of situation. Now, the same situation exists for the modern web. As a user, you might want to share certain resources and capabilities from one service with another, but not the full shebang; nor do you want to provide the credentials for your social media sites to third parties.
This is where OAuth 2.0 comes in. OAuth 2.0 is an open standard for access delegation and authorization without the need to explicitly share password information. OAuth 2.0 allows providers of services to share a “valet key” with a third party, that allows limited access to services, possibly with an attached time constraint. In other words, OAuth 2.0 provides the mechanism for clients to access resources on behalf of the user or owner of those resources. The end user can select or authorize third-party access to resources, without ever sharing any secret credentials such as the username and password.
In simpler terms, OAuth 2.0 empowers people to perform delegated authorization on their own.
The above concept is, of course, nothing new and is seeing more and more uptake across the modern web, where businesses wish to expose their APIs and share information with third party applications in a secure manner.
In the world of OAuth 2.0, there are four roles that are defined in the standard:
An entity capable of granting access to a protected resource. When the resource owner is a person, he is referred to as an end user.
The server that hosts the protected resource, capable of accepting and responding to protected resource requests using access tokens. The resource can be anything–for example, photos on flickr.com.
An application that makes protected resource requests on behalf of the resource owner and with his/her authorization. The term “client” does not imply any particular implementation characteristics (for example, whether the application executes on a server, a desktop, or other device).
The server that issues access tokens to the client, after successfully authenticating the resource owner and obtaining authorization.
In addition to these four roles, two different types of tokens are defined by the standard:
Access Token :
Access tokens are credentials provided by the client to access protected resources. An access token is a string that represents an authorization issued to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server. The access token provides an abstraction layer, replacing different authorization constructs such as traditional credentials (username/password) with a single token that is understood by the resource server.
Refresh Token :
Although not mandated by the specification, access tokens ideally have an expiration time that can last anywhere from a few minutes to several hours. Refresh tokens are credentials that are used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.
OpenAM exposes a RESTful API that allows administrators to read, list, and delete OAuth 2.0 tokens. OAuth 2.0 clients can also manage their own tokens.
The Business Value of OAuth 2.0
Now that we have a rough idea of the purpose of OAuth 2.0, let’s look at how it fits into the business puzzle and why it is important to you and your organization.
More and more frequently, organizations are exposing their own APIs to attract third party developers who can take advantage of the organization’s services to build apps and widgets, with the ultimate goal of driving top-line revenue. Companies like Amazon, Netflix, Sears, etc do this to attract intermediaries who can connect buyers with themselves as sellers, and create convenient ways to transact.
For this strategy to work, however, a certain level of trust must be established between the parties involved. Identity is an important piece of this puzzle and it is imperative that organizations secure the exposure of services via APIs. OAuth 2.0 is a component of any Identity Relationship Management (IRM) platform, and addresses these security issues and provides a convenient way to deal with authorization.
From a developer perspective, (described by Ryan Boyd at Google), before the dawn of OAuth 2.0 inside Google, developers spent 80% of their time dealing with authorization in new applications. The ability to deal with authorization in a more simple, standardized way cuts costs, saves money, and brings applications to market faster.
The OAuth 2.0 Specification – http://tools.ietf.org/html/rfc6749