Skip to main content

OAuth - Playing Ping Pong for Authorization

You probably would have heard the word OAuth more than a few times. Ever wondered what that is? do we use that at all?. Guess what we make use of OAuth almost everyday.I got the opportunity to learn about OAuth during my time at WSO2 Identity Server team. Here's the first step of conquering OAuth :)

What Exactly is OAuth?

Let me start with OAuth, OAuth solves the problem of allowing third party entities( eg: applications) to access a resource owner's protected resources without actually giving away your valuable credentials like passwords. 

Let's think of it this way. You have a facebook account(Assuming you have one :P) which is your protected resource and you are the resource owner. Now you get a little high and decide to try out one of these fancy Facebook apps that finds your soul mate. The app now becomes the third party application which requires access to read out your friend list from your profile which is the protected resource. Suppose you don't have Oauth or the application that does not make use of Oauth, the only way to get access would to give the username and password to the app which would give unlimited access to the app to just about do anything with your profile.

Doesn't it sound bad... Imagine a fake app impersonating one of your favourite fancy Facebook app, it can get hold of your password... Next day you wake up and you see loads of crappy statuses on your timeline. Basically give out your password to third party applications is a bad practice. Oauth was designed to solve this problem. Oauth and its internals is a broad topic which i think you need to explore on your own :)

A must watch

This video helped me a lot to understand the Oauth flow and its internals. It's a long video but well explained and by far the best i came across in YouTube. 

The big picture

Basically this is what happens, although this is just one flow/scenario of how Oauth is used, basically it should help you get the big picture. Now let's get back to that fancy app trying to find your soul mate. 

  • Now with Oauth, without asking for your Facebook password the app redirects you to Facebook page along with some parameters in the URL such as clientID(Something that helps Facebook to identify your soul mate app) and a callback URL(where to send you back after you deal logging in with Facebook) and a scope(what sort of access is requested ie. whether you allow it to read your status, post on behalf of you). 
  • If you not already logged into Facebook you would need to be logged in, but remember you are logging in to Facebook not giving the password to your third party app. 
  • After logging in successfully you would be prompted with a screen showing you the details about the third party app and the requested permissions by the app.
  • You will be prompted to allow/deny authorizing the app from getting the requested permission on your account.
  • Once you allow, Facebook will redirect back to the callback URL of your fancy soul mate app along with a special code called the 'authorization code'. Note that even now you fancy app doesn't have the access permissions to your account.
  • In order to to get the access to your account( rather your friend list) the app has to do a final step, this happens in the background without the user's intervention. The app sends its client_id, authorization code and client secret to Facebook to exchange the authorization code for an access token to your account.
  • The whole purpose of sending client id and client secret by your soul mate app is to authenticate itself to the Facebook, so that Facebook knows that it is indeed the app that has requested for a token. otherwise anyone with the client id of soul mate app can request for tokens on behalf by intercepting authorization code grants.
  • Once an access token is received by your soul mate app, now it can access your friend list on your behalf using the APIs provided by Facebook. With each API request the app will send the access token it got from your authorization.
  •  Of course this token has a expiry period and also you can revoke access rights quite easily. Imagine if you did not use Oauth and had connected about 10 third party apps using your Facebook account, the only way to revoke access to a particular app would be changing the your actual Facebook account password. Write you could change the password and deny access to that one troublesome app. But But what about the other 9 apps. Yeah you guessed it right... You need to go and give your changed password in each and every one of that 9 apps one by one.

"A picture speaks thousand words....."
Here's everything I said so far in one picture, well of course this isn't the soul mate app :P


Okay.... Now that you know a detailed overall picture about the Oauth flow. I will write a few more posts to fill up with what i learnt about OAuth during my time at WSO2 Identity Server team. 



Post a Comment

Popular posts from this blog

JWT Bearer Grant - OAuth2

Previously I wrote a post on my first step towards understanding OAuth. This post continues builds on that. OAuth has different types of flows targeting various scenarios or use cases. The main feature that differentiates each of these flows is the grant type.

What exactly is an OAuth grant type? An OAuth grant is something that a client application could exchange for an access token from an Authorization Server. An access token typically represents a user's permission for the client application to access the resources on their behalf
OAuth Grant Types The OAuth 2.0 core specification defines four types of grants,
Authorization code grantImplicit grantResource owner credentials grantClient credentials grant In addition to these the core specification also defines a refresh grant type.
There are few new additions to these as well,
Message authentication code (MAC) tokensSAML 2.0 Bearer Assertion ProfilesJSON Web Token grant
I would like to focus on the JSON Web Token Grant in this po…

Trying out OAuth2 Authorization Code grant with WSO2 Identity Server without the PlayGround2 App

The first thing I did after joining the WSO2 Identity Server team was to test the WSO2 Identity Server 5.2.0-beta pack. I had some experience playing around with OAuth so I started testing OAuth scenarios. I was able to test most grant types with ease. Then came the authorization code grant type. The usual way to test it was to setup the playground2 app and test. I wanted to look for an alternate way to test the Authorization grant type without setting up the app (partly because I was lazy to download tomcat etc. :P )

So with the help of my team member Pushpalanka, I found an alternate way to get an access token by simply using a browser redirect and a curl command. So I wanted to make a note in case someone wanted to do the same :)

1. First, log in to the Identity Server management console.
       the defaults are,
                  username = admin                   password = admin

2. Go to the Service Provider configuration page and create a Service Provide, let's say SP_lazy…

OAuth2 Authorization Code flow without client secret using WSO2 Identity Server

Quoting from

Single-page apps (or browser-based apps) run entirely in the browser after loading the source code from a web page. Since the entire source code is available to the browser, they cannot maintain the confidentiality of their client secret, so the secret is not used in this case. The flow is exactly the same as the authorization code flow above, but at the last step, the authorization code is exchanged for an access token without using the client secret.  Note: Previously, it was recommended that browser-based apps use the "Implicit" flow, which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written, the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow, such as using the state parameter. References: RedhatDeutsche TelekomS…