Demystifying OAuth 2.0: Front Channels, Back Channels, and Secure Logins

There was a time when sharing your contact list with a new app meant doing the unthinkable: handing over your actual email password. Before 2010, the web relied heavily on these simple, risky logins or older protocols like SAML to share data between services. OAuth 2.0 fixed this by introducing delegated authorisation. Instead of giving away your password, OAuth 2.0 allows you to safely grant third-party applications scoped access to specific data, keeping your underlying credentials completely hidden.

One of the example when on earlier days when the sites needed data from other service.

Few of the problems in the above flow is

• Credential Exposure: The user had to hand over their actual login credentials directly to the client application.
• Over-privileged Access: By possessing the master password, the client application gained full, unrestricted access to the user's entire account, rather than scoped access strictly limited to contacts.
• No Granular Revocation: The only way for the resource owner to revoke the client's access was to completely change their master password.
• Storage Vulnerabilities: The third-party client often had to store the credentials in plain text to maintain persistent access, creating a prime target for data breaches.

To solve this massive security flaw, the industry standardized OAuth 2.0 in 2012, officially documenting it under RFC 6749. While the OAuth 2.0 framework outlines several different paths / flows , to achieve delegated authorisation, this post will focus exclusively on the most common approach for web applications: the Authorisation Code flow. I will cover the other grant types in future blogs.

Authorisation Code flow

At a high level the RFC works like:

1. User Clicks on my-site to sync the contacts from the google
2. The user is redirected to accounts.google.com to perform normal Google authentication.
3. The user is presented with a consent page.
4. Once accepted, the user is redirected back to My-Site.
5. My-Site now has permission to access the user's contacts.

There are few terminologies we need to keep in mind when working with OAuth 2.0

1. Resource Owner : It's the user who owns the data in google.com in above flow.
2. Client: Client is the site who needs some data from the google.com
3. Authorisation Server: In the above diagram the authorisation server is accounts.google.com. It is responsible to issue the authorisation token and access token.
4. Authorisation Grant: The authorisation server generates a token that proves the user the has accepted the consent.
5. Redirect URL: Once the authorisation grant has been generated it needs to be transferred to the my-site. The place where the redirect occurs is
6. Access Token: Once grant is received using redirect url, the callback handler in the my-site backend, uses it to get the access token. The access token then can be used to access the actual resources.
7. Resource Server: The server which holds the actual data. In the above diagram contacts.google.com is resource server. In some cases Authorisation server and Resource Server can be same as well.

If I zoom in the above flow diagram it would look something like

Securing the Channels In the diagram above, Steps 5 and 6 represent the token exchange, but before examining those details, we must address client authentication. The authorisation server must be able to verify the client's identity to prevent malicious actors from intercepting tokens.

This requires a one-time setup: the developer must register the application with the authorisation provider to generate a client_id and a client_secret.

When redirecting the user to the authorisation server, the client includes the public client_id in the request. Later, when making the backend call to retrieve the access token, the client must send both the authorisation code and the client_secret. Validating this secret guarantees the token request originates from the legitimate application.

Why authorisation code and access token ?

A common point of confusion in OAuth 2.0 is the necessity of the authorisation code. Why doesn't the authorisation server just return the access token directly to the application? The answer comes down to security and the difference between communication channels.

To understand this, we need to divide our architecture into two distinct parts:

• The Front Channel (Browser): This represents the user's web browser. While generally secure, the front channel is vulnerable to certain risks, such as network interception or rogue browser extensions manipulating traffic. We trust the front channel, but only to a certain extent.
• The Back Channel (Server): This refers to the highly secure, controlled environment where your backend application code runs.

Because of the inherent risks in the browser, the front channel is strictly used to receive a temporary authorisation code. This code is then passed to your backend. Finally, the back channel safely exchanges that authorisation code along with your hidden client secret to retrieve the actual access token.

Implicit Code flow

Just before we close out , I want to quickly explain the Implicit flow. It feels very similar to the Authorisation Code flow, but it cuts out the middle step. Instead of sending an authorisation code that your server has to exchange, the authorisation server just hands the access token right back to the browser. Operating strictly in the front channel, this method is used primarily for Single Page Applications (SPAs) and static sites where you don't have a secure backend to do the heavy lifting.

Why a Hash Fragment (#)?

This is a clever security feature of the web. Browsers do not send anything after the hash (#) to the server. The access_token remains strictly within the user's browser (the Front Channel) where your JavaScript application can read it and use it to make API calls.

However, because the token lives entirely in the front channel where it could potentially be intercepted by rogue extensions or malicious scripts, the Implicit flow is generally considered less secure than the Authorisation Code flow.

While the Implicit flow was the standard for SPAs for a long time, modern security best practices now often recommend using the Authorisation Code flow with PKCE for SPAs, which acts as a dynamically generated, one-time secret.