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


source: https://apigility.org/apigility-documentation/img/auth-oauth2-web-server-app.png



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. 


Cheers
     

Comments

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 grant Implicit grant Resource owner credentials grant Client 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) tokens SAML 2.0 Bearer Assertion Profiles JSON Web Token grant I would like to focus on