Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...

Monday, 2 July 2012

OAuth 2.0 Webapp Flow Overview

In my last few blogs I’ve been talking about accessing Software as a Service (SaaS) providers such as Facebook and Twitter using Spring Social. Some of you may have noticed that my sample code may have been a bit thin on the ground as I’ve being trying to describe what’s going on in the background and what Spring Social is doing for you.

So far I taken a bird’s eye view of OAuth defining it as the need for your application to get hold of an Access Token so that it can access your user’s private data from an SaaS provider without the need for your users to give your app their credentials. I’m concentrating on OAuth 2.0 and I’ve also hinted that before it can request an Access Token your app needs something called an Authorization Code, which it combines with its app secret.

This blog zooms in some more and hopefully explains what going on - at least in the case of OAuth 2.0.

One thing to remember about OAuth 2.0 is that there are six different flows covering different client scenarios such as the User-Agent flow and the Device Flow. This description covers the Web Server Flow for OAuth clients that are part of a web server application.

OAuth Steps in Summary

In summary, in the Web Server Flow, the following high level steps take place:

The SaaS provider does not immediately create Access Token, instead it creates an authorization code
and stores it for later before passing it back to the User. The Access Token can then be requested and generated using this code.

The SaaS provider passes the code to the User as part of an HTTP redirect (Status codes 3xx).

The redirect is to TheApp’s redirect_url and contains:
code: (The authorisation code)
expires_in: (expiry time)

User

Does a redirect using the URL from the last step back to TheApp with a GET request

code: (The authorisation code)
expires_in: (expiry time)

TheApp

TheApp then calls SaaS provider using a POST to retrieve the Access Token

The user now sees their SaaS data as displayed by TheApp in their browser

In the table above I've included many of the data parameters that are carried through from request to request, even though they aren't always needed at that point in the sequence. The thing to remember here is that for very practical reason a SaaS provider is a REST service and therefore doesn't maintain state between client requests.

A final point to note here is that all this takes place using SSL to ensure that keys, secrets, codes etc are hidden from prying eyes.

A really good way of seeing all this in action is to create a Hootsuite account and use it to access your Twitter, Facebook, LinkedIn etc data: all the screens popup in all the right places: probably a classic implementation.