OAuth 2.0 is the next evolution of the OAuth protocol which was originally created in late 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification is being developed within the IETF OAuth WG and is based on the OAuth WRAP proposal.
OAuth 2.0 is a completely new protocol and is not backwards compatible with previous versions. However, it retains the overall architecture and approach established by the previous versions, and the same introduction (from the Official Guide to OAuth 1.0) still very much applies.
Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.
As the web grows, more and more sites rely on distributed services and cloud computing: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services.
The problem is, in order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else – often the same passwords used for online banking and other sites – it also provide these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.
OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.).
For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service. Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.
The new draft represents a yearlong discussion around goals and requirements for the protocol with participants from a wide range of companies including Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google. OAuth has long been the poster-child of rapid open technology adoption, and 2.0 is no exception – Facebook and Twitter already announced support even before the first draft was officially published.
Why a New Version?
OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s API Auth and Google’s AuthSub. The result represented the best solution based on actual implementation experience. With over 3 years of experience working with the protocol, the community learned enough to rethink and improve the protocol in three main areas where OAuth 1.0 proved limited or confusing:
Authentication and Signatures
The majority of failed OAuth 1.0 implementation attempts are caused by the complexity of the cryptographic requirements of the specification. The fact that the original specification was poorly written didn’t help, but even with the newly published RFC 5849, OAuth 1.0 is still not trivial to use on the client side. The convenient and ease offered by simply using passwords is sorely missing in OAuth.
For example, developers can quickly write Twitter scripts to do useful things by using their username and password. With the move to OAuth, these developers are now forced to find, install, and configure libraries in order to accomplish what was before possible with a single line of cURL script.
User Experience and Alternative Token Issuance Options
OAuth includes two main parts: obtaining a token by asking the user to grant access, and using tokens to access protected resources. The methods for obtaining an access token are called flows. OAuth 1.0 started out with 3 flows: web-based applications, desktop clients, and mobile or limited devices. However, as the specification evolved, the three flows were merged into one which (on paper) enabled all three client types. In practice, the flow works fine for web-based applications but provides an inferior experience elsewhere.
As more sites started using OAuth, especially Twitter, developers realized that the single flow offered by OAuth wasvery limited and often produced poor user experiences. On the other hand, Facebook Connect offered a richer set of flows suitable for web applications, mobile devices, and game consoles.
Performance at Scale
As large providers started using OAuth, the community realized that the protocol does not scale well. It requires state management across different steps, temporary credentials which are more often than not discarded unused, and typically requires issuing long lasting credentials which are less secure and harder to manage (and synchronize across data centers).
In addition, OAuth 1.0 requires that the protected resources endpoints have access to the client credentials in order to validate the request. This breaks the typical architecture of most large providers in which a centralized authorization server is used for issuing credentials, and a separate server is used for API calls. OAuth 1.0 requires the use of both set of credentials: the client credentials and the token credentials which makes this separation very hard.
So What’s New?
The following is a subset of the new features available in OAuth 2.0:
6 New Flows
- User-Agent Flow – for clients running inside a user-agent (typically a web browser).
- Web Server Flow – for clients that are part of a web server application, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0.
- Device Flow – suitable for clients executing on limited devices, but where the end-user has separate access to a browser on another computer or device.
- Username and Password Flow – used in cases where the user trusts the client to handle its credentials but it is still undesirable for the client to store the user’s username and password. This flow is only suitable when there is a high degree of trust between the user and the client.
- Client Credentials Flow – the client uses its credentials to obtain an access token. This flow supports what is known as the 2-legged scenario.
- Assertion Flow – the client presents an assertion such as a SAML assertion to the authorization server in exchange for an access token.
Native application support (applications running on a desktop or mobile device) can be implemented using many of the flows above.
Bearer tokens
OAuth 2.0 provides a cryptography-free option for authentication which is based on existing cookie authentication architecture. Instead of sending signed requests using HMAC and token secrets, the token itself is used as a secret sent over HTTPS. This allows making API calls using cURL and other simple scripting tools without having to canonicalize the request and sign it.
Simplified signatures
Signature support has been significantly simplified to remove the need for special parsing, encoding, and sorting of parameters. It also uses a single secret instead of two.
Short-lived tokens with Long-lived authorizations
Instead of issuing a long lasting token (typically good for a year or unlimited lifetime), the server can issues a short-lived access token and a long lived refresh token. This allows clienta to obtain a new access token without having to involve the user again, but keeps access tokens limited. This feature was adopted from Yahoo!’s BBAuth protocol and later its OAuth 1.0 Session Extension.
Separation of Roles
OAuth 2.0 separates the role of the authorization server responsible for obtaining user authorization and issuing tokens from that of the resource server handling API calls.
When is it coming out?
OAuth 2.0 is currently in development by the IETF OAuth Working Group. The latest draft is considered stable but with many features being changed or added. Partial support is already available from Facebook and Twitter. The final specification is expected by the end of the year.
No comments:
Post a Comment