Introduction to OAuth2.0

Dinanjana Gunaratne
5 min readJul 12, 2022

--

Based on my own experience & Nate Barbettini’s speech

OAuth 2.0 and OpenID connect were always elusive subjects to me until recently. For one I never had an interest in that, and secondly, I managed to go through my work without worrying too much about it as it mostly consists of the machine to machine talking. But it all changed with a bug I had to resolve recently.

Authentication and authorization are 2 different aspects of security. Authentication means the system can identify who you are. With authorization, the system knows what you can do. So there is a huge difference between these 2 aspects.

One way or another you may all have come across a small popup on your browser asking to grant permission to some website from one of your social media accounts. It can be your Google account, Facebook account, or Twitter account. It is not about login in with the social media account, but rather asking for permission over a set of user data. This popup will typically say it will like to access a few of the user information stored in your identity provider. This is OAuth 2.0. OAuth2.0 is not a protocol for authentication, rather it is a protocol for authorization. It lets users grant specific permissions to access their user information in an identity provider.

Typically authorization through OAuth2.0 involves a frontend flow and a backend flow. This can be limited to a frontend-only or back-end-only based on the selection of your token type. Now let's take a look at how OAuth2.0 works.
Below you see, that Slack provides an option to connect my outlook calendar to my Slack account. What will the outlook calendar app do? It will display my meeting information from the outlook calendar on slack, also from slack, I will be able to accept/reject meetings.

So,

  • Slack Outlook Calendar app can write and read information from the Outlook calendar
  • Slack Outlook Calendar app can write information into my Slack account

Therefore,

  • My Outlook identity should authorize Slack Outlook Calendar App to read and write information to my Outlook calendar.
  • My Slack identity should authorize the Outlook calendar app to read and write information to my Slack account

Now clicking on “Add to slack” will move to a prompt asking following permissions to be granted to the outlook calendar to use user information stored in slack. It will clearly state what the outlook calendar app can do on your slack account.

When you press allow, this will prompt you to log in with Microsoft if you are already not. Once you log in successfully, the user will be redirected back to the slack page.

Within these UI transitions and redirects, Slack authorizes the Outlook Calendar app to use the user data stored in Slack and Microsoft authorizes the Outlook Calendar app to use user data stored in Microsoft for this specific user. So there are two OAuth2.0 authorization flows in action. To learn more about OAuth2.0, let’s see how one of the authorization flow works.

Step 1

First, Outlook Calendar App redirects you to the Slack auth server to authorize the access. On a closer inspection of the URL, we can identify following query params.

  • client_id: SAMPLE_CLIENT_ID
  • response_type: code
  • login_hint:
  • state:
  • prompt:
  • scope: chat:write,commands,im:write,team:read,users:read,users:read.email
  • user_scope: users.profile:write
  • redirect_uri: https://slack.com/interop/ocalapp/slack/oauth/v2/callback
  • tracked: 1

When redirecting to the auth server, App specifies that it requires permission to manipulate user data in Slack. The requested permissions are described in the “scope” query param. Also, in the params, there is a param defining a URL called “redirect_uri”. This hints auth server, on a successful authorization from the user, the user should be redirected to that location. Another important query param is respons_type. It indicates that the App is expecting a code as a result of authorization.

Step 2

Users will be redirected to the Outlook Calendar App home page with the click of allow button. If you closely inspect the URL loaded in your browser, you can identify a few query params

  • code: AUTH_CODE
  • state:

Code is the result of the authorization from the Slack auth server. With the user authorization, the Slack auth server creates a token granting permission to scopes requested to handle user data. This token is passed to the Outlook Calendar app through the query param code. This code is short-lived. This is addressed in the next step and it is called “Token exchange”.

Step 3

This is the “Token exchange”. So far the authorization flow was primarily running on frontends with UI redirects. This is the only section of the authorization flow that exclusively happens on the backend. The Outlook Calendar App has a set of credentials that is issued by the Slack auth app. These credentials are client secret and the client id. So when the Outlook app receives the “code” it will call the slack auth server with these credentials and post the received auth code. The server will respond with an access token. The access token only has to be a string. There are no specifics available for that.

With the above step, the app receives an access token which it can use to call the slack APIs to read and update user information. And this is the end of the OAuth2.0 flow for auth code authorization.

There are 2 other ways of authorizing apps to use user data in other apps/services. Those are “implicit flow” and “client credential flow”. Users can pick these flows by specifying specific values to response_type in step 1. Implicit flow is a frontend-only authorization mechanism and client credential flow is a backend-only authorization flow usually reserved for machine-to-machine authorization.

You might question why the token exchange happens at all? We can keep using auth code received to call the APIs. But it is a security risk as it is vulnerable and is visible in front. That is why the code is exchanged for an access token as soon as possible.

So is OAuth2.0 an authentication protocol? NO, it is not. But isn’t it used everywhere for authentication? Yes. How? It is used with OpenId Connect and I will write about it next.

--

--

Dinanjana Gunaratne

Software engineer in the making. I blog tech and life experiences here. You’re in for a mix bag