New Draft for Enabling OAuth2 To Be Used for Authentication

In my last blog post, I discussed the issue of OAuth2 and authentication:  Simple Authentication for OAuth 2? What is the Right Approach? As promised, I submitted a draft to the IETF for discussion in Berlin at the beginning of the month. While the working group didn't get a lot of time in the meeting to talk about the authentication issue (it wasn't formally on the charter), the submission did receive quite a bit of discussion in the hallways and on the IETF OAuth WG mailing list -- some of which I have already addressed in my last blog post.

Since the Berlin meeting, I have reviewed the feedback and have submitted an update. Draft 01 is now aligned to be compatible with OpenID Connect. In other words:

• If you are a web  developer, and the only problem you want to solve today is "how can I use OAuth to authenticate my users?", the new User Authentication and Consent for Clients draft is intended to solve just that problem. 
• But, if you decide you want to add an attribute provider (user profile) services to your requirements, you can upgrade to the OpenID Connect drafts as an extension to authentication without impacting existing code.

The new draft also allows clients to request a minimum Level of Assurance (per NIST-800-63 or ISO 29115) for the authentication -- a useful feature if the clients would like the service provider to do a higher assurance authentication (such as a multi-factor or biometric) than it might otherwise normally perform.

My thanks to Tony Nadalin and Mike Jones of Microsoft for their contributions to this draft.

IIW XII: Adding Identity Information to OAuth2

IIW XII is coming up October 18-20, so I thought I'd share with you a couple of discussions I'd like to open at IIW. The first one is how best to add user identity or authentication information to OAuth2.

The OAuth Identity Information Problem
As many of you know, OAuth2 enables a process whereby a client application, as authorized by a user, is issued a "valet key" (a token) for accessing protected resources controlled by the same user at some resource site/service provider.

One limitation of OAuth "valet keys" is that client applications do not receive information about the authorizing user. From the client application's perspective, the authorizing person is anonymous unless the underlying resource API (e.g. a social graph API) can reveal information about the authorizing user. To date, this has been the typical technique used with Twitter and Facebook. But what if, instead of a social graph API, the resource being accessed by a client application is a bank account, a set of medical test results, or a set of photos? Obviously not all resource service providers provide identity information. What if there was a standard way for client applications to obtain information about the authorizing user?

OpenID Connect's Proposal
Members of the OpenID Foundation have already been working on this. OpenID Connect has been touted by many as an important addition to OAuth2 because it would define a way for an artifact to be passed to the client application that the client could use to obtain more information--or, so I thought. Instead, the current "connect" specification suggests that an ID_token be given directly to the client in addition to the resource access token that shares basic profile information. Is this sharing of information going to be acceptable to all OpenID Providers? Shouldn't there be a trust mechanism between client applications and identity providers (OPs)?

Further, the "Connect" specification seems to assume that only OpenID Providers would be used by a resource provider and its OAuth authorization server. What happens if resource providers want to use multiple types of authenticating services such as local authentication via LDAP or federation through SAML? It seems there is something missing with the current Connect proposal. We need a way for OAuth to hand off identity information while not mandating a single protocol solution. We need a way for multiple federation protocols to work at the same time in an OAuth based service.

While I liked the original idea of OpenID Connect, I think the hand-off between OAuth2 and identity sources needs to be more flexible.

Proposing an OAuth Identity Draft Discussion
A new IETF OAuth Identity draft that lays the foundation for resource sites to be able to share artifacts that enable clients to obtain identity and personal information seems to be needed. It would enable an open solution whereby resource sites could freely choose from the many types of identity providers out there. A core OAuth Identity specification could leave room for differentiated service approaches (e.g. session management) between OpenID, SAML or any other protocol, while defining the key inter-op/hand-off points with OAuth2. Based on such an IETF draft, individual protocol profiles could then lay out the details of how particular protocols such as OpenID, or SAML, or other APIs/protocols should work in relation to OAuth2.

Comments? Thoughts?

If you are going to IIW XII, I'll have a quick ppt with some thoughts on the issues to get the discussion going. Let me know if you are interested in contributing.

ps. Don't forget to register for IIW.

OAuth: Does it replace federation?

Today I received a question about OAuth and whether it replaces existing federation deployments. Would OAuth, WS-Trust, and SAML work together? The answer is no. In fact, OAuth is built to use any authentication system, local or federated.

Note: Coincidentally, Paul Madsen, also posted an interesting graphic that gives a swim lane view of OAuth's flow with an IDP. 

I discussed some of this in my earlier post "OAuth: Does it authenticate?" Instead of prescribing what authentication is possible with OAuth, the OAuth specification simply assumes that there is some form of authentication mechanism in place that is acceptable to the service provider. It could be local authentication (e.g. as seen on Facebook, etc), or federation from SAML, OpenID, etc.

Here are a couple of diagrams (click to enlarge) showing the use of OAuth with a federated IDP. In Figure 1, the client application "ClientApp" of an employee of "IndependentId Enterprise" wants to access a cloud application service hosted by cloudsvc.org. In step 1, ClientApp sends an authorize request to the cloud service via the smartphone browser to the endpoint:

https://cloudsvc.org/authorize/cloudService/independentid

The authorization service determines if the browser already has an authenticated Web SSO session with the user. If not, the authorization point determines the user's home IDP by looking at the original authorize URL. In this case, it indicates the authorization was for IndependentId.com. The user's browser is redirected to IndependentId's SAML IDP where the user authenticates and a SAML Assertion is returned (step 2).

Figure 1

In Figure 2, the Cloud Service Provider having received the users SAML Assertion and authenticating the user, determines by policy that all IndependentId users automatically grant access to the "CloudApp Service". In step 3, the authorization service then redirects the users browser back to:

clientApp://independentid&code=i1WsRn1uB1&

The phone switches to ClientApp and passes it the redirect URL which contains the authorization code. In step 4, ClientApp then uses the code, along with its own client_id and client credentials (e.g. client_secret) and obtains an access token. Finally, in step 5, the client app is able to access the CloudApp Service. Note that the ClientApp can continue accessing the service for as long as the access token is valid which may be minutes, hours, days, or permenantly depending on the security requirements.

Figure 2

There are lots more variations on this. For example, during the authorization request, the IDP endpoint may not be known. In that case a NASCAR style authentication process could take place. Also, in step 4, the token server could elect to return a refresh token. This allows the ClientApp to maintain a longer session with the service without having to re-authenticate the user. Meanwhile, access tokens still maintain a shorter lifetime forcing the ClientApp to silently re-authenticate and provide a refresh token to continue to validate the clients access over time.

OAuth: Does it Authorize? Yes, but much more

My previous post asked the question "Does OAuth do authentication"? In this post, I explore OAuth2 and its support of authorization.

When most people ask the question about whether OAuth2 supports authorization, you might be thinking in terms of today's authorization/access management/policy systems. But, as mentioned in my previous post, authorization here is within the terms of how HTTP defines it. A fairly low-level distinction that convolves authentication and authorization. To really answer the question we must look at how HTTP defines authorization. Then we can begin to look at the larger implications of how OAuth2 impacts authorization in a more modern, higher level view.

What is HTTP Authorization?

Consider authorization from the standpoint of HTTP/1.1 (RFC2616). Section 14.8 defines authorization as a user-agent providing an authorization request-header field with its HTTP request(often after receiving a 401 response). The value of the authorization field consists of

"credentials containing the authentication information of the user agent for the realm of the realm of the resource being requested."

It seems that the authorization header specified in RFC2616 is not really an authorization, but rather an authentication credential. But consider the time frame when RFC2616 was authored. In that timeframe, authorization was rather simplistic. Do you have an account? If so, you are 'authorized'. Note: I may be over-simplifying the specifications here, but I think it you'll see more clearly where this is going.

So what does OAuth2 do for authorization?

Classic web access management (e.g. Oracle Access Manager) support users who use browsers accessing protected web sites. Over time, the control exerted over what users could do has become increasingly fine-grained such is the vision with XACML. Yet, typically these systems involve end-users requesting web resources rendered in browsers, or distinctly there may be separate "service" managers (such as Oracle Web Services Manager) supporting WS-* based services over SOAP.

OAuth2 supports a range of new use case scenarios. Many do not directly involve a user or a browser, but rather define a client application acting on behalf of a resource owner's (e.g. the user) behalf using only HTTP to access REST based services in a lightweight fashion. From an authorization perspective, OAuth2 use cases introduce the new capability that client applications, each with their own identity, act on behalf of a users that own resources and can perform service calls with a specified "scope". In its simplest form, OAuth2 provides a means to identify and perform authorization of two security credentials: that of the user that owns a resource, and that of an application.

What credential relationships are supported?

OAuth2 enables most combinations of relationships and in theory allows for extensions define new ones. Currently defined are:

• A client app, who also has the resource owner credentials, acting on behalf of a resource owner (see Resource Owner Password flow).
• A client app obtaining user/owner authorization (see Authorization Code flow).
• An unidentified client (typically javascript in a browser) acting on behalf of a resource owner (see Implicit Grant flow).
• A client app acting using its own authority (see Client Credential flow).
• A relationship defined using an extension (see Extensions flow). For example, a client app using an externally generated SAML2 Bearer assertion. The SAML assertion defining what Identity and/or what rights are being expressed.

What about OAuth2 authorization goes beyond security credentials?

RFC 2616 together with sister specification RFC2617 (Basic Authentication) define a rather simple notion of "authorization" as simple rights corresponding to a single user account. In OAuth2, we have the possibility of 2 entities: a client app acting on behalf of a resource owner.

But, to further narrow the focus from specifically what a specific client can do can do in a particular credential relationship, OAuth2 introduces the notion of scope. Scope defines capabilities of a client application performed on behalf of the resource owner. These capabilities may be thought of as roles or entitlements within the resource API. Typical examples are of the style: readProfile, updateProfile, readStatus, updateStatus, readBalances, payBills, executeTrades and so on. OAuth2 says almost nothing about what the possible values of scope can be - it is entirely up to the site being protected to determine meaning. In theory then, it is possible to set very specific scope such as the right to access a very specific URL. But in practice, it seems the use of scope is usually defined by the underlying web service API as enabling simple "capabilities".

For a more in depth discussion on capabilities, check out Hal Lockhart's recent post on "The Property-Capability Spectrum of Attributes".

What forms of authorization can be supported by OAuth2?

OAuth2 systems can support any number of authorization systems so the types of authorization that can be supported are unlimited. However, because the end-result of an OAuth2 authorization flow is always an authorization token (aka access token) to be used in a subsequent operation, the types of authorizations that can be handled are limited to those decisions that can be calculated in advance. At the time of authorization in OAuth, remember that that actual resource has yet to be accessed, so no transaction is occurring.

As an example, consider that OAuth2 systems can clearly handle [actors and scopable actions bolded for emphasis]:

"CheckPayer may writeChecks for Phil"

vs. a contextual or transactional authorization decision of

"CheckPayer may write a check on behalf of Phil for $50 payable to Nishant now".

The latter decision will still have to be decided by a policy system within the context of the transaction rather then within the context of an OAuth2 authorization. The reality is the likely OAuth2 products will define a mix of "capability" style authorizations together with access management systems. Thus if, the first statement was known as "philCheckToken" embodies the right of a client to write checks for "Phil", then the transactional statement might be:

"philCheckToken writes check for $50 payable to Nishant"

We know that the client (identified by philCheckToken) is allowed to writeChecks for Phil. Now the transaction policy simply checks to see if Nishant is a valid recipient and if the amount is within policy (and potentially whether Phil has $50). In OAuth2, these authorization systems will work together to make in-advance "capability" assertions, together with applying fine-grained decisions in the context of actual transactions.

OAuth: Does it authenticate? Well...Yes and No. And that's a good thing!

I'm not kidding. OAuth itself doesn't seemed to be defined. It's not an acronym just a name. In fact the specification draft simply says:

The OAuth 2.0 Authorization Protocol

"OAuth" itself isn't spelled out in most places. Wikipedia says its "Open Authorization". But who knows. I can't tell you how many times this question comes up. But if you ask me, it doesn't matter and that is a good thing. Let's dive into the question of authentication...

Does OAuth authenticate users?

No. The answer here is clearly no. Not only does OAuth not authenticate users, but it doesn't have anything to say about user authentication. But hang on, see the next question...

Does OAuth accomplish user authentication?

Yes. The answer here is yes, but the method is indirect. If you read my post on OAuth flows, you will know that OAuth has an "authorization" step that requires users to authorize clients to act on their behalf. For OAuth, authentication then is a logical conclusion of authorization.

In order to authorize a client to act on behalf of a user, the user must be known.

For a user to be known, the user must be authenticated.

Therefore, if a user has authorized a client, they must have authenticated.

This logic flow is at the heart of OAuth's power. Because authentication of participants is a necessary requirement of authorization, OAuth doesn't have to say how authentication is accomplished. Because of this, OAuth can be integrated with all sorts of authentication systems and protocols such as: LDAP, OpenID, SAML, WS-Trust, WebSSO, etc - placing OAuth at the crossroads of identity.

Ok, so does OAuth authorize?

Now you're jumping ahead. That's the subject for the next blog post. Stay tuned.

OAuth Flows - Extended

Updated: Revised flow to add javascript implicit flow.

I received a lot of interesting comments on my previous post, "Does OAuth Have Legs". That post was about trying to understand what was meant by legs in OAuth. It included a useful diagram which I have since updated based on feedback. The revised diagram is available below (click to enlarge).

A couple of notes:

• The flows depicted are from the perspective of what a client app has to do to access a protected resource.
• The general consensus was that "legs" was meant to refer to parties and not the number of steps though co-incidentally, it was often the same. The consensus on the OAuth mailing list seems to be to now refer to, 2-party or 3-party flows.
• Each party has one or more "roles" as defined in OAuth: Resource role (the resource being requested), Token Service Role (the server issuing access tokens), and Authorization Service Role (the server that determines if the end-user has granted permission, and if not obtains it).
• The Implicit Request (OAuth v13, sec 4.2) is actually a dual-role request. It requires that the authorizing server also issue tokens. I have put this in a separate "dual-role" box in the diagram.
• There may be additional exchanges not shown in the diagram such as logging in the user in order to obtain authorization. These are not shown since they are out of scope of the OAuth specification and should not impact the client (i.e. because authorization is obtained from the user using an external browser).

Lightweight Web Services

There has been growing interest in a group of protocols, namely HTTP, REST, OAuth, and JSON, and how they can support web services. REST and JSON, have been around for a while, but one of the puzzling problems was how to handle authentication in REST especially for non-browser based clients using HTTP. So far the only options have been BASIC authentication or SSL/TLS mutual authentication. So far, neither of which have been adequate (but that's a whole other blog post). However, more recently OAuth2 emerged, and offers some possibilities - especially for access to user controlled resources.

Another reason for interest in these protocols has been the emergence of cloud services and smart phones. Instead of using traditional web services such as WS-*, cloud service providers are opting for lighter weight, more quick to implement approaches that focus on basic HTTP. Smart phones with increasingly popular 'app stores' and their obvious need to be lightweight also figure heavily in this surge in interest OAuth, REST, and JSON. It occurs to me that the common theme here is a drive towards something I'll call "lightweight web services".

Pragmatic cloud proponents argue that WS-* and other specifications like SAML, ID-WSF and so on have all become bloated and unworkable. They are just too much for application developers to handle. Why not get 'lightweight' and use specifications like the PortableContacts spec to transfer personal information? Traditionalists argue about security, privacy and other important aspects. In contrast, lightweight web services focus on transport layer security to do most of its work.

Are proponents trading off security, inter-operability, and flexibility for one-shot-at-a-time lightweight services? Let's take a look at the key technologies/standards that comprise lightweight web services so far and talk about some of the challenges/drivers going forwards...

HTTP is the foundation upon which Lightweight Web Services are built. The founding protocol on the web, HTTP is getting a new look as new application clients begin using HTTP rather than just browsers. Driven by social media and the emergence of smart-phone applications and cloud services, HTTP is now the foundation protocol upon which both browsers and application clients are accessing resources and services on the web.

REST has been around for a while. Before it was popular, early web systems used REST like calls in the 90s (before it was called REST). REST creates simple, easy to document APIs that are more URL centric that seem to be more friendly to developers. The emergence of social network APIs (e.g. the Facebook Graph APIs) are good examples. It seems that many developers would rather trade discovery based code generation (e.g. facilitated by WSDLs) for simple-to-read web site documentation and manual code writing against a simple REST API.

JSON or JavaScript Object Notation is the new XML. It enables simple results from REST based service calls to be returned to clients. From wikipedia...

"It is derived from the JavaScript programming language for representing simple data structures and associative arrays, called objects. Despite its relationship to JavaScript, it is language-independent, with parsers available for most programming languages."

OAuth2, originally a method of delegating authorization to access web services (typically used in social media), OAuth2 is quickly becoming a badly needed authentication/authorization services for non-browser web application clients. While browser authentication had quickly migrated from BASIC Authentication (defined by RFC 2617) to Forms based authentication supported by cookies, OAuth provides new browser-less client applications a needed method to authenticate to web services using the HTTP Authorization header.

Shaping Lightweight Web Services

Lightweight web services have come on so strong proponents have generated "need it yesterday" demand for features that aren't yet defined or standardized. Some features are critical and while others are debatable. At present, there is still no standardized authentication token suitable for non-browser web service clients; no signing and/or encryption of content (other than TLS); no concept of message handling and much more. Are we rushing to re-invent here because of the design to have a single tool for all jobs? Or is this just a case of building out REST services to a supportable, secure level of some sort?

The lightweight web has so far been a loosely associated set of technologies with some interesting design patterns in common. As enterprises are quickly joining the community, it seems important that lightweight web services gain a more formal status with discussion in a new working group.

I invite everyone to help further define what are Lightweight Web Services and to help define a WG to help steer the development of relevant IETF and non-IETF standards that make up lightweight web services.

OAuth: New Chain Grant Type

I posted a new Internet Draft, the "Chain" grant draft [now expired] today for the consideration of the OAuth2 working group. The specification defines a new grant type that enables an OAuth protected service to in turn act as an OAuth client to another OAuth protected service. The grant type allows the first server to exchange the current oauth access token for a new token valid on the target service. This grant type makes it possible for multiple connected services to interact in a message bus or chain.

Introduction

The use case for this proposal springs from inter-service communication or messaging scenarios. Currently many applications use SOAP based services, such as in WS-SecureConversation which have ways to handle authorization and identity propagation between service end-points.

Now, that REST is becoming popular, the question arises as to how to properly propagate identity without heavier SOAP messages. Since REST relies solely on HTTP, how do you pass identity assertions?

Aside: Note that I'm not saying REST is better or worse than SOAP, merely that REST needs a way to propagate identity just like SOAP.

OAuth seems to have some answers to this question by allowing services to use tokens to access protected resources. It also allows for SAML Assertions to be exchanged for OAuth bearer tokens. But what happens if multiple services are chained together in a bus? What happens when the next pairwise exchange that needs to occurs? The original user and/or SAML bearer assertion is no longer available.

As currently specified, the OAuth framework handles only one client-service pair relationship, it cannot handle multiple 'chained' service calls.

Let's take a look at the following scenario:

In the above picture, we see a user, accessing a web site that offers banking statement aggregation. The user, having previously authenticated to "Bank Svc" (the Bank), indicates to the Aggregator that they would like to include information from the Bank. The Aggregator site accesses the token service for the Bank. The Bank Auth/Token Service, takes into account the user context (UC), the client credentials (C1C), and a requested scope and if successful, returns an access token (AT1).

Note: for those paying attention, there is often a 3-legged flow involving the end-user, but I am simplifying for brevity.

Once the access token AT1 is returned, the Aggregator is free to access the Bank as authorized by the user and the Bank's Authorization Service.

So far, we have demonstrated a successful capability to access a REST based service using a token that embodies both a user context, a client context, and a scope. But what happens, as is common in messaging systems, if the Bank in turn wants to access another service provider (e.g. Trader). Since there is no longer any direct user involvement, can the Bank obtain an access token for the Trader service?

The Chain Grant Profile

In this scenario, the Bank is acting under some high level of trust with the Trader service. E.g. the Bank owns the Trader service. In this case, the Trader is willing to trust the Bank application to indicate that it has the authorization to work on behalf of a user. In this flow, the Bank application contacts the authorization service for the Trader, and requests an access token using a new grant_type called "chain". In the "chain" grant type, instead of passing a user context, or an authorization code, the client instead passes an access token received from the Aggregator.

In this flow, the Bank provides its own client context (C2C) for its application (now acting as an OAuth client), and the access token (AT1) that it received from the aggregator is included in a POST to the Trader authorization/token service. This allows the Trader's authorization/token service to either parse AT1 or contact the Bank's authorization service for more information. In this case, AT1 embodies both the original user context (UC) plus the Aggregator (C1C). After successful processing, the Trader authorization service issues AT2, which combines C2C and AT1 as shown below.

In multi-node scenarios, this process could be repeated indefinitely leaving a traceable security path to the originating user along a pair-wise trust path between services.

Token Issues

One thing the draft specification does not address is how the trader's OAuth authorization/token service is able to parse the bank's authorization token (AT1). This likely will be handled in upcoming OAuth token specifications standardizing formats and claims included in tokens.

As always...comments and feedback are appreciated.

**Update**
Unfortunately due to IETF policy, the chain draft has now expired. If anyone is still interested in seeing the draft, please let me know by commenting.

Does OAuth Have Legs?

Some folks have been asking, "what's all this stuff about legs in OAuth?" and "I don't understand the difference between 1, 2, and 3 legged OAuth?"

I have put together a flow-chart to try and show, from a client app perspective, what constitutes a 1, 2, or 3 legged authorization (click on image to enlarge).

Basically the rule of thumb is, each time you make a request response within the OAuth protocol, that is one leg. Note that in the diagram the [4.xx] numbers represent the relevant paragraph from the draft 13 specification.

[Update: Corrected diagram decision box,authorization box]

OAuth: More Than Just Delegation

It seems many are still looking at OAuth as simply a delegation protocol. I think it is much more. Let's take a moment and highlight some features that go beyond simple delegation, and get at some of the real value behind OAuth.

Authentication & The Password Anti-Pattern

One way to look at OAuth is that it is a "Proxy Authentication" system. It allows applications acting on a user's behalf (as a proxy) to access user-controlled or identity-centric services like your bank account, or your google docs account. Unlike most approaches today, OAuth does not use user-ids and passwords (the dreaded password anti-pattern). If you haven't heard it before, you should never share your password for one service provider with another. If you still aren't sure why this is a big deal, read the story on the recent Gawker Media Hack and how it spread to include multiple social media accounts.

In OAuth, applications have their own credentials (a 'client_id'). There are multiple ways for them to authenticate with a service provider. The client application obtains a token (with user consent) with which the client application can act on behalf of a user. Note the important distinction: the application does not become the user. The application is simply able to indicate that it is acting on behalf of a user for a particular scope of activity.

Separation of Roles/Rights/Entitlements

Consider a Financial aggregation site (there are several now) uses user-id and password to access a customer's bank account to aggregate information from multiple institutions. Because of the password-anti pattern, accessed banks have increased difficulty distinguishing the real customer from the aggregator service masquerading as the customer. Thus the bank ends up potentially giving full access to the aggregator which may not be desirable to the user. Because the aggregator needs to use the customer's user-id and password, the customer must place a lot of trust in the aggregator not to do bad things with their account.

The pattern of using a user-id/password means that service providers like banks, cannot easily distinguish customers from client applications. Because of this, the ability to set finer grained access rights is limited. I am somewhat simplifying here, but because OAuth uses both a client application credential (aka client identifier) and a token representing the user's scope of permission, service providers like banks, are able to set different access policies for client applications authorized by their customers.

OAuth creates the possibility for policy/access management servers set specific access roles/rights/entitlements for client applications acting on a user's behalf to access services. Now the bank can more easily limit the financial aggregator to only those operations authorized by their customer.

Flexible Session Lifetimes

We tend to think of a session as what happens when we log into a site using a browser. We perform some operations and then log out. In other cases we may already be logged in due to a long-lived cookie. The service provider site can also set a cookies that span multiple days or weeks. The lifetime of a login really depends on the nature of the service provider web site and the service being offered.

The typical pattern of user-in-the-browser sessions may not be optimal for client services and non-browser application (such as on a smart phone). For example, a photo printing service might only need one-time access to a set of photos. While a smart-phone photo browsing application would more typically have ongoing access since the application is in the control of the user.

OAuth uses a code/refresh token/access token system that enables 3 possible session lifetimes for a single relationship. It sounds complex, but let's boil it down...

1. When a user initially authorizes an application to have access, a code is issued (first lifetime). Typically this code is used one-time to obtain something called a refresh token or access token.
2. A refresh token (the second lifetime) is optional, but the intention is that it is kept for a longer term and allows the client application to obtain resource access tokens. Refresh tokens might typically last days or months.
3. Resource access tokens (third lifetime) are then used (often as bearer tokens) to access protected services. These tokens are typically short-lived (minutes/hours).

The effect is that client applications can obtain a long term access grant from the user, but the grant is constantly re-verified by requiring the client app to both authenticate to the service with its own credential, and reissue its resource access token (lasting minutes or hours).

While this seems like a lot of overhead, it really isn't. Once the refresh token is obtained, the client app only has to use the refresh token once to request an resource access token. At this point, the pattern is not that unlike a browser login followed by an SSO cookie being set. As with the browser SSO cookie, the client app uses the resource access token for each operation until it expires.

Revocation

One of the benefits of the approach of a refresh token and access token approach is it forces the client app to re-authenticate to re-verify its access fairly frequently. This is actually very important as it enables the possibility of revocation. If a user (or a web site) chooses to revoke an OAuth grant or authorization, the client application access is effectively terminated as soon as the current access token has expired. When the client application attempts to use its refresh token to obtain a new access token, the access manager will reject the request.

Revocation is a nice feature. It is probably one of the most under-estimated features of OAuth. If you use Twitter, or Facebook, check out your account applications settings page and you'll see what I mean. You'll see that you are probably already using OAuth extensively you'll be surprised at how many grants you have already given out!

OAuth: Emergence of Network Centric Identity

For 5 or more years now, there has been a push by many in the identity management industry to rally around the idea of user-centric identity. Why not give users complete control over information being shared between web sites? From a web service provider it should make sense. Why retain data if it could be provided easily by the user? It made a lot of sense. Thus user-centric identity was born. There was a lot of interest, but user-centricity has remained esoteric and hasn't really taken off...

At the recent IIW 11 meeting, Dick Hardt led a discussion on the decline of user-centric identity. The conclusion was predictable. Lack of big players with significant financial incentives, too many negative financial incentives, and finally launching with immature technology not able to meet security, functionality or usability requirements. But I'm not so sure that fully explains the issue.

Both InfoCards and OpenID had some great new thinking. They both evolved around the idea of either a single user-agent or a single identity provider. User-control was key to both offerings putting the user at the centre. Neither approach was accepted by the market except in limited ways. I think that a big part of the problem was a design that focuses on a single point of control or distribution - a centricity. Both of these approaches ended up creating functional "silos" that limit the ability to embrace the Internet. Though with good intent, I think they fell into the same trap that applications fall into when they manage their own security and identity management. The application works, but it is a limited use silo with potential elevated risk and management costs. Further as application silos get big, the pressure to bridge the silos has increased. As evidence of this look at social networking application today and the Google/Facebook API sharing debate.

A new option has emerged that may serve to rejuvenate user-centric protocols by adding a new capability - open authorization or OAuth. OAuth enables applications and service providers to access data with the permission of users. Instead of trying to solve data transfer and user authentication at the same time, the requirements are separated. Yes, data can still be transferred as part of authentication, but now, many more use cases are handled without needing the users to be present. Instead of just applying to typical data points about users (first name, last name, etc), OAuth enables access to services that are controlled by users. Much more powerful. OAuth in combination with OpenID, SAML, or InfoCards enables new network cases like photo printing services, game boxes, cell-phone applications.

OAuth brings forward the notion that too me is a multi-agent or network-centric approach that enables controlled sharing of personal information by parties with some level of independence. For example, a user can give a game-box a one-time token that enables it to access his online game profile automatically. No longer does the user need to perform complex authentication in a device that doesn't have a keyboard. Instead, the user enables the device to act as an "agent" on his or her behalf. In fact there are many use-cases now envisioned (see the Zeltsan use cases draft).

OAuth enables applications to have independent relationships with data providers by using tokens as proof they are working on a user's behalf. With OAuth, applications access each other's services while allowing access control systems to handle authentication and authorization and more importantly, as I outlined in my last blog post, it allows the authorization system to distinguish between an OAuth client and a user. The OAuth concept is important because it enables network-centric identity.

I am glossing over a lot of issues (like the security of tokens, which I'll address in later posts), but the essential point, is that OAuth enables users to authorize applications, devices, or web services to perform actions on their behalf. This can be done with the user present (browser based), and with the user absent from ongoing exchanges of information. This is done with tokens (bearer, holder-of-key, etc). The OAuth 2.0 draft describe several scenarios in which users can enable a "client" application to obtain an access token to access user-controlled information on their behalf. Example, a service like Mint.com can aggregate financial information from investment services or banking service; a photo printing service can obtain photos from flickr for 24 hours to allow it to print a set of photos. A Twitter client on an smart phone can have a long-lived token to allow a user to easily post and read updates from services like twitter.

In short, network-centricity allows users to form a web of relationships between service clients and service providers. In this approach, emphasis on private 'silos' are minimized and authorized shared access to authoritative information is emphasized. Because applications have easy access to authorized, quality data, the need to copy and retain information is reduced as network services are embraced and adoption is more likely.

IIW OAUTH Enterprise BOF: Session Management

Continuing the summary of the OAuth Enterprise BOF, I want to call attention to a discussion on session management and OAuth. While we didn't start off talking about it, we soon came to realize a key potential benefit–session management.

The group was looking at the issue of UI complexity and features like "Share" buttons–a user clicks on a "Share" button and passes a token on to friends and family members to share content such as photos. Is this an appropriate use of OAuth? Are there complex token handling and UI issues to resolve?

The conversation took a rather interesting turn when Chuck Mortimore (Salesforce.com) commented that there are some technical SSO and session management issues to be concerned about. Bob Blakley (Gartner) responded by saying, OAuth is being used to establish CORBA-like "associations" to handle the absence of session management. The idea being that OAuth enables a different form of re-authentication for token holders than would normally happen for a typical user.

Bob asked: Are we overloading session management on to OAuth?

Because OAuth gives applications an idea of a separate identity from the user, access control systems can make different access control decisions about an authorized agent (token holder) distinct from the user that authorized agent (token holder). The implication is that a OAuth agent application could have a different session life than the end user. In contrast to OpenID and other SSO approaches, activity can take place without the presence of the user.

In my personal opinion, whether intended or not, enabling authorized agent session management independent of user session management is OAuth's most powerful feature! It allows for agent specific access policies and independent session lifetimes that will work in far more use-case scenarios then currently offered in current Web SSO protocols where the focus is on solving user-present in the browser scenarios.

But there is some caution here. Bob quite correctly pointed out that the fact that people are doing this without it being intentionally designed may be good reason to be worried. The group agreed that though implementations seem to be handling it well, there is good motivation to work further on some good guidance on refresh and re-authentication issues within OAuth.

IIW OAuth Enterprise BOF: Scenarios Discussion

As I blogged earlier, it seems like it is time explore the idea of enterprise use of OAuth. Many folks chimed in via email and blog comments that they were interested in a group discussion. So, at IIW 11, folks from Gartner, Google, HP, Paypal, PingIdentity, Salesforce.com, VMWare, Oracle, and others got together for a series of sessions on OAuth at IIW.

Please note, the opinions here are my own and represent my impression of the discussion that took place. Hopefully I have not misrepresented anyones view here, if I have, please let me know. This post is not meant to represent minutes for the discussion but rather a summary. Minutes can be obtained here.

Nishant Kaushik (Oracle) started off by talking about the case of a personal banking/financial services aggregator site and the quandary that services like it present to the financial service industry and their customers. While a great idea, these types of sites currently require customers to provide their banking user ids and passwords to access financial information. Obviously there is a lot of risk for potential customers to share this information. But, it seems the biggest risk is that there is no way to differentiate the customer from the aggregator. The aggregator accesses banking information with the same rights as the customer. This forces the customer to take an undue risk and likely compromises the aggregators ability to gather a broad set of customers. For banks being accessed by the aggregator, the sharing of uid/passwords by their customers also brings a certain amount of risk.

OAuth provides a new way to handle this scenario that would enable these types of aggregators to avoid using private user-ids and passwords, and instead obtain OAuth "authorization" tokens with the permission of their customers, to access financial service information. The advantage? Well, for one, no re-use of passwords. But for Banks, a key advantage. The ability to to differentiate usage capabilities of individual 3rd-party applications as distinct from and approved by their customers.

Patrick Harding (PingIdentity) covered another scenario that actually may be even more familiar. Patrick described how web companies (such as banks, or retailers) often offer 3rd-party services to their customers. To-date, that has been done successfully using web single-sign-on (SSO) technology. When a web retailer hands off to a 3rd-party, a SSO token is used to transfer session information. However, that need is evolving to where the 3rd-party service provider needs to have access to services from the retailer on some ongoing basis, or beyond the current session with the user. OAuth presents an opportunity for the 3rd party site to obtain access rights, with the customer permission, to access retailer information about the customer on an as-needed basis.

Patrick also pointed out that for the enterprise, the OAuth token avoids having to give broad access to 3rd parties systems. Enterprises will prefer a delegated access model as could be offered with OAuth. While eliminating the uid/password anti-pattern is key, differentiated access management of 3rd parties acting on behalf of users is an even more important benefit of OAuth.

There was a general discussion that there are many cases where OAuth tokens are a useful way to obtain user consent for sharing of information between service providers (organizations). As usual, Bob Blakley (Gartner) made the point, more important here is the idea that the holders of valuable data, will retain their ability to ascent to particular clients service providers access data on behalf of users. This makes natural sense, since the above scenarios demonstrate the need by enterprises to be able to have access policy that differentiates capabilities of users/customers from those of 3rd party service providers acting on their behalf.

There was a lot more discussion that took place. Some of it very detailed, some on topics which I plan to blog on shortly. Stay tuned!

Update on Enterprise OAuth BOF at IIW

For those interested, the following sessions have been proposed for Wednesday at IIW 11 (tomorrow):

1. Introduction / level-set (Patrick Harding)
2. Client App credentials discussion (Chuck Mortimore)
3. Chaining, Can OAuth happend for Application access to directories/databases? (Phil Hunt)
4. The case for OAuth for Enterprises who already have SAML Artifact support. Discussion (Prateek Mishra)
5. Relationship to Kerberos (Thomas Hardjono)
6. Revocation/logout - Revocation of client credentials? Session logout and access token relationships (Axel Nennker).

Apologies if I missed any topics.

I also recommend Eric Sachs paper on OAuth Practices. This paper makes a fairly good case for why OAuth is important to enterprise customers and enterprise application developers.

Please feel free to pass this info to fellow attendees who you think might be interested!

Enterprise OAUTH and ChangeNotify at IIW #11

For those considering attending the Internet Identity Workshop 11 in Mountain View, California, here a couple of session proposals that may be of interest:

• Enterprise OAuth BOF - this is looking like it may be an all day session on Wednesday as lot of topics have already been proposed (email me or comment if you want the list). If you are interested in adding topics, please let me know by commenting below.
• ChangeNotify - an introduction and update on the SAML ChangeNotify specification. This proposal has proved to be an interesting way to handle updates between federated providers particularly for cloud services. We'll discuss why it is different and what the advantages are. While ChangeNotify is currently profiled for SAML, there has been a proposal to develop a notification protocol variant that is non-SAML specific. Your participation and input is greatly appreciated! If you have a preference for a specific day on this, let me know!

See you there!

OAuth And The Re-Emergence Of HTTP And Client Apps

As I mentioned yesterday, I've been doing a lot of thinking about OAuth and what it brings to "web" applications. Is delegation really a big deal? I think so. While social networking has developed this protocol and the enterprise community has considered its relevance, something else has been changing and will likely contribute to demand for OAuth. I'm talking about the re-emergence of the intelligent client application and of HTTP itself.

John Gruber puts forward an excellent theory on Apple, the evolution of browsers, and what he feels is the real Web 2.0 revolution.

Definitely some interesting food for thought.

How many times are you asked to enter user-id and passwords in these mobile applications? Delegation is one of the methods in which you can authorize a mobile application to access your data in a cloud application.

If intelligent mobile and desktop client applications are the next 'thing', then OAuth will be a key requirement for handling authentication of intelligent client applications in enterprise applications.

The Case for OAuth and Enterprise Software

I've been spending some time lately on OAuth and exploring its applicability for enterprise software and the cloud. To date, OAuth's use cases have been focused primarily on social networking. Yet customers are asking, will OAuth be useful? The answer, I believe, is YES!

But first, some background for those new to OAuth...

What is OAuth?

OAuth is an open authorization protocol used to allow 3rd-party desktop, mobile phone and web applications to access Internet services that are often accessed with a user-id and password or federated sign-on such as OpenID or SAML. The objective, is to get rid of the anti-pattern of asking users to provide their user-id and password to obtain data from a web site or service.

Why should web site owners care about OAuth?

To answer this, I'll suggest an excellent article by Eric Sachs, Product Manager, Google Security, on OAuth Practices. Eric lays out the case for why social networking apps need OAuth. Eric answers key questions like:

• What does [your company] get out of [OAuth]?
• What if startups are already pulling data from [your company] without [your] permission?
• What can [your] company do?
• What data should we make available via OAuth?
• and many more.

How did OAuth Originate?

According to Dave Recordon, OAuth was derived from several existing API authorization protocols originating from AOL, Flickr, Google, Microsft, and Yahoo!. Paraphrasing Dave, "The thinking was that building a unified approach to authorization it would reduce burden of implementing any one of these protocols and provide third party applications a more convenient and secure was to access user controlled data."

Work moved quickly and the 1.0 implementation was very successful. But, there was a problem. On the way to a formal IETF specification, a bug appeared that resulted in 1.0a revised specification to fix a threat. Eran Hammer-Lahav tells the story here about the "session fixation attack". The problem was corrected and was subsequently included in the IETF OAuth 1.0 draft (RFC 5849).

OAuth 2.0 - Under Construction

After OAuth 1.0, a new specification emerged called "Simple OAuth" or WRAP. The objective was to take the OAuth concept and apply it to a broader set of use cases. Very quickly both the 1.1 OAuth work and the WRAP work were merged into a combined draft as the IETF OAuth Working Group achieved agreement to work on a new 2.0 protocol. This work introduces many new use cases and protocol flows and is suggestive of a highly useful solution in a broad range of use cases.

OAuth and the Traditional Enterprise Software Market

At the start of this post, I mentioned that YES, I feel that OAuth will be important to the Enterprise Software Market. As with large social media sites, vendors of large enterprise software systems such as ERP, CRM, HCM, also have a community of third-party tools developers that want to integrate with enterprise applications.

At Oracle, I have already noticed the emergence of iPhone and Blackberry apps and the related discussions around the use of passwords in mobile apps. The password anti-pattern is everywhere in enterprise systems and it has to go! Mobile applications are just the first example of enterprise software demanding an OAuth type solution.

Emergence of Cloud Services

As you'll no-doubt have heard, Oracle made a number of announcements recently regarding supporting cloud computing. This has profound implications. As we talk about enterprise software deployed in the cloud, perceptions of risk change because in part, corporate firewalls can't be counted on as the first line of defence. Because the Cloud computing paradigm will put enterprise computing "in the cloud", the demand for 3rd-party application integration with enterprise systems is set to balloon!

Oracle and its competitors now have the same requirements faced earlier by the social networking communities supported by AOL, Flickr, Google, LinkedIn, Twitter, and Yahoo that pitched in their early support for OAuth.

Perfect Storm

The combination of steadily increasing enterprise security requirements, the evolution of user-controlled content, and the emergence of cloud computing represent a perfect storm of demand for OAuth in enterprise software. If OAuth 2 is successful, enterprise support won't be far behind - if not leading the way.

Next Steps

The Oracle Identity Standards team is beginning a phase of increased engagement in the IETF OAuth Workgroup to review and expand coverage of the spec to meet enterprise requirements. The OAuth 2.0 draft specification is definitely headed in the right direction. It seems clear it is time to help support the development of OAuth 2.

In light of this, I am recommending an OAuth Enterprise BOF meeting at the next IIW in Mountain View, California, on November 2-4. The objective will be to talk about whether there are any use-case/technical requirements that need to be addressed in the current 2.0 planned specification. Enterprise feedback needs to happen quickly if we are to make the 2.0 specification timeline.

Here's hoping you can make it!

Phil

UMA and OAuth 2 - First Impressions

I recently attended a briefing by Eve Maler, chair of the UMA Workgroup. As usual, Eve had lots of info to share, and I'd like to pass it on.

First, for those of you who don't know, OAuth 2.0, is a protocol designed to allow people to authorize one web service to access the resources of another web service. For example, allowing a photo printing service to access photos on Flickr.

UMA takes the concept of OAuth a step further and places the authorization server to a third party that works on behalf of an individual. By doing this, UMA take authorization from a resource perspective, and turns it into a consent server for users. That's pretty cool. So far, we've not had a good inter-site model for handling consent.

Where in the typical OAuth 2 deployment, user authorization and resource owner authorization are combined, UMA instead separates the processing of a user's consent, from authorizing access by the resource owner (e.g. Flickr).

Aside from the benefits Eve describes, here are a couple more things I like about the UMA proposal.

1. UMA recognizes that user information exists in many places on the Internet, and not just at a single IDP/OPs etc.
2. It supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.
3. It's a great way to separate the issue of user consent away from the resource owner's access control policy.
4. It becomes possible to handle consent when individuals are offline

The only downside I can see at the moment, is that the UMA Authorization server would get to know a lot about its users. What type of organizations would/could successfully offer UMA consent services? Any organization attempting this would have to have a strong privacy brand indeed. Monetizing private information would be a tough sell. Yet would users pay for the service? Anyway, not to worry, I'm sure someone will figure this out soon, if not already.

Will this be useful to the enterprise community? As with OAuth, I think so. This is an evolving space to watch.

Aristotle Project Wins Award

I am happy to announce that Project Aristotle won an award for "Best new or improved standard" at the European Identity Conference. The win is shared with the Open Authentication (OAuth) and the Information Card Foundation (ICF).

The European Identity Award for the category “Best new or improved standard” went to the Aristotle Project for ArisID, an important enhancement of IGF (Identity Governance Frameworks) and CARML, which enhances user-friendliness of these important standards for IAM and GRC. This particular innovation had been promoted and supported by Oracle. The standardization initiative OAuth (Open Authentication) receives an award for their streamlined approach for authentication standardization, which finds a lot of market interest. The last award in this category goes to the Information Card Foundation (ICF) for standardizing the important approach of Information Cards for future identity management.

Congrats to the contributors of openLiberty, the members of Liberty Alliance TEG, as well as my colleagues at Oracle, who all contributed to the effort. Congratulations to OAuth and ICF as the co-winners!

A special thanks to Kuppinger Cole for organizing the event and for taking the time to recognize the efforts of all the award winners and of standards development in general.