Demystifying the OAuth 2.0 Workflow: A Step-by-Step Guide in 10 Simple Steps

“Simplicity is the ultimate sophistication.” — Leonardo da Vinci

Photo by Job Moses on Unsplash

OAuth 2.0 has become a widely adopted protocol for authorization, particularly in the world of web and mobile applications. The protocol provides a standardized way for third-party applications to access user data without requiring the user to provide their login credentials directly to the application. This is accomplished through a series of steps. I recently listened to an old tech talk by Nate Barbettini, who was explaining Oauth in simple terms. There are lots of documents around this topic on the internet, which often creates confusion between authentication and authorization. OAuth is used for Authorization.

Why we need OAuth 2.0

In today’s interconnected world, users often find themselves using multiple web and mobile applications that require access to their personal information or data. This information can range from basic user profile details to more sensitive data such as financial information or health records. Traditionally, the only way for a user to grant access to this information was by providing their login credentials directly to each application, which presented significant security risks. With OAuth 2.0, however, users can grant permissions to third-party applications to access their data without disclosing their login credentials.

What exactly is OAuth 2.0

OAuth 2.0 is an authorization protocol that allows users to grant limited permission to their resources on one website or application to another website or application without giving away their credentials, such as username and password. An application lets a user authenticate themselves with the help of a third party server, without accessing their credentials, while getting the scope and user info from the third party server in a secure manner.

Before we proceed further we need to understand some basic terminologies related to OAuth workflow.

Client : The application which requires access to a resource. It will be identified using a client id.

Resource Owner: The owner who owns the data that the application is trying to get, normally identified using a email-id. The resource owner owns the piece of information, which client is trying to access.

Authorization server: The server which performs the authorization and decides whether the client can access the resource owner data.

Resource server: The server which hosts the data which the client wants to access. Sometimes both resource and authorization server are running from the same server.

Authorization grant: The permission that user has consented to share their data in resource server with the client.

Redirect(CallBack) URI: When the authorization server redirects back to the client to this URI. This is one of the configuration information which the client passes to the authorization server.

Access Token: The token provided by the authorization server to the client to access the permitted data from the resource server. Access tokens are sometimes called Bearer tokens and is included in the Authorization header of an http request.

Response Type: Another configuration information which the client passes to the authorization server, which refers to the type of Authorization grant the client needs from the authorization server. eg: Code,

Scope: One more configuration information which the client passes to the authorization server. It consists of a list of permissions which the Authorization server understands. The Client can pass the list of scopes required to the Authorization server. The User then provides an authorization grant to this list of permission. eg:- contacts.read, email.write etc

Consent: Then page which is generated by the authorization server with the list of scopes requested by the client. It will show the list of permissions which the User can allow the client to access.

How does it work

How can an application access the user data which is available in another website, without sharing the user credentials needed to access the data. This problem is solved using delegated authorization.

Let’s consider an imaginary webapp called “Sample WebApp” and assume that it is using Google as the 3rd party application for authorization.

Resource Owner: user
Client: “Sample WebApp”
Authorization server: accounts.google.com
CallBack URI: sample_webapp.com/callback
Resource server: contacts.google.com

For the client to delegate authorization, it needs to perform some initial steps with the authorization server. It needs to create a Client with the Authorization server to get a Client Id and Client secret.

The user gets the page below to login to the application.

What happens next is the OAuth Workflow.

Below are the steps which happens during a OAuth workflow

1. Client provides a login page for the user to connect with the Authorization server to login.
2. The User is redirected to the Authorization server with the configuration parameters set by the Client.
3. User gets a login prompt and provides the username and password.
4. User is presented with the consent page from the authorization server, which mentions the client -“Sample WebApp” needs access to Public Profile and contacts. Do you allow — “yes” or “no”. (Authorization grant)
5. When the user selects “Yes” on the consent page, the authorization server redirects to the Redirect(CallBack) URI for the client along with the response type requested. If “Code” is the response type, it passes the authorization code back to “Sample Web” app.
6. Client (“Sample WebApp”) application connects to the authorization server to exchange the authorization code with the Access token. It shares Client Id, Authorization code and a client secret.
7. Authorization server (accounts.google.com ) validates the authorization code to make sure the Client (“Sample WebApp”) is valid. Client encrypts the authorization code with a secret which client was pre-configured with the authorization server.
8. Authorization server provides the access token to Client (“Sample WebApp”). This token will have a expiry time defined.
9. Client (“Sample WebApp”) can now go to the Resource server (“contacts.google.com”) with the access token (Bearer Token) to get the profile and user contacts.
10. The Resource server will validate the access token and provide the required data as permitted in the access token (Scope) to the client.

The dotted lines mentioned in the diagram is referred to as Back channels in network terminology which contains some sensitive data and is encrypted using a secret, and is communication between servers. The other normal lines refer to the communication between browser and server called Front Channels.

Conclusion

OAuth has become the industry standard for secure, delegated access to APIs. Its popularity is largely due to its flexibility, ease of use, and strong security guarantees. I hope you get a basic understanding of the steps involved for OAuth workflow. In my next article I will be writing about OpenID connect, which is a small layer on top of Oauth, enabling Authentication. It will be an interesting one to discuss. If you like this article do follow me for the next article.

Reference: Talk by Nate Barbettini about Oauth 2.0 in OktaDev YT channel