Authentication Methods

Comprehensive guide to authentication methods: sessions, JWT, OAuth 2.0, OIDC, and SAML.

Authentication vs Authorization

Authentication (AuthN): Who are you?

  • Verifying identity
  • Credentials: username/password, tokens, biometrics
  • Result: User identity established

Authorization (AuthZ): What can you do?

  • Verifying permissions
  • Access control: roles, permissions, policies
  • Result: Access granted or denied

1. Session-Based Authentication

sequenceDiagram
    participant User
    participant Browser
    participant Server
    participant SessionStore
    
    User->>Browser: Enter credentials
    Browser->>Server: POST /login (username, password)
    Server->>Server: Validate credentials
    Server->>SessionStore: Create session
    SessionStore-->>Server: Session ID
    Server->>Browser: Set-Cookie: session_id=abc123
    Browser->>User: Login successful
    
    Note over Browser,Server: Subsequent requests
    
    User->>Browser: Access protected resource
    Browser->>Server: GET /profile (Cookie: session_id=abc123)
    Server->>SessionStore: Validate session
    SessionStore-->>Server: Session data
    Server->>Browser: Protected resource
    Browser->>User: Display profile

Pros:

  • Simple to implement
  • Server controls session lifecycle
  • Can revoke sessions instantly

Cons:

  • Requires server-side session storage
  • Doesn't scale well horizontally
  • CSRF vulnerability if not protected

Use Case: Traditional web applications, admin panels


2. Token-Based Authentication (JWT)

sequenceDiagram
    participant User
    participant Client
    participant Server
    
    User->>Client: Enter credentials
    Client->>Server: POST /login (username, password)
    Server->>Server: Validate credentials
    Server->>Server: Generate JWT
    Server->>Client: JWT token
    Client->>Client: Store JWT (localStorage/memory)
    Client->>User: Login successful
    
    Note over Client,Server: Subsequent requests
    
    User->>Client: Access protected resource
    Client->>Server: GET /api/data (Authorization: Bearer JWT)
    Server->>Server: Verify JWT signature
    Server->>Server: Validate claims (exp, iat)
    Server->>Client: Protected resource
    Client->>User: Display data

JWT Structure:

1header.payload.signature
2eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT Payload Example:

1{
2  "sub": "1234567890",
3  "name": "John Doe",
4  "email": "john@example.com",
5  "roles": ["user", "admin"],
6  "iat": 1516239022,
7  "exp": 1516242622
8}

Pros:

  • Stateless (no server-side storage)
  • Scales horizontally
  • Works across domains
  • Mobile-friendly

Cons:

  • Cannot revoke before expiry (use short TTL + refresh tokens)
  • Larger than session IDs
  • Vulnerable if stolen (store securely)

Use Case: APIs, microservices, SPAs, mobile apps


3. OAuth 2.0

sequenceDiagram
    participant User
    participant Client
    participant AuthServer as Authorization Server
    participant ResourceServer as Resource Server
    
    User->>Client: Click "Login with Google"
    Client->>AuthServer: Redirect to /authorize
    Note right of Client: client_id, redirect_uri, scope
    AuthServer->>User: Show login page
    User->>AuthServer: Enter credentials & authorize
    AuthServer->>Client: Redirect with auth code
    Client->>AuthServer: POST /token
    Note right of Client: code, client_id, client_secret
    AuthServer->>Client: Access token + Refresh token
    
    Note over Client,ResourceServer: Access protected resources
    
    Client->>ResourceServer: GET /api/data (Bearer token)
    ResourceServer->>ResourceServer: Validate token
    ResourceServer->>Client: Protected resource
    Client->>User: Display data

OAuth 2.0 Grant Types

1. Authorization Code (most secure for web apps)

1Client → Redirect to Auth Server → User Authorizes → Auth Code → Exchange for Token

2. Client Credentials (machine-to-machine)

1Client ID + Secret → Access Token

3. Resource Owner Password (legacy, avoid)

1Username + Password → Access Token

4. Implicit (deprecated, use Authorization Code + PKCE)

Use Case: Third-party integrations (Login with Google, GitHub)


4. OpenID Connect (OIDC)

OAuth 2.0 + Identity Layer

1OAuth 2.0 Flow → Access Token + ID Token (JWT with user info)

ID Token Claims:

 1{
 2  "iss": "https://auth.example.com",
 3  "sub": "user123",
 4  "aud": "client_id",
 5  "exp": 1516242622,
 6  "iat": 1516239022,
 7  "email": "user@example.com",
 8  "email_verified": true,
 9  "name": "John Doe"
10}

Use Case: SSO, federated identity


5. SAML 2.0

XML-based authentication protocol

1Service Provider → Identity Provider → SAML Assertion → SP Validates

Use Case: Enterprise SSO, legacy systems


Comparison Table

MethodStatelessScalabilityRevocationMobileComplexity
Session⭐⭐✅ Instant⭐⭐⭐ Low
JWT⭐⭐⭐⭐⭐❌ (use short TTL)⭐⭐⭐⭐⭐⭐⭐ Medium
OAuth 2.0⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ High
OIDC⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ High
SAML⭐⭐⭐⭐⭐⭐⭐⭐ Very High

Decision Tree

 1Need third-party login? → OAuth 2.0 / OIDC
 2  |
 3  No
 4 5Building API/Microservices? → JWT
 6  |
 7  No
 8 9Traditional web app? → Sessions
10  |
11  No
1213Enterprise SSO? → SAML / OIDC

Related Snippets