Software Development

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:
  1. The user logs into their SaaS provider
  2. Your application is sent an Authorisation Code
  3. Your application uses the Authorisation Code to retrieve an Access Token
  4. The Access Token is used to retrieve the user’s private data
For some, such a high level overview will suffice but, if you’re like me, then you’ll want to understand some of the nitty-gritty of what’s going on.
Obtaining an OAuth 2.0 authorisation token if often referred to as the ‘OAuth Dance’ and in this dance there are three dancers or actors:
OAuth Actors
 
ActorDescription
UserThe user’s browser as controlled by a human user
TheAppThe webapp that wants to access the user’s SaaS Data
SaaS AppThe Software as a Service provider such as Facebook
The OAuth Dance
The table below describes the OAuth 2.0 dance in detail…
ActorDescriptionData
UserNavigates to TheApp in browser. TheApp in loading a page needs to ask for SaaS data
TheAppTheApp has no AccessToken for this User on this SaaS provider and can’t return the SaaS data.
It returns enough information to the User to allow him/her to request one.
authorize_url (The URL of the SaaS OAuth service)
redirect_uri
client_id (app key)
response_type: code
UserThe User contacts the SaaS provider asking for an Access TokenDoes a GET to the SaaS authorize_url passing the following params:
client_id: (app key)
redirect_url:
response_type: code
SaaSResponds with the User’s login page on the SaaS webapp
UserTypes in their Username and Password on the SaaS site and presses okay.POSTs back SaaS login details such as user name and password
SaaSThe SaaS provider asks user to confirm that TheApp can access their data.
It usually does this by presenting a small screen that asks something like: “Do you want TheApp to access your SaaS data?
This is REST so the following are carried through in hidden fields:
client_id: (app key)
redirect_url:
response_type: code
UserConfirms the above to the SaaSclient_id: (app key)
redirect_url:
response_type: code
authorize=1 (or YES)
SaaSThe 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)
UserDoes a redirect using the URL from the last step back to TheApp with a GET requestcode: (The authorisation code)
expires_in: (expiry time)
TheAppTheApp then calls SaaS provider using a POST to retrieve the Access Tokenclient_id (The App Id/Key)
client_secret?code? (The App secret code)
redirect_url
grant_type: authorisation-code
SaaSThe SaaS provider recognises the authorisation code and creates an Access Token.
It also revokes the authorisation code.
Returns the Access Token to TheApp
access_token (The prized Access Token)
expires_in (expiry time)
refresh_token
TheAppTheApp tells the user that the OAuth process has worked.
TheAppTheApp can now access the User’s SaaS data using a GET request.Passes Access Token as HTTP authorization header (or request param) For example:
https://graph.facebook.com/me/friends?access_token=AAAAAAITEghMWiBBlEC5OG… etc …eAVbjNnWjIlE
UserThe 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 are 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.
Reference: OAuth 2.0 Webapp Flow Overview from our JCG partner Roger Hughes at the Captain Debug’s Blog blog.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button