By Tanu Sood on Jan 15, 2013
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:
for 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 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.