OAuth2.0 for dummies — Introduction to OAuth2.0
Content
In this article, I expect to cover the following facts.
- What is OAuth2.0 ?
- OAuth2.0 authorization flow (from user’s point of view)
- OAuth2.0 Authorization Flow (actual operation)
What is OAuth2.0 ?
Before we dive into OAuth2.0 Authorization flows, we will first rush through what OAuth2.0 is and why it is important for us to learn.
OAuth2.0 is an Authorization protocol which is widely used in the industry today. If you ask the question “What’s an Authorization protocol?”, I’ll be in trouble. But in case you do, here’s the simple answer.
We daily use applications which require us to obtain data from other applications that we have ownership of. Let’s take an example scenario. Bob needs to use an online dating application which wants to take some basic information such as his profile picture, birthday, sex, education and occupation from our facebook account. This is a very convenient method to provide information to the dating app instead of filling out forms, but it’s also risky, since facebook accounts can contain other sensitive information which we wouldn’t like to expose to others. Therefore, Bob wants the dating app to only retrieve the information that he allows.
OAuth2.0 is a protocol or predefined set of standards which can be used in such a scenario. There are 4 main roles in OAuth2.0 basic authentication flow. Client application, Resource owner, Resource server and Authorization server.
In our example scenario, these roles map into the following entities.
But I’m altering the previous scenario a little bit, to separate the roles clearly.
- Client application — Dating app
- Resource owner — Bob
- Resource server — ‘Personal Info’ app, which contains information about Bob
- Authorization server — WSO2 Identity Server (I’ll explain who this guy is)
Authorization server is simply the intermediary which regulates the OAuth2.0 flow and ensures Bob that the authorization flow will be carried out responsibly.
I omitted the use of facebook in our example, since facebook has the functions of both resource server and authorization server, which will confuse you when trying to understand the flow clearly.
OAuth2.0 authorization flow (from user’s point of view)
Now we have identified the roles of OAuth2.0 protocol, relative to our example scenario. Now we will see how a user sees this flow from outside. Later we will dive into what’s happening inside. The following are the steps.
Let’s assume that WSO2 Identity Server has already been installed in the environment, and the dating application is already registered with WSO2. In case this sentence doesn’t make much sense, I will explain it later.
- Bob opens the dating application
- Bob sees 2 options to provide the app with personal information (Fill out a form, Obtain information from ‘Personal Info’ app)
- Bob selects the 2nd option
- Bob is shown a login page saying ‘WSO2 IDENTITY SERVER’ on the top, with fields ‘Username’ and ‘Password’ to fill
- Bob logs in, giving his WSO2 credentials
- Bob is prompted with a page similar to the following image which asks Bob’s consent to give the dating app to receive the information (profile picture, birthday, sex, education and occupation) from his ‘Personal Info’ app profile.
- Bob clicks “Approve”
- Then the dating app processes his information and finds him a suitable companion before valentine’s day! Rest is history.
OAuth2.0 Authorization Flow (actual operation)
Now that we understand how the user sees this flow, it’s time to dive into how this operation works from the inside. For this, we need to use a flow diagram from the original specification of the OAuth protocol. (You will find more decent diagrams if you just googled. But I wanted to keep the originality).
Some words may be gibberish to you. Well that’s why I’m writing this article!
Let me explain.
- A : When Bob opens the application and selects the option of retrieving information from the ‘Personal Info’ app, the client (dating app) sends an ‘Authorization Request’ to the resource owner (Bob). Bob then enters his WSO2 credentials, logs in and gives his consent to retrieving certain data.
(This process preferably goes through the authorization server (WSO2) although it is not mentioned specifically in the above diagram. This will be explained in a later article.)
- B : Then the client receives an authorization grant, which contains a credential (code) that can confirm the authorization of the resource owner. There are several types of authorization grants. If the authentication fails, the client receives an error code.
- C : The client presents the received authorization grant to the authorization server (WSO2), which processes the authorization code.
- D : After processing the authorization code, the authorization server sends an access token, which contains information about what information the resource server should provide for the client. Optionally, a refresh token can be also sent.
(A refresh token is a token which can be used to obtain a new access token when the previous access token is expired.)
- E : The client presents the received access token to the resource server (‘Personal Info’ app)
- F : The resource server processes the token and provides the client with the requested resources (profile picture, birthday, sex, education and occupation). If the token is invalid or erroneous, the client will receive an error code.
This is the basic high-level view of the OAuth2.0 authorization flow. More information about the grant types and the grant flows are required to obtain a more detailed understanding of the flow. I hope to cover those details in my next article, on obtaining authorization from the resource owner.
