With the latest release of ForgeRock OpenAM in November 2013, there is 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. As for this article, we’ll focus on OpenAM as an OAuth 2.0 authorization server, and the business value of this implementation.
Assume you rock up at the fancy restaurant with your $200k sports car and hand over the car key to the 18 year old valet tasked to drive it off to the parking lot a block away. Somehow you wish you could restrict the performance of your car, to drive below a certain speed, not allow access to the trunk and glove compartment, not to use the built in communication package to make outgoing calls, and only to travel a certain distance.
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” to 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 application in 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:
- Resource Owner
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. - Resource Server
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, in the case of flickr.com. - Client
An application that makes protected resource requests on behalf of the resource owner and with his 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). - Authorization Server
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 the business puzzle and why it can be 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 motive of driving top line revenue. Companies like Amazon, Netflix, and even Sears 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 serves to address these security issues and provide 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 easier and in a standardized way, cuts costs, saves money and brings applications to market quicker.
Further Reading
- The OAuth 2.0 Specification - http://tools.ietf.org/html/rfc6749
- http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/admin-guide/index.html#chap-oauth2
- http://www.wired.com/insights/2012/12/when-the-answer-is-oauth-what-was-the-question/
Inga kommentarer:
Skicka en kommentar