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
12  ↓
13Enterprise SSO? β†’ SAML / OIDC

Related Snippets