Modern Authentication and Authorization - From LDAP to OAuth 2.0 SSO

#Introduction

Authentication and authorization are the gatekeepers of modern systems. Every time you log into an application, your identity is verified (authentication) and your permissions are checked (authorization). But how this happens has fundamentally changed over the past two decades.

For years, enterprises relied on LDAP and Active Directory—centralized directory services that worked well within corporate networks. Today, organizations operate across cloud platforms, mobile devices, and distributed teams. The old model breaks down. Modern systems demand something different: Single Sign-On (SSO) powered by OAuth 2.0 and OpenID Connect.

This shift isn't just technical—it's architectural. Understanding this evolution helps you make better decisions about identity infrastructure, security posture, and user experience.

#Table of Contents

#The Authentication Evolution: A Brief History

#The LDAP Era (1990s-2000s)

LDAP (Lightweight Directory Access Protocol) was revolutionary for its time. It provided a centralized way to store and query user credentials and organizational information.

How LDAP worked:

Users stored in a hierarchical directory tree
Applications queried LDAP directly for user credentials
Passwords verified against the directory
Simple, but tightly coupled to the network

The problem: LDAP assumed users were on the corporate network. VPN access was clunky. Mobile? Forget about it. Cross-organization collaboration required complex federation setups.

#Active Directory's Dominance (2000s-2010s)

Microsoft's Active Directory (AD) extended LDAP with Kerberos authentication, group policies, and deep Windows integration. It became the de facto standard for enterprise identity.

Why AD was powerful:

Kerberos provided ticket-based authentication (more on this later)
Group policies enabled centralized management
Seamless Windows domain integration
Works well within corporate boundaries

The limitation: AD was designed for on-premises networks. Cloud adoption exposed its weaknesses. Managing identities across AWS, Azure, and SaaS applications became a nightmare.

#The Cloud-Native Shift (2010s-Present)

As organizations moved to cloud platforms and adopted SaaS applications, a new model emerged: token-based, stateless authentication. OAuth 2.0 and OpenID Connect became the standard.

Why the shift happened:

Users work from anywhere, not just corporate networks
Applications are distributed across cloud providers
SaaS adoption exploded (Salesforce, Slack, Jira, etc.)
Mobile-first development required stateless authentication
Microservices needed lightweight, scalable identity solutions

#Understanding OAuth 2.0 and SSO

#What is OAuth 2.0?

OAuth 2.0 is an authorization framework, not an authentication protocol. This distinction matters.

Authorization = "What are you allowed to do?" Authentication = "Who are you?"

OAuth 2.0 answers the authorization question. It lets users grant applications permission to access their resources without sharing passwords.

#The OAuth 2.0 Flow: A Real-World Analogy

Imagine you're at a restaurant and want to pay with a credit card:

You hand your card to the waiter (not your PIN)
The waiter takes it to the payment processor
The processor verifies the card and charges it
The waiter returns with a receipt (proof of transaction)
You never shared your PIN with the waiter

OAuth 2.0 works similarly:

User clicks "Login with SSO" on an application
Application redirects user to the identity provider (IdP)
IdP verifies the user's credentials
IdP issues an authorization code
Application exchanges the code for an access token
Application uses the token to access user resources

#The Four Key Players in OAuth 2.0

plaintext

┌─────────────┐
│   Resource  │
│   Owner     │
│  (User)     │
└──────┬──────┘
       │
       │ 1. Initiates login
       ▼
┌─────────────────┐         ┌──────────────────┐
│  Client App     │◄───────►│  Authorization   │
│  (Your App)     │ 2,3,4   │  Server (IdP)    │
└─────────────────┘         └──────────────────┘
       │                            │
       │ 5. Access Token            │
       │◄───────────────────────────┘
       │
       ▼
┌──────────────────┐
│  Resource Server │
│  (API)           │
└──────────────────┘

Resource Owner: The user whose data is being accessed Client Application: Your app requesting access Authorization Server: The identity provider (IdP) that verifies identity Resource Server: The API or service holding the user's data

#IAM Concepts: The Building Blocks

#Realms

A realm is a logical grouping of users, applications, and policies. Think of it as a namespace for identity.

Example: A company might have:

Production realm (for customer-facing apps)
Staging realm (for testing)
Internal realm (for employee apps)

Each realm has its own:

User directory
Applications
Policies
Token signing keys

#Claims

Claims are statements about a user. They're key-value pairs included in tokens that describe who the user is and what they're allowed to do.

Standard claims:

sub (subject): Unique user identifier
iss (issuer): Who issued the token
aud (audience): Who the token is for
exp (expiration): When the token expires
iat (issued at): When the token was created

Custom claims:

department: "Engineering"
role: "Senior Engineer"
team: "Platform"
permissions: ["read:logs", "write:config"]

JWT Payload with Claims

{
  "sub": "user123",
  "iss": "https://idp.company.com",
  "aud": "web-app",
  "exp": 1708108800,
  "iat": 1708022400,
  "email": "alice@company.com",
  "department": "Engineering",
  "role": "Senior Engineer",
  "permissions": ["read:logs", "write:config", "deploy:staging"]
}

#Tokens: The Currency of Modern Auth

Tokens are the core of OAuth 2.0. They're cryptographically signed credentials that prove identity and authorization.

Access Token: Short-lived token used to access APIs

Typically expires in 15 minutes to 1 hour
Included in every API request
If compromised, limited damage window

Refresh Token: Long-lived token used to get new access tokens

Typically expires in days or weeks
Stored securely (httpOnly cookies or secure storage)
Never sent to APIs, only to the authorization server

ID Token: Contains user identity information (OpenID Connect)

Includes claims about the user
Used for authentication, not authorization
Should not be used to access APIs

Token Exchange Flow

// 1. User logs in, receives authorization code
const authCode = "auth_code_xyz";
 
// 2. Exchange code for tokens
const tokenResponse = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret_xyz",
    redirect_uri: "https://app.company.com/callback"
  })
});
 
// 3. Response contains tokens
const { access_token, refresh_token, id_token, expires_in } = 
  await tokenResponse.json();
 
// 4. Use access token for API calls
const apiResponse = await fetch("https://api.company.com/user", {
  headers: {
    Authorization: `Bearer ${access_token}`
  }
});

#Kerberos: The Ticket-Based Alternative

Kerberos is often mentioned alongside OAuth 2.0, but it's fundamentally different. Understanding the distinction helps you choose the right tool.

#How Kerberos Works

Kerberos uses a ticket-based system instead of tokens:

User authenticates to the Kerberos server with their password
Kerberos server issues a Ticket Granting Ticket (TGT)
User uses the TGT to request service tickets for specific applications
User presents the service ticket to access the application
Application verifies the ticket with the Kerberos server

plaintext

User Password
     │
     ▼
┌──────────────────┐
│ Kerberos Server  │
│ (KDC)            │
└──────────────────┘
     │
     │ Ticket Granting Ticket (TGT)
     ▼
User's Cache
     │
     ├─► Request Service Ticket for App A
     │        │
     │        ▼
     │   ┌──────────────────┐
     │   │ Kerberos Server  │
     │   └──────────────────┘
     │        │
     │        │ Service Ticket
     │        ▼
     └─► App A (Verify with KDC)

#Kerberos vs OAuth 2.0

Aspect	Kerberos	OAuth 2.0
Design Era	1980s (network-centric)	2010s (internet-centric)
Network Assumption	Trusted internal network	Untrusted internet
Credential Sharing	Tickets (time-limited)	Tokens (cryptographically signed)
Scalability	Requires KDC availability	Stateless, highly scalable
Mobile/Cloud	Poor fit	Excellent fit
Use Case	Enterprise networks	Cloud, SaaS, APIs

Tip

Kerberos is still valuable for on-premises enterprise environments. Many modern SSO systems support Kerberos as a fallback for legacy applications while using OAuth 2.0 for new services.

#LDAP Compatibility with Modern SSO

One of the biggest concerns during migration: "What about our existing LDAP infrastructure?"

The good news: Modern SSO systems maintain LDAP compatibility through bridges and connectors.

#LDAP as a User Store

Many SSO systems can use LDAP as the backend user directory:

SSO with LDAP Backend

sso:
  name: company-sso
  userStore:
    type: ldap
    connection:
      url: ldap://ldap.company.com:389
      baseDn: dc=company,dc=com
      bindDn: cn=admin,dc=company,dc=com
    userMapping:
      username: uid
      email: mail
      displayName: cn
      groups: memberOf

How it works:

User logs into SSO portal
SSO queries LDAP directory for user credentials
SSO verifies password against LDAP
SSO issues OAuth tokens
Applications use OAuth tokens (not LDAP directly)

#LDAP Proxy for Legacy Apps

For applications that only understand LDAP, SSO systems can act as an LDAP proxy:

plaintext

Legacy App
    │
    │ LDAP Query
    ▼
┌──────────────────┐
│ SSO System       │
│ (LDAP Proxy)     │
└──────────────────┘
    │
    │ LDAP Query
    ▼
┌──────────────────┐
│ LDAP Directory   │
└──────────────────┘

This allows legacy applications to continue working while you migrate to OAuth 2.0 for new services.

#OpenID Connect: Authentication on Top of OAuth 2.0

OAuth 2.0 handles authorization, but what about authentication? That's where OpenID Connect (OIDC) comes in.

OIDC is a thin layer on top of OAuth 2.0 that adds authentication. It introduces the ID token, which contains claims about the user's identity.

#OAuth 2.0 vs OpenID Connect

OAuth 2.0 Flow (Authorization Only)

// OAuth 2.0: Get access token to call APIs
const response = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret"
  })
});
 
const { access_token } = await response.json();
// Use access_token to call APIs

OpenID Connect Flow (Authentication + Authorization)

// OIDC: Get access token AND id_token
const response = await fetch("https://idp.company.com/token", {
  method: "POST",
  body: JSON.stringify({
    grant_type: "authorization_code",
    code: authCode,
    client_id: "web-app",
    client_secret: "secret",
    scope: "openid profile email" // OIDC scopes
  })
});
 
const { access_token, id_token } = await response.json();
// id_token contains user identity information
// access_token used to call APIs

#Practical Implementation: Building SSO Integration

#Step 1: Register Your Application

First, register your application with the SSO provider:

Application Registration

application:
  name: my-web-app
  clientId: my-web-app-prod
  clientSecret: ${OAUTH_CLIENT_SECRET}
  redirectUris:
    - https://app.company.com/auth/callback
    - https://app.company.com/auth/callback/mobile
  allowedScopes:
    - openid
    - profile
    - email
    - offline_access
  tokenEndpointAuthMethod: client_secret_basic
  accessTokenLifespan: 3600
  refreshTokenLifespan: 604800

OAuth 2.0 Login Implementation

import { generateRandomString, generateCodeChallenge } from './crypto';
 
export function initiateLogin() {
  // Generate PKCE parameters for security
  const codeVerifier = generateRandomString(128);
  const codeChallenge = generateCodeChallenge(codeVerifier);
  const state = generateRandomString(32);
  
  // Store for later verification
  sessionStorage.setItem('oauth_state', state);
  sessionStorage.setItem('oauth_code_verifier', codeVerifier);
  
  // Build authorization URL
  const params = new URLSearchParams({
    client_id: 'my-web-app-prod',
    redirect_uri: 'https://app.company.com/auth/callback',
    response_type: 'code',
    scope: 'openid profile email offline_access',
    state: state,
    code_challenge: codeChallenge,
    code_challenge_method: 'S256'
  });
  
  // Redirect to SSO provider
  window.location.href = `https://idp.company.com/authorize?${params}`;
}

#Step 3: Handle the Callback

OAuth 2.0 Callback Handler

export async function handleCallback(code: string, state: string) {
  // Verify state parameter
  const storedState = sessionStorage.getItem('oauth_state');
  if (state !== storedState) {
    throw new Error('State mismatch - possible CSRF attack');
  }
  
  const codeVerifier = sessionStorage.getItem('oauth_code_verifier');
  
  // Exchange code for tokens
  const response = await fetch('https://idp.company.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code: code,
      client_id: 'my-web-app-prod',
      client_secret: process.env.OAUTH_CLIENT_SECRET,
      redirect_uri: 'https://app.company.com/auth/callback',
      code_verifier: codeVerifier
    })
  });
  
  const { access_token, refresh_token, id_token } = await response.json();
  
  // Store tokens securely
  sessionStorage.setItem('access_token', access_token);
  // Store refresh token in httpOnly cookie (server-side)
  await fetch('/api/auth/store-refresh-token', {
    method: 'POST',
    body: JSON.stringify({ refresh_token })
  });
  
  // Decode and verify ID token
  const user = decodeIdToken(id_token);
  return user;
}

#Step 4: Use Access Tokens for API Calls

API Calls with Access Token

export async function fetchUserData() {
  const accessToken = sessionStorage.getItem('access_token');
  
  const response = await fetch('https://api.company.com/user', {
    headers: {
      Authorization: `Bearer ${accessToken}`
    }
  });
  
  if (response.status === 401) {
    // Token expired, refresh it
    await refreshAccessToken();
    return fetchUserData(); // Retry
  }
  
  return response.json();
}
 
async function refreshAccessToken() {
  const response = await fetch('/api/auth/refresh', {
    method: 'POST'
  });
  
  const { access_token } = await response.json();
  sessionStorage.setItem('access_token', access_token);
}

#Common Mistakes and Pitfalls

#Mistake 1: Storing Access Tokens in localStorage

The Problem:

❌ Don't Do This

// Vulnerable to XSS attacks
localStorage.setItem('access_token', token);

Why it's dangerous: Any JavaScript on the page (including malicious scripts from XSS vulnerabilities) can read localStorage.

The Solution:

✅ Do This Instead

// Store in httpOnly cookie (server-side only)
// Server sets: Set-Cookie: access_token=...; HttpOnly; Secure; SameSite=Strict

#Mistake 2: Not Validating ID Tokens

The Problem:

❌ Don't Do This

// Trusting the token without verification
const user = JSON.parse(atob(idToken.split('.')[1]));

Why it's dangerous: Anyone can create a fake JWT. You must verify the signature.

The Solution:

✅ Do This Instead

import jwt from 'jsonwebtoken';
 
const publicKey = await fetchIdpPublicKey();
const decoded = jwt.verify(idToken, publicKey, {
  algorithms: ['RS256'],
  issuer: 'https://idp.company.com',
  audience: 'my-web-app-prod'
});

#Mistake 3: Ignoring Token Expiration

The Problem:

❌ Don't Do This

// Using expired tokens
const token = sessionStorage.getItem('access_token');
// No expiration check

The Solution:

✅ Do This Instead

function isTokenExpired(token: string): boolean {
  const decoded = jwt.decode(token) as any;
  return decoded.exp * 1000 < Date.now();
}
 
if (isTokenExpired(accessToken)) {
  await refreshAccessToken();
}

#Mistake 4: Not Using PKCE for SPAs

The Problem:

❌ Don't Do This

// Authorization code flow without PKCE
const params = new URLSearchParams({
  client_id: 'my-app',
  redirect_uri: 'https://app.company.com/callback',
  response_type: 'code'
  // Missing code_challenge
});

Why it's dangerous: Without PKCE, authorization codes can be intercepted and used by attackers.

The Solution:

✅ Do This Instead

// Always use PKCE for SPAs
const codeChallenge = generateCodeChallenge(codeVerifier);
const params = new URLSearchParams({
  client_id: 'my-app',
  redirect_uri: 'https://app.company.com/callback',
  response_type: 'code',
  code_challenge: codeChallenge,
  code_challenge_method: 'S256'
});

#Best Practices for Production

#1. Use PKCE for All Public Clients

PKCE (Proof Key for Code Exchange) protects against authorization code interception attacks.

PKCE Implementation

function generateCodeChallenge(codeVerifier: string): string {
  const hash = crypto.createHash('sha256').update(codeVerifier).digest();
  return base64url(hash);
}
 
// Always include in authorization request
const codeChallenge = generateCodeChallenge(codeVerifier);

#2. Implement Token Rotation

Refresh tokens should be rotated on each use to limit exposure:

Token Rotation Pattern

async function refreshAccessToken(refreshToken: string) {
  const response = await fetch('https://idp.company.com/token', {
    method: 'POST',
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      refresh_token: refreshToken,
      client_id: 'my-app',
      client_secret: process.env.OAUTH_CLIENT_SECRET
    })
  });
  
  const { access_token, refresh_token: newRefreshToken } = 
    await response.json();
  
  // Store new refresh token (old one is invalidated)
  await storeRefreshToken(newRefreshToken);
  
  return access_token;
}

#3. Implement Proper Logout

Logout should invalidate tokens on both client and server:

Secure Logout Implementation

async function logout() {
  // Clear client-side tokens
  sessionStorage.removeItem('access_token');
  
  // Invalidate refresh token on server
  await fetch('/api/auth/logout', {
    method: 'POST'
  });
  
  // Redirect to SSO logout endpoint
  window.location.href = 'https://idp.company.com/logout?' + 
    new URLSearchParams({
      post_logout_redirect_uri: 'https://app.company.com'
    });
}

#4. Monitor and Alert on Suspicious Activity

Security Monitoring Configuration

monitoring:
  alerts:
    - name: multiple-failed-logins
      condition: failed_login_attempts > 5 in 5m
      action: lock_account
    - name: token-reuse-detected
      condition: same_refresh_token_used_twice
      action: invalidate_all_tokens
    - name: unusual-location
      condition: login_from_new_country
      action: require_mfa

#5. Use Short-Lived Access Tokens

Keep access token lifetime short (15-60 minutes) to limit damage if compromised:

Token Lifetime Configuration

tokenPolicy:
  accessToken:
    lifetime: 900 # 15 minutes
    refreshable: false
  refreshToken:
    lifetime: 604800 # 7 days
    rotateOnUse: true

#When NOT to Use OAuth 2.0 / SSO

#Scenario 1: Highly Sensitive Internal Systems

For systems with extreme security requirements (financial transactions, healthcare), consider additional layers:

Multi-factor authentication (MFA) requirements
Hardware security keys
Certificate-based authentication
Network segmentation

OAuth 2.0 is still appropriate, but with stricter policies.

#Scenario 2: Legacy Systems with No HTTP Support

If you have systems that only support LDAP or Kerberos and cannot be updated:

Keep LDAP/Kerberos for those systems
Use SSO bridges for new applications
Plan gradual migration

#Scenario 3: Offline-First Applications

Applications that must work without network connectivity:

Use local authentication
Sync identity data when online
Consider hybrid approaches

#Scenario 4: Machine-to-Machine (M2M) Communication

For service-to-service authentication, OAuth 2.0 client credentials flow is appropriate, but consider:

Mutual TLS (mTLS) for additional security
Service mesh integration
API key rotation policies

#Architecture Patterns for Modern SSO

#Pattern 1: Centralized SSO with Multiple Realms

plaintext

┌─────────────────────────────────────────┐
│         Central SSO System              │
├─────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐      │
│ │ Production   │ │ Staging      │      │
│ │ Realm        │ │ Realm        │      │
│ └──────────────┘ └──────────────┘      │
│ ┌──────────────┐ ┌──────────────┐      │
│ │ Internal     │ │ Partner      │      │
│ │ Realm        │ │ Realm        │      │
│ └──────────────┘ └──────────────┘      │
└─────────────────────────────────────────┘
         │              │
    ┌────┴──────────────┴────┐
    │                        │
    ▼                        ▼
┌─────────────┐      ┌──────────────┐
│ Web Apps    │      │ Mobile Apps  │
└─────────────┘      └──────────────┘

#Pattern 2: Federated SSO Across Organizations

plaintext

┌──────────────────────┐      ┌──────────────────────┐
│  Company A SSO       │      │  Company B SSO       │
│  (IdP)               │      │  (IdP)               │
└──────────────────────┘      └──────────────────────┘
         │                             │
         └─────────────┬───────────────┘
                       │
                ┌──────▼──────┐
                │ Federation  │
                │ Broker      │
                └──────┬──────┘
                       │
         ┌─────────────┴─────────────┐
         │                           │
         ▼                           ▼
    ┌─────────┐              ┌──────────┐
    │ App A   │              │ App B    │
    └─────────┘              └──────────┘

#Migration Strategy: From LDAP to OAuth 2.0

#Phase 1: Assessment (Weeks 1-2)

Inventory all applications using LDAP/AD
Categorize by criticality and complexity
Identify dependencies

#Phase 2: Pilot (Weeks 3-6)

Deploy SSO system in staging
Migrate 2-3 non-critical applications
Test with subset of users
Gather feedback

#Phase 3: Gradual Rollout (Weeks 7-16)

Migrate applications in batches
Maintain LDAP proxy for legacy apps
Monitor for issues
Provide user training

#Phase 4: Decommission (Weeks 17+)

Verify all applications migrated
Disable LDAP proxy
Archive LDAP infrastructure
Document lessons learned

Migration Timeline Example

migration:
  phase1:
    duration: 2 weeks
    tasks:
      - audit_applications
      - assess_complexity
      - plan_rollout
  phase2:
    duration: 4 weeks
    pilot_apps:
      - internal-wiki
      - status-page
  phase3:
    duration: 10 weeks
    batches:
      - batch1: [jira, confluence, slack]
      - batch2: [github, gitlab, npm-registry]
      - batch3: [custom-apps]
  phase4:
    duration: ongoing
    tasks:
      - monitor_stability
      - optimize_performance
      - decommission_ldap

#Conclusion

The shift from LDAP and Active Directory to OAuth 2.0 and SSO represents more than a technology upgrade—it's an architectural evolution driven by how we work today.

Key takeaways:

LDAP/AD were designed for trusted corporate networks; they don't scale to cloud and distributed teams
OAuth 2.0 provides stateless, scalable authorization; OpenID Connect adds authentication on top
Tokens (access, refresh, ID) are the currency of modern authentication
Kerberos remains valuable for on-premises environments but doesn't fit cloud-native architectures
LDAP compatibility can be maintained during migration through bridges and proxies
Security practices matter more than ever: PKCE, token rotation, short lifespans, proper logout

Start with a pilot program, learn from real-world usage, and migrate gradually. The investment in modern identity infrastructure pays dividends in security, scalability, and user experience.

Your next step: Evaluate SSO solutions for your organization's specific needs, considering factors like existing infrastructure, compliance requirements, and team expertise.

Modern Authentication and Authorization - From LDAP to OAuth 2.0 SSO

Related Posts