Standards Corner: Basic Auth MUST Die!

Basic Authentication (part of RFC2617) was developed along with HTTP1.1 (RFC2616) when the web was relatively new. This specification envisioned that user-agents (browsers) would ask users for their user-id and password and then pass the encoded information to the web server via the HTTP Authorization header.

Basic Auth approach quickly died in popularity in favour of form based login where browser cookies were used to maintain user session, rather than repeated re-transmission of the user-id and password for each web request. Basic Auth was clinically dead and ceased being the "state-of-the-art" method for authentication.

These days, now that non-browser based applications are increasing in popularity, one of the first asks by architects is support for Basic Authentication. It seems the Basic Authentication "zombie" lives on. Why is this? Is it for testing purposes?

Why should Basic Authentication die?

Well, for one, Basic Auth requires that web servers have access to "passwords" which have continually been shown to be one of the weakest security architecture. Further, it requires that the client application ask users directly for their user-id and password greatly increasing the points of attack a hacker might have. A user giving an application (whether a mobile application or a web site) their user-id and password is allowing that application the ability to impersonate the user.  Further, we now know that password re-use continues to undermine this simple form of authentication.

There are better alternatives.

A better alternative uses "tokens", such as the cookies I mentioned above, to track client/user login state. An even better solution, not easily done with Basic Auth, is to use an adaptive authentication service whose job it is to evaluate not only a user's id and password, but can also evaluate multiple factors for authentication. This can go beyond the idea of something you know, to something you are, and something you have types of factors. Many service providers are even beginning to evaluate network factors as well, such as, has the user logged in from this IP address and geographical location before?

In order to take advantage of such an approach, the far better solution is to demand OAuth2 as a key part of your application security architecture for non-browser applications and APIs. Just like form-based authentication dramatically improved browser authentication in the 2000s, OAuth2 (RFC6749 and 6750), and its predecessor, Kerberos, provide a much better way for client applications to obtain tokens that can be used for authenticated access to web services.

Token authentication is far superior because:

• Tokens cleanly separate user authentication and delegation from the application's activities with web services.
• Tokens do not require that clients impersonate users. They can be highly scoped and restrictive in nature.
• The loss of a token, means only a single service is compromised where as the loss of a password compromises every site where a user-id and password is used.
• Tokens can be issued by multi-factor authentication systems.
• Tokens do not require access to a password data store for validation.
• Tokens can be cryptographically generated and thus can be validated by web services in a "stateless" fashion (not requiring access to a central security database).
• Tokens can be easily expired and re-issued.

RFC 2617 Basic Authentication is not only dead. It needs to be buried. Stop using it. You can do it!

Cross-posted from Oracle Fusion Blog.

Standards Corner: Tokens. Can You Bear It?

This week's post is all about tokens. What are the different types of tokens that may be used in RESTful services? How are they the same/different from browser cookies? What are access tokens, artifacts, bearer tokens, and MAC tokens?

If I asked you what are tokens used for, many of you would answer authentication. But there is a bit more to it than that. First, I'd like to point you to a post I wrote on my personal blog called "3 Parts to Authentication"

In this post, authentication is described as a process broken down into 3 parts:
1. Registration
2. Credential Presentation
3. Message Authentication

What's important here is that many often confuse the process of credential presentation with message authentication. Credential presentation is the process where a user or an HTTP client application demonstrate (with one or more factors), that the user or HTTP client application in question is the same one that was previously registered. Having successfully completed the credential presentation process, the authenticator issues a cookie or token which can be used for a period of time, as a means of message authentication -- creating a single-sign-on session.

Today's post focuses on step 3, using cookies or tokens to access web resources. In browsers, cookies are added to requests in order to allow web sites to perform message authentication -- in effect creating the effect of single-sign-on. HTTP client applications use tokens in much the same way. They pass tokens, given to them by an authorization server, in the HTTP Authorization header of requests to achieve the same thing cookies do for browsers. In the case of tokens issued by an OAuth2 Authorization server (as with Kerberos and others), we call these tokens "access tokens" because they are used to access web resources.

Broadly speaking, there are 2 categories of tokens web sites may accept: bearer tokens and proof tokens. Bearer tokens work very much like browser cookies. They can be a simple unique identifier (aka artifact), or they can be encoded strings that have meaning to the web sites they are intended for. However to the client, these cookies are just random (opaque) text strings that need to be passed to the web site in order to access a resource (message authentication). Because the client doesn't have to do anything but merely attach a bearer token to its request, bearer tokens are very simple for client developers to use. For more details on bearer tokens, check out RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage.

While bearer tokens are incredibly simple and easy to use, there is a downside. Any client that obtains a copy of the bearer token may use it. Simple possession is enough to access the web resource (hence the term bearer). So, a critical limitation of bearer tokens is they SHOULD NOT be used over plain HTTP since they can be sniffed and copied. Web sites, accepting tokens should consider whether there is a possibility that access tokens could be sniffed or otherwise shared and does that impose a risk. Because of this, the IETF OAuth Working Group is nowworking on requirements for Holder-of-Key tokens (aka proof tokens).This document describes in detail the kinds of problems that could be solved and attempts to get to a set of use case requirements for a final token specification.

Proof tokens require an HTTP client to perform some kind of calculation that shows that only it could have used the token (such as with a private key or other shared secret). In a HoK token, a client could be required to generate a request signature, and even add a counter in order to prevent play-back attacks in addition to simple proof of a client's right to use a token. An example of this is the MAC token draft. The OAuth2 Working Group is debating whether this specification should move forward or whether a simpler specification based on JSON Tokens (JWT) should be developed.

So, in many ways, tokens build on the experience industry has had for many years with browsers and single-sign-on cookies. Tokens wielded by HTTP clients accessing RESTful web resources achieve the same feature we've taken for granted with browsers. Bearer tokens are easy for most clients to use, but require secure connections when used to prevent sniffing. Proof/HoK tokens can be used to where web resources are either unprotected, or further proof of the right to use a token is needed.

Cross-posted from OracleIDM.

OAuth2: Is OAuth the End of SAML? Or a New Opportunity?

I mentioned in my year in review post that rather then spell the end of SAML, OAuth2 might in fact greatly expand SAML's adoption. Why is that?

The OAuth2 Working Group is nearing completion on the OAuth2 SAML Bearer draft which defines how SAML Bearer assertions can be used with OAuth2 essentially replacing less secure user-id and passwords with more secure federated assertions.

Before I describe how this works, here is some quick terminology:

• Resource Service - A service offering access to resources, some or all of which may be "owned" or "controlled by" users known as "Resource Owners".
• Resource Owner - An end user, who is authorizing delegated scoped access by a client to resources offered by a Resource Service
• Client - An application (e.g. mobile app, or web site) that wants to access resources on a Resource Service on behalf of a Resource Owner.
• Authorization Service - A service authorized to issue access tokens to Clients on behalf of a resource server.

While the resource service and the authorization service may be authenticated by means of TLS domain name certificate, both the client application and the end-user often need to be authenticated. In "classic" OAuth, you can use simple user-id's and passwords for both. The SAML2 Bearer draft describes how federated SAML assertions can be used instead.

A typical scenario goes much like this.

OAuth2 with SAML

1. Alice (resource owner) accesses a corporate travel booking application. 
2. In order to log into the corporate travel application, Alice is redirected to her employer's Identity Provider to obtain a SAML Authentication Assertion. 
3. Upon logging in to the Corporate Travel Application, Alice wishes to update her seat preferences with her selected airline. In order to do this, the corporate travel application goes to the authorization server for the airline. The travel application provides two SAML authentication assertions: 1) An assertion representing the identity of the client application, and 2) an assertion representing Alice. The scope requested is "readProfile seat". 
4. Upon verifying the SAML assertions and delegated authority requested, the authorization server issues an access token enabling the corporate travel application to act on behalf of Alice.
5. Upon receiving the access token, the corporate travel app is then able to access the frequent flyer account web resource by passing the token in the header of the HTTP Request. The Access token, acts as a session token that encapsulates the fact that the travel app is acting for Alice with scope read & seat update. 

This SAML Bearer flow is actually very similar to the classic OAuth 3-leg flow. However instead of redirecting the user's browser to the authorization server in the first leg, the corporate travel app works with the user's IDP to obtain a delegation (or simple authentication) assertion direct from the IDP. Instead of swapping a code in the second leg, the client app now swaps a SAML Bearer assertion for the user.

OAuth2's ability to leverage different authentication systems makes it possible for SAML to enhance OAuth2 security going even further to eliminate the propagation of dreaded user-ids and passwords in much the same way SAML did for classic federate web sign-on. Rather than making SAML redundant, OAuth2 has in fact increased SAML's utility.

Note: this post cross-posted from the OracleIDM blog.

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).

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!

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!

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

What's All This Plumbing For?

Johannes Ernst blogs "If the Open Stack Is Mere Plumbing: The Plumbing Of What?". That question seems surprising from one of the proponents of OpenID. I thought it was all about simple identity for blog comments? Seriously though, he has a point.

If we look beyond OpenID, I would have to say it is the plumbing of layer 7 of the network - Applications! So, while I was joking when I said that I thought OpenID was only for blog comments, I was serious too. That's what it was designed to do. But was OpenID designed for the enterprise, for consumer applications, for social networking? Not yet. Hopefully some day in the future.

Of course user-centricity, which used to be all the rage, is still very important. But at the end of the day for the "users", centricity is just another tool, one of the plumbing options. Real people interact with businesses web sites. Notions of OPs, InfoCards, RPs are just plumbing lingo.

No, the real action is with applications. This is what consumers, users, and business people think about when they interact with the web. For the few of us, we might obsess about how a web site is built, and does it support UX protocol. But for the vast majority, identity plumbing for its own sake, doesn't mean much. Its hard to define a business model because well, there is no business.

What are the services that applications really need from identity plumbing? How about vetting, verification, privacy, assurance to name a few. Are they being delivered now? Many applications not only do their own identity management, but these as well. I would argue that in large part, many of the needed identity services are ill-defined and missing. This is why major web applications will continue to make mistakes as they try to learn, by managing personal identity information in a standalone silo.

The question I have, as specialist in IDM standards, does the application layer have all that it needs? When do we move beyond specific protocols and plumbing debates and ask what are the application-centric requirements that are needed to compliment the user-centric developments, we've had to date?

Johannes. Thanks for a great question!

Kuppinger-Cole: Finally, An Open XACML API

Felix Gaehtgens of Kuppinger-Cole writes about his conversation with Prateek Mishra of Oracle, who indicated that Cisco and Oracle have posted a new XACML API to the OASIS XACML TC.

It was a “soft launch” that was announced at the Kantara meetings on Monday at Burton Catalyst (which very unfortunately, I missed). When Prateek mentioned it to me, it stopped me dead in my tracks, because I find it really significant news – a very important step towards flexible access control policy based on XACML.

Felix's article gives a great example of why Attribute Based Access Control (ABAC) is going to be the next generation of access control and why it will ultimately replace Role Based Access Control (RBAC).

In my opinion, this will be a space to watch closely. RBAC has always been a lot like physical building security guards. They are very good at protected the building entrances and exits; but when it comes to determining who should be able to go where inside the building, or who should be able to interact with whom, the building guard model quickly reaches limits. It is easy to see that one of the enforcement points in security architecture has to be within applications themselves. ABAC and the open XACML API will make this possible.

The Twitter Attack And Improving Application IDM

TechCrunch posted an article: "The Anatomy of the Twitter Attack" that details how an attacker leveraged use of search, social, and public email services to hack the Twitter corporate services.

...modern web applications have built out their own systems and policies that require a user to register and then manage their identities separately with each app. The identifier that most applications use is an email address, and it is this common factor that creates a de facto trust relationship between a user’s applications. The second factor is a password: a random string that only the user knows, is unique to each application, and in theory should take even a computer months or years to figure out if it started guessing. These two elements would work well enough for most cases, were it not for what is often the single weakest factor: human habit.

If you were looking for an example of why web applications should move towards supporting federated identity and identity management services rather than rolling their own identity management systems, well, this is the poster-child case.

Look at the front page of almost any web application and you will see hints at just how hopeless and helpless we are in managing our digital lives: “forgot my password”, “forgot my username”, “keep me logged in”, “do not keep me logged in”, “forgot my name”, “who am i?”. Features that were designed and built as a compromise since we are often unable to remember and recall a single four-digit PIN number, let alone a unique password for every application we ever sign up for. Each new service that a user signs up for creates a management overhead that collapses quickly into a common dirty habit of using simple passwords, everywhere. At that point, the security of that user’s entire online identity is only as strong as the weakest application they use - which often is to say, very weak.

The article is quite long, but is very worth while reading. It shows how one weak application can be used to weaken the security of another (directly and indirectly). In this case, password recovery at an unrelated email service was the vector that unlocked valuable information at Twitter according to TechCrunch. To be fair to the web sites mentioned in the article, this identity management (IDM) stuff is hard. Many have done a pleasing job that works well on their own for their user constituencies. But this article shows how hackers can use social attacks to leverage multiple sites together to gain an advantage.

As you may know Oracle's approach to IDM is to be application-centric, to focus in on the issues relevant to making secure applications. Products like Oracle Adaptive Access Manager, OAM, Oracle Identity Manager, (not the mention the entire suite) really go a long way to provide the tools needed for secure IDM infrastructure.

But Oracle, and the members of Liberty Alliance, and now Kantara are going much further to figure out a way to recruit more application developers to leverage identity services through a common set of secure middleware components and technologies that lowers development costs, improves privacy, and ultimately the security of applications and their users. To broaden this industry effort, Oracle and many others initiated a standardization effort called the Identity Governance Framework with Liberty Alliance. Together we also initiated development of a free and open-source API called "Project Aristotle" under openLiberty.org. This work is still in development, new participation and input are greatly welcomed!

IDM and the Enterprise Social

Not sure why I had not seen this before. But there is an interesting post on the Oracle AppsLab showing how my colleague, Clayton Donley build an iPhone app in his spare time that takes advantage of secure access to enterprise identity sources (e.g. directory) and leverage social networking information found in Oracle Connect, our internal social network service.

So, you can find people, and when you do, the app uses Connect API goodness to show you the person’s profile and Connect activity. The profile actually combines the person’s Connect and corporate directory profiles into a single view. Tapping the person’s phone number/s open the Phone app; tapping the person’s email address opens the Email app.

But wait, there's more!

Beyond all the contact stuff, the app also surfaces a lot of Connect’s functionality to your iPhone. You can view your network (Connections) and various activity logs, and you can reply and comment on items in your activity logs, by email and by OraTweet.

What is nice about this app is that it starts from a familiar paradigm: the lowly corporate address book. By using OracleConnect, the Oracle People app quickly takes you to new and interesting places by exploring the social relationships that naturally exist in an enterprise.

For example, I have been using Twitter (@independentid), and I have mixed feelings about the whole technology. I just don't need to communicate that broadly about what I'm doing (after-all, I have a blog). So the idea of enterprise tweets seemed strange. Oracle People and OraTweet have created another way to find out what others are doing in a very compelling way. OraTweet really boosts the ability to communicate and interact with colleagues around the world.

Talking IGF at the European Identity Conference

Felix Gaehtgens of Kuppinger Cole interviews Oracle's Dr. Prateek Mishra about IGF and its role in setting a foundation for privacy at this week's European Identity Conference.

Check out more interviews, and comments about the EIC here.

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.