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

Comments:

Phil,

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 soley on transport security does that mean all connections need to be HTTPS mutual authentication to be viable?

Thanks
Marc

Posted by Marc on January 15, 2013 at 10:50 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

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.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
3
4
5
6
7
8
11
12
13
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today