Tuesday Jan 15, 2013

A Look at OAuth2 - A Follow-Up to the Reader's Comments

Originally posted on Phil Hunt's blog IndependentID

On my last blog post on Oracle IDM, Marc asks some very good questions that deserve a longer response:


Here's where I get confused about OAuth2. I keep hearing you don't need crypto (which is often where developers get so tripped up on other federation protocols) but how do you securely have a self contained token without crypto? You mention signing a token, but isn't that crypto? If you are relying solely on transport security does that mean all connections need to be HTTPS mutual authentication to be viable?


Let me break this up into a couple of paraphrased pieces:

1. If you do not use crypto, how do you securely have a self-contained token without crypto (aka bearer token)?

In OAuth1, the algorithm, usage and signing instructions were narrowly defined (probably limiting the life of the spec). OAuth1, assumed all communication would be insecure and therefore the access token itself needed to be secure. This required each client developer to implement the specifications MAC token in order to access services.

In contrast, OAuth2 the assumptions are reversed. Communication are secure, so tokens do not need to be self-securing (as MAC tokens were in OAuth1). OAuth2 opens the door to using simple bearer tokens (RFC 6750) to access services. OAuth2 assumes that because the issuing process is secured by TLS, the mere possession of a valid token is sufficient to authenticate or rather maintain the session relationship with the client.

With that said, there are still many scenarios where stronger ongoing authentication of the client is important to improve security. For a larger discussion on this, check out the current OAuth2 WG Security draft which discusses these issues.

2. Does this mean all connections must be HTTPS mutual authentication to be viable?

TLS Mutual authentication is useful, but is not required. OAuth2 allows the client application to be authenticated through other means such as client secret, a JWT, or SAML assertion. One of the problems with TLS mutual authentication is when TLS terminates before the server (e.g. in a load balancer), the server may not be able to access the client's authentication with the load balancer.

Let me first qualify that not all communication needs to be secured in all cases. Let's look at the two main endpoints that are being communicated with. The Authorization Server (aka Token Server), does require that at least server-authenticated TLS be enabled for all communication. In the case of a Resource Server, server-authenticated TLS is not required but SHOULD be used when using tokens without crypto (aka bearer tokens).

Thanks for the questions. Please keep them coming!

Standards Corner: A Look at OAuth2

Last week, the IETF published RFC 6819 (http://tools.ietf.org/html/rfc6819 ), a Threat Model document that describes extended security considerations for OAuth2. Having had a hand in drafting that document, some have asked, what's my feeling on OAuth1? What new features does OAuth2 bring over OAuth1?  Should customers use OAuth1?

Let me just say that Dick Hardt gives a great summary of the origin and inspiration for OAuth1:

The inspiration for OAuth was to standardize how users authorize a site or application (the client) to access data at another site (the resource server). Clients wanting to access data on a resource server would ask the user for their credentials so that they could call the API or scrape the site – a horrible practice from a security point of view.

Flickr, Microsoft, Yahoo! and others came up with flows that allowed the client to redirect the user to the resource server to authorize release of the users data and then get a token to make API calls instead of the user’s password.

Each of these solved the same problem in a slightly different way and client developers had to learn each mechanism and terminology. Many say a need to standardizing the best practices to discourage the falling back to asking for the user’s password and OAuth was born.

One of the design decisions in OAuth 1.0 was to not require SSL. While lowering the barrier to developers by not requiring SSL was admirable, it effectively meant the developer had to implement crypto. While this was wrapped up in libraries and it would usually work – when it did not work – or worse – worked intermittently – it was difficult to debug. I know.

I won't get into the full history, but I encourage you to read Dick's blog post here: http://dickhardt.org/2012/10/oauth-2-0/#more-161

Dick sums up OAuth2's 3 most important enhancements:

1. Simplicity: Client developers don’t need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.

2. Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.

3. Separation of roles: if the token is self-contained, then the resource can verify the token independently of the authorization server. Resources don’t have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security contexts.

From an enterprise perspective, the choice is very clear. OAuth2 gives the flexibility needed to cover enterprise authorization scenarios and goes much further to eliminate the password anti-pattern if done correctly. In particular, point 2, is surprisingly important. It enables important bridges with SOAP based services and SAML infrastructure.

So, should customers go ahead with OAuth1 support? My recommendation is no. OAuth1 is likely too narrowly defined for most customer use cases and requires too much risk that client developers can implement OAuth1's MAC tokens correctly. OAuth2 on the other hand has had substantial implementation and review. Coupled with the Threat Model document capturing a lot of the working group experience, this newly ratified protocol comes ready with a strong set of best practices.

The OAuth2 WG is currently working on new functionality and some new token types. Such as dynamic registration (of client applications), token revocation, as well as a new JSON Web Token (JWT) which is essentially a JSON version of SAML tokens. These drafts represent new functionality for OAuth2 that add new capabilities that address features like federated resources and client-bound (HoK) tokens. None of these efforts change the core OAuth2 specification. So, if you are wondering, is OAuth2 ready to go? The answer is yes!

About the Writer:

Phil Hunt joined Oracle as part of the November 2005 acquisition of OctetString Inc. where he headed software development for what is now Oracle Virtual Directory. Since joining Oracle, Phil works as CMTS in the Identity Standards group at Oracle where he developed the Kantara Identify Governance Framework and provided significant input to JSR 351. Phil participates in several standards development organizations such as IETF and OASIS working on federation, authorization (OAuth), and provisioning (SCIM) standards.  Phil blogs at www.independentid.com and a Twitter handle of @independentid.

Previous Posts:

2012: No Time to REST for the Holidays


Oracle Identity Management is a complete and integrated next-generation identity management platform that provides breakthrough scalability; enables organizations to achieve rapid compliance with regulatory mandates; secures sensitive applications and data regardless of whether they are hosted on-premise or in a cloud; and reduces operational costs. Oracle Identity Management enables secure user access to resources anytime on any device.


« January 2013 »