Delegated Authentication

We were all suffering from password fatigue. Remembering dozens of unique, complex passwords for every service we use has become nearly impossible. As developers, building and maintaining secure authentication systems is equally challenging. What if there weas a better way? Enter delegated authentication.

What Is Delegated Authentication?

Your application does NOT authenticate the user directly. Instead, it “delegated” the authentication process to a trusted third-party Identity Provider (IdP).

Delegated authentication is the process of outsourcing the application's login functionality to a trusted third-party identity provider. Instead of creating and managing username and passwords and passwords yourself, you let experts like Google, Facebook, Microsoft, or specialized identity platforms handle the verification.

When you see “Sign in with Google” or “Continue with Facebook", you are experiencing delegated authentication in action. It's like a universal ID card that works across multiple services without creating new credentials for each one.

It is the concept, or we can say a design philosophy / architecture pattern.

Examples of Identity providers:

• Google
• Facebook
• GitHub
• Apple
• Microsoft Azure AD
• Auth0
• Okta
• Twitter/X
• Government IDs (Aadhaar login, DigiLocker login, etc.)

Your app relies on the IdP to verify:

• the user is who they claim to be
• the user has successfully logged in
• the app can trust the identity information provided

Why Delegated Authentication Exists

Before delegated auth, application used:

• username/password stored in the local database
• users had to create accounts on every site
• apps had to manage password security (hashing, storage, resets)
• massive security burden + bad UX

As the web matured:

• People trusted major identity providers
• Password leaks became common
• Users hated signing up repeatedly
• Mobile apps needed seamless login

Thus, “Login with Google” or “Login with Facebook” became common.

Delegation solved:

• poor UX
• password security problems
• account recovery issues
• identity uniqueness
• multi-device login
• MFA/2FA security
• provides frictionless onboarding
• improves reliability

While Delegated authentication is a conceptual model, the actual mechanism behind it is implemented using open protocols and standard specifications such as:

• OAuth 2.0
• OpenID Connect (OIDC)
• PKCE
• SAML 2.0

The Protocols / Standard Specifications

Delegated authentication is implemented through industry-standard protocols. These define exactly how tokens are issued, how identity is transmitted, and how applications should verify the information.

1 OAuth 1.0 – The First Version (2007)

OAuth 1.0 was introduced:

• Authorization tokens instead of passwords
• Signing requests using cryptographic signatures
• A standardized permission model

Problem Before OAuth

Apps used to ask for your username/password for other services.

Example: “Enter your Gmail password so we can import your contacts.”

This was extremely insecure.

OAuth 1.0 Flow (High-Level)

1. App asks for permission
2. User approves
3. App gets a signed token
4. App uses this token to access the API

But OAuth 1.0 was complicated:

• Required cryptographic signing
• Hard to implement
• Not ideal for browsers or mobile

2 OAuth 2.0 – Authorization Framework

It is a complete redesign of OAuth 1.0, it is not backward compatible with OAuth 1.0. It is a new protocol sharing only the concept of delegated authorization.

OAuth 2.0 is a framework, not strictly a protocol, but it forms the foundation of modern delegated authentication.

Purpose:

Allow a user to grant an application limited access to their data without sharing their password.

It provides:

• Access Tokens – used to access APIs. It is short lived, thus gives limited access to APIs. It is issued after user grants permission.
• Refresh Tokens – used to obtain new access tokens. It is long lived. It is used to obtain new access token.
• Scope – define what permissions are granted

OAuth is NOT for authentication

Although people often use it for login, OAuth 2.0 by itself does not identify the user. It only grants permission to resources.

That is why OpenID Connect was created.

Key Roles in OAuth 2.0

1. Resource Owner: The user (you) who owns the data.
2. Client: The third-party application that wants to access your data.
3. Authorization Server: The server that handles the user's authentication and issues tokens (e.g., Google's login page).
4. Resource Server: The API server that holds the user's data (e.g., Google's Photos API).

Step-by-Step Walkthrough:

1. User Initiates Login: You Click “Login With Google” on PrintPhotos.com.
2. Authorization Request: The client (PrintPhotos.com) redirects your browser to the Authorization Server (Google) with a request that includes:
   1. client_id: The public identifier for PrintPhotos.com (like a username).
   2. redirect_uri: Where Google should send the user back to after approval.
   3. response_type=code: This specifies we are using the "Authorization Code" flow.
   4. scope: What permissions are being requested (e.g., photos.readonly).
   5. state: A random string for security (to prevent CSRF attacks).
3. User Authentication & Consent: You are prompted to log into Google (if you aren't already).
   Thus, Google shows a consent screen: “PrintPhotos.com wants to access your photos. Is that okay?”
4. Authorization Grant: If you click “Allow”, the Authorization Server (Google) redirects your browser back to redirect_url (PrintPhotos.com) with a single-use Authorization Code in the URL.
5. Token Request: The Client's server-side backend (not the browser) takes this Authorization Code and makes a back-channel request directly to the Authorization Server. This request includes:
   1. The auhorization_code
   2. The client_id
   3. The client_secret (a password known only to the client and the Authorization Server).
6. Token Response: The Authorization Server verifies everything. If it's correct, it responds with a JSON object containing an Access Token (not often a Refresh Token).
7. API Access: The client can now use this Access Token to make API calls to the Resource Server (Google Photos API). The token is sent in the Authorization header of the request (e.g., Authorization: Bearer <Access Token>).
8. Data Response: The Resource Server validates the token and, if it's valid and has the right scope, returns the requested data (your photos) to the client.

Why is this Secure?

• The user's password is never shared with the third-party app.
• The sensitive client_secret is never exposed to the user's browser.
• Access Tokens are short-lived (usually hours): If stolen, they are only useful for limited time.
• Refresh Tokens can be used to get new Access Tokens without asking the user to log in again, but they must be stored very securely by the client.
• Scopes limit what the app can do (e.g., read vs. read+write).

2 OpenID Connect (OIDC) – Authentication Protocol

OIDC is a layer on top of OAuth 2.0, adding authentication.

OAuth 2.0 says:

“Here is a token to access resources.”

OpenID Connect Says:

“Here is proof of who the user is (ID Token).”

Purpose:

OAuth 2.0 was designed only for authorization:

“App X is allowed to access data Y on behalf of the user.”

It was never designed for login or identify verification. But companies were incorrectly using OAuth 2.0 as a login mechanism ("Sign in with Google").

This created problems:

• No standard way to get user profile
• No standard way to return user email
• No standard token for identify
• No way to verify the user securely
• Inconsistent implementation between companies

To fix this, OpenID Foundation created:

OpenID Connect = OAuth 2.0 + Identity Layer

Provides a secure, standardized way to authenticate users and verify their identity.

What OIDC adds:

• ID Token (JWT)
• /userinfo endpoint
• Standard scopes: openid, email, profile
• Issuer and audience validation rules
• Standardized metadata discovery

The ID Token

A JSON Web Token containing:

• the user's identity (sub)
• issuer (iss)
• expiration (exp)
• app audience (aud)
• optional user profile fields

OIDC is the protocol behind:

• Login with Google
• Login with Apple
• Login with Microsof

In modern web development, OIDC is the primary protocol for delegated authentication.

3 PKCE – Security Extension for OAuth

PKCE (Proof Key for Code Exchange) is a security enhancement for OAuth 2.0 Authorization Code Flow.

Purpose:

Prevent attackers from intercepting the authorization code and exchanging it for tokens.

How it Works:

• The app generates a secret value (code_verifier)
• Sends a hashed version (code_challenge) to the authorization server
• Must present the code_verifier during token exchange

If an attacker grabs only the authorization code, they cannot redeem it without the secret verifier.

PKCE is essential for:

• Mobile apps
• Single-page application (SPAs)
• Browser-based apps