OAuth in plain English
If you are a developer or related to web security you must have heard the term OAuth. Most of us have heard the term but some of us don’t exactly understand what does it mean. Even if we understand we have lots of confusion related to the terminology. One online blog will say something and others will say different. In this tutorial, I will try to explain OAuth, its terminologies, and workflow related to it in plain English.
The Definition
OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP(s) service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account.
That’s a mouth full, right?
A little background
First of all, when I say OAuth, that means OAuth2, which is of course version two of OAuth. For now, forget about OAuth version one and just focus on OAuth2, version 1 is obsolete and no one uses it now.
Millions of years ago web uses only user login and password to log into websites. Each one has its own magic username and password for each user. That was OK at that time but then requirements changed with time. There comes the Social network. People don’t want to fill up lengthy forms to sign up for each website. They use their social network credentials to log in to websites they trust. Then mobile devices arrived. Security requirements changed, people wanted to use one single login to sign in everywhere and on every device. To the rescue here comes OAuth.
Basic Authentication
In basic authentication, we send login and password to the server which validates the credentials, sets the user session, and sends the session id to the client via cookies. With each subsequent call, the client sends back the session id from cookies to the server, and the server identifies the user.
OAuth is doing something else aka Token based authentication and to be fancy, cookieless authentication.
Commonly used OAuth terminologies
Before starting OAuth, we should first understand some terminologies used while describing OAuth. Here are some commonly used terminologies (aka Roles) related to OAuth and their common meanings.
- Resource Owner
- Resource Server
- Client Application
- Authorization Server
- Scope
- Token
Resource Owner is the user who owns the account. It’s the user with a login name and password.
Resource server is the server where actually user’s data is placed. Like accounts, profile data, etc.
Client application is the application to which the user is interacting to access his resources (Frontend application).
Authorization server is where user login and password are saved and it will provide the access token.
Scopes are the limited resources which are allowed to be accessed by the user, like accounts, email address, etc. (Don't worry about this).
Token is the strange lengthy string provided by the authentication server, which is actually used for authentication. Usually, the token is JWT (JSON web token).
OAuth Workflow
1: Application Registration
Before a client application can request access to resources on a resource server, the client application must first register with the authorization server associated with the resource
At registration, the client application is assigned a client ID and a client secret by the authorization server. The client ID and secret are unique to the client application on that authorization server. If a client application registers with multiple authorization servers (e.g. both Facebook, Twitter, and Google), each authorization server will issue its own unique client ID to the client application.
Whenever the client application requests access to resources stored on the resource server, the client application needs to send the client id to the authentication server. Why it’s doing that? to recognize the application.
During the registration, the client also registers a redirect URI. This redirect URI is used when a resource owner grants authorization to the client application. When a resource owner has successfully authorized the client application via the authorization server, the resource owner is redirected back to the client application, using the redirect URI.
2: Grant Code
Okay, now the user is trying to login using a third-party authentication provider like Facebook which uses OAuth. Users click on login with the Facebook button and the action begins.
The client application sends a request to the authorization server along with the client id. Using client id Facebook will recognize the app and it shows a popup screen to the user asking that application want to access your resources (only limited resources defined by scope, just remember this for now). The user presses the accept button, telling the server that yes I am willing to grant permissions. The authentication server will then send the response back using the redirect URI along with a code (grant code).
3: Get Access Token
After the redirection to the resource server, along with grant code, the resource server will again send a request to the authentication server along with the grant code and the client secret, which we have already saved when we register. You noticed this time it’s a server call, from the resource server to the authentication server.
The authentication server will receive the code and secret, performs validity checks, and respond back with an access token, which resource server then sends back to the client application and store it there for further use.
4: Send Token for Authentication
With all subsequent requests, this token will be sent to the resource server along with headers. The resource server will extract this token and checks if this is a valid token or not. Generally, this is referred to as the bearer token, which means the bearer of this token is an authenticated user. How JWT token validation is done, that’s a different topic and out of the scope of this article. Check this article for info about validating a JWT.
Front Channel and Back Channel
So that’s how it’s all done. You may be wondering why the authentication server sends a code back to the resource server which again contacts the authentication server for token and why not directly send back the token to the resource server. That’s where what we call the frontend channel and backend channel is involved.
The frontend channel is where a call is initiated from a client browser. It is less secure and can be tempered. On the other side, a backend channel is where calls are transferred server to server which is considered to be more secure.
Keeping that in mind first code is sent from a frontend channel and then the server sends back the code along with the secret to get the access token. In the following figure, the solid line represents the frontend channel and dotted lines represent backend channel
In the modern world, front end frameworks are widely used for creating single page applications. In that case, there is no backchannel involved. In that case, instead of sending the authorization code, the token is directly sent back to the frontend app. This is called implicit grant type.
Final Words
OAuth works perfectly fine and widely adapted but if you have noticed, we can only perform authentication using the provided token, there is no information provided about the user. To overcome this issue another protocol was designed, which actually is an extension of OAuth, and it’s called Open ID Connect. More on that later.
