Authentication, OAuth2, PKCE, JWT & Authorization (RBAC/ABAC)

Designing enterprise authentication and authorization architecture requires understanding JWT (JSON Web Tokens) validation mechanics, OAuth 2.0 with PKCE (Proof Key for Code Exchange) for public and single-page apps, and authorization models (RBAC vs ABAC).

This chapter details JWT header/payload/signature structure, RS256 asymmetric token verification, OAuth2 PKCE authorization flows, and fine-grained ABAC policy enforcement.

1. JWT Structure & Asymmetric Verification (RS256 vs. HS256)

A JSON Web Token (JWT) consists of three Base64URL-encoded components separated by dots (.): Header.Payload.Signature.

JWT Cryptographic Signing:

1. HS256 (Symmetric):
   Uses a SINGLE shared secret key to both SIGN and VERIFY the JWT.
   - Danger: All microservices must know the secret key; leaking it allows ANY service to forge valid JWTs!

2. RS256 (Asymmetric - Enterprise Standard):
   Uses a PRIVATE KEY to sign JWTs (Auth Server), and a PUBLIC KEY to verify signatures (Resource Services).
   - Advantage: Resource microservices verify tokens using the Public Key without being able to forge tokens!

import jwt  # PyJWT library

PUBLIC_KEY = """-----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY-----"""

def verify_jwt_token(token: str) -> dict:
    try:
        # RS256 Asymmetric Verification: Verifies signature, expiration ('exp'), and issuer ('iss')
        payload = jwt.decode(
            token,
            PUBLIC_KEY,
            algorithms=["RS256"],
            options={"verify_exp": True, "verify_iss": True},
            issuer="https://auth.company.com/"
        )
        return payload
    except jwt.ExpiredSignatureError:
        raise Exception("Token expired")
    except jwt.InvalidTokenError:
        raise Exception("Invalid authentication token")

2. OAuth 2.0 Authorization Code Flow with PKCE

For SPA and Mobile applications, standard Authorization Code Flow risks secret leakage. PKCE (Proof Key for Code Exchange) solves this using a dynamic code challenge:

OAuth 2.0 PKCE Flow Sequence:

[ Client App ] ──> (1. Generates secret 'code_verifier' & SHA256 'code_challenge')
      |
      ├── (2. Redirects to Auth Server with 'code_challenge') ──> [ Auth Server ]
      |                                                                 |
      |<── (3. Returns Authorization Code) ─────────────────────────────┘
      |
      ├── (4. Exchanges Authorization Code + raw 'code_verifier') ──> [ Auth Server ]
                                                                        | (Verifies SHA256(verifier) == challenge)
                                                                        v
                                                               [ Issues Access Token ]

3. Authorization Architecture: RBAC vs. ABAC

Authorization Models Comparison:

1. ROLE-BASED ACCESS CONTROL (RBAC):
   Assigns permissions to coarse roles: @requires_role("admin").
   - Limitation: Cannot express context-aware permissions (e.g. "Can edit post ONLY if owner AND before 5 PM").

2. ATTRIBUTE-BASED ACCESS CONTROL (ABAC):
   Evaluates boolean policy rules against Subject, Resource, Action, and Environment attributes:
   - Policy: user.id == resource.owner_id AND environment.time < 17:00

⚡

Revision Mode Active Condensed for 5-minute review. Focused on 30-second pitches, mental anchors, and high-frequency interview traps.

⚡ 30-Second Elevator Pitch

“Verify JWTs using asymmetric RS256 so microservices verify signatures with public keys without storing token-signing private keys. Secure mobile/SPA clients using OAuth2 PKCE (Proof Key for Code Exchange) to prevent authorization code interception. Implement ABAC for dynamic, attribute-driven access policies beyond static RBAC roles.”

🧠 Under The Hood & Mental Model

RS256 vs HS256: RS256 uses asymmetric Public/Private keys; HS256 uses a symmetric shared secret.
PKCE code_verifier: Dynamic high-entropy secret created per login attempt; hashed via SHA256 to form code_challenge.
JWT Expiration (exp): Statistically non-revocable until expiration; keep Access Token lifetimes short (15 mins) paired with revocable Refresh Tokens.
ABAC Invariant: Evaluates (Subject, Resource, Action, Environment) tuples dynamically at runtime.

💻 High-Yield Code & Gotcha

# ❌ ANTI-PATTERN: Disabling JWT Expiration or Issuer Verification
# DANGEROUS: Allows expired or forged tokens from unauthorized auth servers!
payload = jwt.decode(token, PUBLIC_KEY, algorithms=["RS256"], options={"verify_signature": False})

# ✅ PRODUCTION PATTERN: Strict RS256 Verification with Audience & Expiration
payload = jwt.decode(
    token,
    PUBLIC_KEY,
    algorithms=["RS256"],
    audience="api://default",
    issuer="https://auth.company.com/"
)

⚠️ GOTCHA: Using “none” Algorithm in JWT Decoding

Attackers can forge JWTs by setting the header {"alg": "none"}. If your JWT library does not explicitly enforce a whitelist (algorithms=["RS256"]), it will accept un-signed forged tokens! Always specify explicit algorithm whitelists.

⚖️ Trade-Offs & Comparison

+ RS256 Asymmetric JWTs: Decentralized token verification across microservices without central database lookups.
- JWT Revocation: Stateless JWTs cannot be revoked instantly prior to expiration without maintaining a centralized token blacklist in Redis.

🌟 My Experience (STAR Anchor)

“A microservice architecture suffered latency spikes because every service called a central Auth DB to validate session tokens. I migrated the system to RS256 JWTs with local public-key verification, eliminating 5,000 DB auth calls per second and dropping API latency by 45ms.”

Python Interview Handbook