Understanding OAuth

Understanding OAuth (Image generated through ChatGPT)

 

Understanding OAuth

OAuth is an open standard for access delegation, widely used for securely granting access to resources on behalf of a user without sharing credentials like passwords.

Authentication and Authorization

Authentication (Who you are)

Authentication is the process of verifying a user’s identity. It answers the question: “Are you really who you claim to be?”

Example:

  • Entering your username and password to log into an account.
  • Scanning your fingerprint or face to unlock your phone.
  • Using a One-Time Password (OTP) sent to your email.

Analogy: Authentication is like showing your ID card at a club to prove that you are who you say you are.

Authorization (What you can do)

Authorization determines what resources or actions a user is allowed to access after they are authenticated. It answers the question: “What are you allowed to do?”

Example:

  • A regular user can view content, but only an admin can edit or delete it.
  • In a banking app, you can check your balance, but you need extra permission to transfer money.
  • A guest can browse a website, but only logged-in users can post comments.

Analogy: Authorization is like having a VIP pass at a club, just because you got in (authentication) doesn’t mean you can access the VIP lounge (authorization).

Why OAuth is needed

In the initial days when desktop application were not connected to internet, each desktop application managed its own login flow.

Once internet came into the picture, we started building web applications that followed similar pattern of each web application managing its own login flow. Over the time period, securing application became more and more complicated.

Next, when social media took over the world, there was a need for connecting different applications.

Example:

  • Users had Flicker (photo sharing site) account.
  • These users wanted to share photos on X (earlier Twitter).
  • Now X would need access to user's Flicker account.

This type of Authorization is called delegate authorization where you (resource owner) wants to authorize a client (X) to access your resources (photos on Flicker).

Imagine you’re at a restaurant and need someone to get your coat from the coat check. Instead of giving them your keys (password), you hand them a claim ticket (a token). The token grants specific, limited access to your coat—nothing else.

In the digital world, OAuth solves similar problems:

  • Secure Access: Lets apps access resources (like your Google Drive files) without sharing your credentials.
  • Granular Permissions: Provides control over what an app can access (e.g., only read emails, not send).
  • Revocability: Access can be revoked anytime without affecting the user’s credentials.

This need for Delegate authorization led to the development of the original OAuth (Open Authorization) 1.0 protocol with following high level goals:

  • No password sharing
  • Revoke access of application
  • Granular resource access

Latency versus Throughput

History and evolution of OAuth

  • Origins: OAuth was first proposed in 2007 to solve the problem of sharing data between services without sharing passwords. It emerged as a collaborative effort among developers from X (earlier Twitter), Google, and other platforms. It had few limitations like complex implementation, it was not designed for SPA (Single Page Application) or Mobile applications.
  • OAuth 1.0: Released in 2010, this version was secure but complex, requiring cryptographic signing.
  • OAuth 2.0: Introduced in 2012 to simplify the process and provide greater flexibility. It abandoned cryptographic signing in favor of HTTPS-based security mechanisms. OAuth 2.0 is now the most widely adopted version.

Now lets talk about important terminologies in OAuth 2.0

  • Client: The application requesting access to the protected resources on behalf of the Resource Owner. (e.g., a photo editing app)

  • Client ID & Client Secret: Client registered with Resource Server to get the Client ID & Client Secret.

  • Resource Owner: The user who owns the protected resources and can grant access to them. (e.g., you)

  • Authorization Server: The server issuing tokens after verifying permissions. (e.g., Google’s OAuth service)

  • Resource Server: The server hosting the resource. (e.g., Google Photos)

  • Callback URL (Redirect URI): The URL to which the Authorization Server redirects the Resource Owner after granting authorization. This URL is registered with the Authorization Server when setting up the Client.

  • Response Type: Indicates the type of response expected from the Authorization Server. Common type is:

    • Code: For the Authorization Code flow, used when the Client is a web server (more secure).

  • Auth Code: A short lived code which authorization server send to Client (via browser). Client's backend get Auth token by sending its client ID, client secret and Auth Code to Authorization server token endpoint.

  • Access Token: A short lived token used by the Client to access protected resources on the Resource Server.

  • Refresh Token: A long-lived token used to get new access tokens without re-authentication.

  • Scope: Specifies the level of access that the Client is requesting. In our example, this might be "post_to_wall" or "read_user_posts".

  • Consent: The Resource Owner's permission for the Client to access their protected resources, usually given through a consent screen.

  • Grant Types: Methods for a client to obtain tokens (e.g., Authorization Code Grant).

Grant types vs. OAuth flows: Are they the same?

No, Grant Types and OAuth Flows are different but closely related in OAuth 2.0.

Grant types (core concept)

Grant Types define the different ways a client application can obtain an Access Token from the Authorization Server. These are the methods used to request access.

Examples of grant types:

  • Authorization Code Grant – Secure method where the client gets an authorization code first, then exchanges it for an access token (used for web apps).
  • Implicit Grant (Deprecated) – Directly issues an access token in the URL without extra verification (previously used for SPAs, now replaced by PKCE).
  • Client Credentials Grant – Used for machine-to-machine authentication where no user is involved (e.g., API-to-API communication).
  • Resource Owner Password Credentials (ROPC) Grant – Allows the user to provide a username/password directly to the app, exchanging it for a token (only for highly trusted apps).
  • Device Code Grant – Used for devices with limited input (e.g., Smart TVs) where the user authorizes access via a separate device.
  • JWT Bearer Grant – Uses an existing JWT (e.g., from SSO or identity provider) to request an access token without user interaction.

OAuth Flows (Practical Implementation)

OAuth Flows are real-world implementations of the grant types, customized for different types of applications. These are the step-by-step process of how authentication and authorization happen.

OAuth Flows typically use specific Grant Types, but they may also include additional security mechanisms.

Examples of OAuth flows:

  • Authorization Code Flow (uses Authorization Code Grant)
  • Authorization Code Flow with PKCE (uses Authorization Code Grant + PKCE security)
  • Client Credentials Flow (uses Client Credentials Grant)
  • Implicit Flow (now discouraged, used Implicit Grant)
  • Resource Owner Password Flow (uses ROPC Grant)
  • Device Authorization Flow (uses Device Code Grant)
  • JWT Bearer Token Flow (OAuth 2.0 SAML Assertion Flow)

 

Let's look at the various OAuth 2.0 flows in detail

Authorization code flow (Standard flow client only)

This flow is used by public clients like Single Page Applications (SPAs) or mobile apps, where the backend is absent or not secure. This is less secure and hence we should use the Authorization code flow with PKCE instead.

Let's take an example to understand this flow - You (resource owner), crated a post on an app (client). Let's name this app SuperPost. Now you want this client (SuperPost app) to share your post (resource) on Facebook on your behalf (delegate authorization). You (resource owner) want to make sure that the client (SuperPost app) is only able to post on your behalf and nothing else.

OAuth 2.0 Flow

In-order for this flow to work Client (SuperPost app) has to be already registered with Facebook and should have access to the client ID and client secret that Facebook provides to the client (SuperPost app) when registering, in order to support delegate authorization via OAuth 2.0.

  1. You (resource owner) click on the 'Connect to Facebook' button.
  2. Client (SuperPost app) will redirect you to Facebook for granting the authorization, with a Callback URL and Response type.
  3. Next, you login into Facebook
  4. Facebook will ask for your consent by showing what all access the client (SuperPost app) wants to have, in this case publishing a post on your behalf.
  5. Now, you click on the allow button to grant permission.
  6. Facebook (the authorization server) will redirect back to the SuperPost app (client) with an authorization code (Auth code).
  7. In the background SuperPost app (client) makes a request for Auth token by sending its client ID, client secret and Auth code to Facebook's token endpoint.
  8. Facebook verifies these credentials and the code, then responds with an access token (and optionally, a refresh token).
  9. SuperPost app (client) can now use the access token to make API requests to Facebook (the resource server) to post on your behalf (delegate authorization).
  10. Facebook (the resource server) returns the response to client (SuperPost app)

Authorization code flow (Standard flow having client and server)

This flow is used by clients like web apps that have a secure backend API server. This server can securely store secrets, handle sensitive tokens and can interact with the Authorization server.

Let's look at the same example to understand this flow - You (resource owner), crated a post on an SuperPost app (client). Now you want this client (SuperPost app) to share your post (resource) on Facebook on your behalf (delegate authorization). You (resource owner) want to make sure that the client (SuperPost app) is only able to post on your behalf and nothing else.

OAuth 2.0 Flow

Again, in-order for this flow to work Client (SuperPost app) has to be already registered with Facebook and should have access to the client ID and client secret that Facebook provides to the client (SuperPost app) when registering, in order to support delegate authorization via OAuth 2.0.

  1. You (resource owner) click on the 'Connect to Facebook' button.
  2. Client (SuperPost app) will redirect you to Facebook for granting the authorization, with a Callback URL and Response type.
  3. Next, you login into Facebook
  4. Facebook will ask for your consent by showing what all access the client (SuperPost app) wants to have, in this case publishing a post on your behalf.
  5. Now, you click on the allow button to grant permission.
  6. Facebook (the authorization server) will redirect back to the SuperPost app (client) with an authorization code (Auth code).
  7. Now, the client (SuperPost app) will send this Auth code to its server side API.
  8. Now, the server side API makes a request for Auth token by sending its client ID, client secret and Auth code to Facebook's token endpoint.
  9. Facebook verifies these credentials and the code, then responds with an access token (and optionally, a refresh token).
  10. SuperPost app's server side API can now use the access token to make API requests to Facebook (the resource server) to post on your behalf (delegate authorization).
  11. Facebook (the resource server) returns the response to SuperPost's server side API
  12. SuperPost's server side API responds back with appropriate response to the SuperPost App (client)

Authorization code flow with PKCE (Proof Key for Code Exchange)

This flow is used for mobile apps and single-page applications (SPAs) where a backend server may not be present to store secrets securely.

This flow is more secure compared to using the standard Authorization code flow. In the standard Authorization code flow, an attacker can intercept the authorization code and exchange it for an access token. However, here PKCE (Proof Key for Code Exchange) adds an extra layer of security by verifying the app’s identity using a Code Challenge.

We will use the same above example as above. Again, in-order for this flow to work Client (SuperPost app) has to be already registered with Facebook and should have access to the client ID and client secret.

OAuth 2.0 Flow - PKCE (Proof of key code exchange)

  1. You (resource owner) click on the 'Connect to Facebook' button.
  2. Client (SuperPost app) generates a random string (code verifier)
  3. It then calculates a "code challenge" by hashing the code verifier (using SHA-256) and encoding it.
  4. Client (SuperPost app) will now redirect you to Facebook for granting the authorization, with a Callback URL, Response type, and Code Challenge.
  5. Facebook (Authorization server) will store the code challenge
  6. Next, you login into Facebook
  7. Facebook will ask for your consent by showing what all access the client (SuperPost app) wants to have, in this case publishing a post on your behalf.
  8. Now, you click on the allow button to grant permission.
  9. Facebook (the authorization server) will redirect back to the SuperPost app (client) with an authorization code (Auth code).
  10. In the background SuperPost app (client) makes a request for Auth token by sending its client ID, client secret, Auth code and the original Code Verifier to Facebook's token endpoint.
  11. Facebook (Authorization server) hashes the Code Verifier and compares it to the Code Challenge that it had stored from initial request from SuperPost app.
  12. Facebook (Authorization server) verifies the credentials and the Auth code, then responds with an access token (and optionally, a refresh token).
  13. SuperPost app (client) can now use the access token to make API requests to Facebook (the resource server) to post on your behalf (delegate authorization).
  14. Facebook (the resource server) returns the response to client (SuperPost app)

Client Credentials Flow:

This flow is used for machine (server) to machine (server) (M2M) authentication (When no user is involved)

OAuth 2.0 Flow - Client Credentials Flow: for Server to Server authentication (no user involved)

This is often used in Microservices architecture and backend jobs.

  1. The client (e.g., a backend service) sends its client ID and client secret to the authorization server.
  2. The authorization server verifies the credentials and if valid, the server responds with an access token.
  3. The client uses the access token to access the resource server.

Implicit Flow (now discouraged, used Implicit Grant)

This was originally designed for Single Page Applications (SPAs), but it is now considered insecure and discouraged in favor of Authorization Code Flow with PKCE. The access token is exposed in the URL, making it vulnerable to interception (e.g., via browser history, network sniffing).

  1. The user is redirected to the authorization server.
  2. The user logs in and grants permissions to the client.
  3. The authorization server immediately returns an access token in the URL fragment (instead of an authorization code).
  4. The client extracts the access token and uses it to access the resource.

Resource owner password credentials flow (uses ROPC Grant)

This flow is used for highly trusted applications where users enter their username and password directly into the client application. This is suitable for legacy systems that don’t support modern OAuth mechanisms. Requires a high-trust environment (not suitable for third-party apps).

The client application handles raw credentials, increasing the risk of leaks.

  1. The user enters their username and password into the application.
  2. The application sends these credentials directly to the authorization server.
  3. If valid, the authorization server issues an access token (and optionally a refresh token).
  4. The client uses the access token to access resources.

Device authorization flow (uses Device Code Grant)

This flow is used for devices without a browser or limited input capabilities (e.g., Smart TVs, IoT devices, gaming consoles).

  1. The device requests a login by sending a request to the authorization server.
  2. The authorization server responds with a device code and a user verification URL.
  3. The device displays a message: "Go to example.com/device and enter this code: ABC123."
  4. The user access the link and enters the code on a separate device (e.g., a phone or laptop).
  5. Once authenticated, the authorization server issues an access token to the original device.

JWT bearer token flow (OAuth 2.0 SAML assertion flow)

This flow is used for single sign-on (SSO) between organizations without requiring user interaction. It is suitable for enterprise applications that use SAML (Security Assertion Markup Language) or JWT (JSON Web Tokens) for authentication.

Here the client application has to be registered with the token service (also called IdP or Identity Provider) to establish a trust.

  1. The client requests for a JWT (Json Web Token) from the token service (IdP)
  2. The token service (IdP) encrypts the JWT using JSON Web Encryption and issues it to the client application.
  3. Client application verifies the JSON Web token received from the token service (IdP).
  4. Client application sends a request to authorization server’s /token endpoint. The value of the mandatory grant_type parameter must be set to urn:ietf:params:oauth:grant-type:jwt-bearer. The value of the assertion parameter must contain a single JWT.
  5. The authorization server decrypts and verifies the JWT.
  6. The authorization server issues an access token and returns it to the client application.
  7. The client uses the access token to access protected resources.

OpenID Connect (OIDC)

This is used for user authentication (verifying user identity). OIDC extends OAuth 2.0 by adding ID tokens to verify who the user is.

Let's consider our SuperPost app. SuperPost uses OAuth 2.0 to obtain permission to post on Facebook on behalf of the user. However, OAuth2.0 alone doesn't provide SuperPost any details about the user's identity.

This is where OpenID Connect comes into play. OpenID Connect is a standardized identity layer on top of OAuth2.0 to provide authenticated user identity to client app. This identity can now be used by Client app for authorization and personalization purpose.

OpenID Connect (OIDC) extends OAuth 2.0 add these components

  • ID Token
    • A JWT (JSON Web Token) containing claims about the authentication event and basic user info.
    • JWT is signed by Identity Provider (Auth Server) to ensure integrity and authenticity.
  • Scope
    • Predefined scopes like 'openid', 'profile' and 'email' that request specific set of user information.

Open ID Connect (OIDC) extends OAuth 2.0 add these components

  1. User attempts to access a protected resource
  2. The client application, known as the Relying Party (RP), redirects the user to the OIDC Identity Provider (IdP) for authentication
  3. The user provides the credentials to the IdP to authenticate.
  4. The IdP verifies the user's identity.
  5. The IdP issues and ID Token, which contains information about the user (claims) and an Access Token.
  6. The ID Token is a JWT (JSON Web Token) that the client (RP) can use to verify the user's identity.
  7. The Access Token is used by client to access the protected resource.
  8. The client (RP) receives and verifies the ID Token's signature and claims to ensure its authenticity and integrity.
  9. The client (RP) can then use the access token to access the protected resource.
Flow Best For Security Considerations
Authorization Code Flow Web apps (server-side) Secure token exchange via backend
Authorization Code with PKCE Mobile apps, SPAs Prevents code interception (replaces Implicit Flow)
Client Credentials Flow Machine-to-machine (M2M) APIs No user involvement, uses client secrets
OpenID Connect (OIDC) User authentication (login) Adds ID token for authentication
Implicit Flow (Deprecated) SPAs (legacy) Not recommended (tokens exposed in URL)
Resource Owner Password Flow Legacy systems, internal apps Less secure (direct credential exchange)
Device Authorization Flow Smart TVs, IoT, gaming consoles Secure login via code entry on another device
JWT Bearer Token Flow Enterprise SSO Secure assertion-based authentication

 

OAuth 2.0 empowers secure, delegated access to user data without exposing credentials, using well-defined flows and token-based authorization. Whether it's a web app, mobile app, or machine-to-machine API, OAuth ensures access is both controlled and secure



Try few questions
<-- Back
Take quiz -->