Modern Authentication & Authorization Architecture 12-Layer Panoramic Cheat Sheet

In distributed cloud-native microservices and autonomous AI Agent ecosystems, the security perimeter has fundamentally shifted from physical network topology to an identity-centric dynamic trust boundary. From initial user credential verification to machine-to-machine mutual TLS and AI agents acting autonomously on behalf of humans, Authentication (AuthN) and Authorization (AuthZ) span the entire software architecture lifecycle.

Anchored on industry standards of Defense-in-Depth and Zero Trust (Never Trust, Always Verify), this cheat sheet systematically organizes a 12-layer technical evolution architecture from core cryptographic credentials to top-tier agent governance. It provides protocol mechanics, algorithmic selection matrices, common vulnerability remediations, and engineering benchmarks as an authoritative desktop reference for backend developers, architects, and security engineers.

🔗 Related Cheat Sheets: Network Security Protocols & Defense Systems Cheat Sheet · Cryptography & Encryption Algorithms Cheat Sheet · HTTP Status Codes Cheat Sheet · AI Agent Harness Architecture Cheat Sheet · AI Agent Skills System Cheat Sheet

---

0. Mental Models & 12-Layer Architecture Topology

The Three Core Dimensions (Who vs What vs Who-on-behalf)

4 Abstract Tiers & 12-Layer Architecture Matrix

┌────────────────────────────────────────────────────────────────────────┐
│ Unified Observability & Continuous Security: Audit Logs | Metrics | Alerts | SIEM | Threat Response │
└────────────────────────────────────┬───────────────────────────────────┘
                                     │
┌───────────────────────────────┐    │    ┌───────────────────────────────┐
│ L4: Machine & Agent Identity  │    │    │ L4: Machine & Agent Identity  │
│ Layer 10: API & Machine mTLS  │    │    │ Layer 11: AI Agent Delegation │
│ Layer 12: Security Testing    │    │    │                               │
├───────────────────────────────┤    │    ├───────────────────────────────┤
│ L3: Authorization & Governance│    │    │ L3: Authorization & Governance│
│ Layer 08: Policy Engines (PDP)│◄───┼───►│ Layer 07: AuthZ Models (RBAC)│
│                               │    │    │ Layer 09: Enterprise SSO/SCIM │
├───────────────────────────────┤    │    ├───────────────────────────────┤
│ L2: Modern Auth Protocols     │    │    │ L2: Modern Auth Protocols     │
│ Layer 06: MFA & Passkeys      │    │    │ Layer 05: OAuth 2.0 & OIDC    │
├───────────────────────────────┤    │    ├───────────────────────────────┤
│ L1: Foundation & Credentials  │    │    │ L1: Foundation & Credentials  │
│ Layer 02: Password Hashing    │    │    │ Layer 03: Server Sessions/HTTP│
│ Layer 01: Trust & Lifecycle   │    │    │ Layer 04: Tokens & JWT State  │
└───────────────────────────────┘    │    └───────────────────────────────┘
                                     ▼
           Users · Applications · Microservices · Autonomous AI Agents

---

1. Foundation & Credential Security (L1: Identity Foundation)

Layer 01: Identity & Security Foundations

Establishing identity infrastructure begins with rigorous trust models and structured lifecycle states:

• Subjects: Entities that can be identified and assigned permissions: human users (workforce / consumers), machine workloads (background daemons / microservice containers), and software agents (autonomous AI entities).
• Identity Lifecycle: Provision $\to$ Manage / Update $\to$ Suspend $\to$ Revoke / Deprovision. Gaps anywhere lead to orphaned accounts or lingering dormant privileges.
• Trust Boundaries: Never assume trust on untrusted boundaries (such as frontend clients or external API callers). Boundary crossings must enforce explicit identity verification and access evaluation.
• Principle of Least Privilege (PoLP): Entities must be granted strictly the minimal permissions necessary to perform their current task, with time decay and scope restriction.
• Defense-in-Depth: Avoid single points of failure. Internal network isolation is not enough; internal microservices must enforce strong mutual authentication and authorization.

---

Layer 02: Password & Credential Security

Passwords remain widely used and require modern cryptographic storage and handling:

Four Golden Practices for Password Defense

1. Salting & Peppering:
   • Salt: Globally unique per user, generated by a cryptographically secure pseudo-random number generator (CSPRNG, $\ge 16$ bytes), stored alongside the hash in plaintext to eliminate multi-account rainbow table attacks.
   • Pepper: Globally shared secret key (HMAC key), managed outside the database in KMS/HSM or environment secrets, preventing offline cracking even if database dumps are compromised.
2. NIST SP 800-63B Modern Password Guidelines:
   • Eliminate mandatory 90-day expiration and complex composition rules (e.g. mandatory symbols/mixed case), which induce predictable patterns.
   • Enforce minimum length ($\ge 8$–12 characters) and encourage memorable passphrases.
   • Screen against breached password dictionaries (e.g. Have I Been Pwned / top 100,000 common passwords).
3. Rate Limiting & Credential Stuffing Defense:
   • Apply sliding window rate limits (Token Bucket / Leaky Bucket) scoped by IP, device fingerprint, and account ID.
   • Implement progressive exponential backoff and frictionless challenges (Cloudflare Turnstile / reCAPTCHA v3).
4. Secure Account Recovery Flow:
   • Issue cryptographically secure, single-use, short-lived tokens (TTL $\le 15$ minutes) stored in the database as salted hashes.
   • Maintain uniform timing and messaging to eliminate user enumeration ("If an account exists for this email, a reset link has been dispatched").

---

Layer 03: Server-Side Sessions & Cookie Governance

Stateful web architectures rely on server-side sessions and secure cookies:

---

Layer 04: Tokens, JWT & Stateless Session Management

Modern distributed architectures favor stateless or hybrid token-based authentication:

JWT Structure & Common Pitfalls

JSON Web Tokens (JWT) consist of three dot-separated components: Header.Payload.Signature.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJleHAiOjE3MDAwMDAwMDB9.iG8j2...
└───────────────┬───────────────────┘ └──────────────────┬──────────────────────┘ └────┬────┘
      Header (Metadata & Algorithm)              Payload (Claims Data)              Signature (Verification)

• Prevent alg: none Vulnerabilities: Verification logic must hardcode the expected signing algorithm (e.g. enforce RS256), never allowing the unverified token header's alg value to dictate the verification routine.
• Algorithm Selection: Use HS256 (symmetric shared secret) only within single closed-perimeter systems. In microservices, distributed setups, or federated architectures, use asymmetric signing (RS256, ES256, or Ed25519/EdDSA), allowing downstream services to verify claims using public keys only.

Token Storage & Architecture Trade-off Matrix

Refresh Token Rotation (RTR) & Reuse Detection Flow

sequenceDiagram
    autonumber
    actor Client as Client App
    participant Auth as Authorization Server
    participant Res as Resource Server

    Client->>Auth: Authenticate (Credentials / MFA)
    Auth-->>Client: Issue Short-lived Access Token (5-15m) + Long-lived Refresh Token (7-30d)
    Client->>Res: Fetch data (Bearer Access Token)
    Res-->>Client: Verify & Return data
    Note over Client,Res: 15 minutes elapse; Access Token expires
    Client->>Res: Fetch data (Expired Access Token)
    Res-->>Client: 401 Unauthorized (Token Expired)
    Client->>Auth: Exchange Refresh Token for fresh tokens
    Note over Auth: Invalidate old Refresh Token; issue fresh pair
    Auth-->>Client: Issue New Access Token + New Refresh Token
    Note over Client,Auth: Anomaly Defense: If the revoked Refresh Token is re-submitted
    Auth->>Auth: Detect Token Family Reuse Breach
    Auth-->>Client: 400 Bad Request: Invalidate entire token family immediately & alert

---

2. Modern Authentication Protocols (L2: Authentication Protocols)

Layer 05: OAuth 2.0 & OpenID Connect (OIDC)

• OAuth 2.0 (RFC 6749): Governs delegated authorization ("grant an application permission to access protected resources").
• OpenID Connect (OIDC 1.0): Identity authentication layer built on top of OAuth 2.0. Standardizes identity assertions via digitally signed id_token (JWT format) and the /userinfo endpoint to answer "who is the user?".

OAuth 2.0 Core Grant Types Comparison

---

Layer 06: Multi-Factor Authentication (MFA), Passkeys & Passwordless

NIST and the FIDO Alliance categorize authentication factors into three classes:

1. Knowledge Factor (Something you know): Passwords, PINs, security questions.
2. Possession Factor (Something you have): Hardware security keys (YubiKey), mobile authenticators (TOTP apps), smartcards.
3. Inherence Factor (Something you are): Fingerprint, Face ID, iris biometric scans.

MFA Mechanisms & Phishing-Resistance Matrix

Passkeys (FIDO2) Challenge-Response Flow

[Browser / Authenticator Device]                 [Relying Party (Auth Server)]
       │                                                       │
       │─── 1. Initiate Login Request ────────────────────────►│
       │◄── 2. Return Random Challenge + RP ID (Origin) ───────│
       │                                                       │
 ┌─────┴─────────────────────────┐                             │
 │ Hardware Security Enclave/TPM │                             │
 │ • Match Origin with RP ID     │                             │
 │ • Prompt biometric / PIN      │                             │
 │ • Sign challenge with private key                           │
 └─────┬─────────────────────────┘                             │
       │                                                       │
       │─── 3. Submit Signature (ClientDataJSON, Signature) ──►│
       │                                                       │
       │                                              ┌────────┴────────┐
       │                                              │ Verify signature│
       │                                              │ using stored    │
       │                                              │ public key      │
       │                                              └────────┬────────┘
       │                                                       │
       │◄── 4. Verification successful: Issue Session / JWT ───│

---

3. Authorization Models & Policy Governance (L3: Authorization & Governance)

Layer 07: Authorization Models

Once identity is authenticated, the system must evaluate whether the entity has permission to perform specific actions:

---

Layer 08: Policy Decision & Enforcement Engines

In large-scale architectures, Policy-as-Code and Decoupled Decision/Enforcement represent the industry standard.

The Decoupled Authorization Model (XACML / NIST)

• PAP (Policy Administration Point): Where policies are authored, versioned, and distributed (e.g. GitOps repositories).
• PDP (Policy Decision Point): The engine that evaluates loaded policies against input contexts to produce an Allow or Deny verdict.
• PEP (Policy Enforcement Point): The interceptor enforcing PDP decisions (API gateways, service mesh sidecars, middleware).
• PIP (Policy Information Point): Supplies dynamic runtime attributes to the PDP (e.g. looking up resource ownership in databases or risk scores in Redis).

Modern Declarative Policy Engines Comparison

---

Layer 09: Enterprise Identity & Single Sign-On (SSO)

SAML 2.0 vs OIDC for Enterprise Federation

Supporting Standards & IdP Selection

• SCIM 2.0 (RFC 7643/7644): System for Cross-domain Identity Management. Standardizes RESTful APIs for IdPs (e.g. Okta, Microsoft Entra ID) to automatically provision and deprovision users in SaaS apps, preventing orphaned accounts.
• Enterprise IdP Selection Matrix:
  • Keycloak: Leading open-source standard by Red Hat. Comprehensive feature set (SAML/OIDC/Kerberos/User Federation); ideal for self-hosted sovereign deployments.
  • Auth0 / Okta: Leading commercial cloud IdP. Turnkey enterprise SSO integrations, compliance certifications, and global edge reliability.
  • Clerk / Logto / Zitadel: Developer-first modern identity platforms designed for Next.js, React, and multi-tenant B2B SaaS.

---

4. Machine & AI Agent Identity (L4: Machine & Agent Identity)

Layer 10: API & Machine-to-Machine Identity (M2M)

In zero-trust microservice meshes, the assumption of network perimeter trust is discarded. Both east-west internal traffic and north-south API requests must verify machine identity:

---

Layer 11: AI Agent Identity, Autonomous Delegation & Guardrails

As AI Agents autonomously invoke tools, query datastores, and execute tasks across systems, traditional static human or server identity models fall short. A specialized identity framework with provenance, bounded delegation, dynamic privilege contraction, and human circuit breakers is required:

[Human User]
       │ 1. Delegates high-level objective ("Book travel to SF and file expense")
       ▼
[AI Orchestrator Agent]
       │
       │─── 2. Request Token Exchange (RFC 8693) from Auth Server
       │       • Passes User Access Token as Actor Token
       │       • Constrains Scope: ["travel:book", "expense:create"]
       │       • Enforces short TTL: 10 minutes
       │
       ├───► [Auth Server] ──► Issues downscoped Capability Token
       │
       │─── 3. Invokes Travel API autonomously (Bearing Capability Token)
       ▼
 ┌────────────────────────────────────────────────────────┐
 │ Agent Runtime Guardrails & Human-in-the-Loop (HITL)    │
 │ • Financial threshold exceeded (> $1,000) pauses task  │
 │ • Triggers push notification for Human Confirmation    │
 │ • Records tamper-proof execution audit trail (Trace ID)│
 └────────────────────────────────────────────────────────┘

Core Pillars of AI Agent Governance

1. Agent Identity & Cryptographic Attestation:
   • Each agent possesses its own workload identity (SPIFFE ID or asymmetric keypair), recording its underlying model version, prompt template hash, and human custodian.
2. Delegated Token Exchange (RFC 8693):
   • When an agent acts on behalf of a human user, it executes an OAuth 2.0 Token Exchange to convert the user's broad credential into a strictly scoped, short-lived (TTL $\le 10$m) capability token, preventing prompt injection attacks from hijacking broader account permissions.
3. Runtime Guardrails & Human-in-the-Loop (HITL):
   • Deterministic API Allowlisting: Agents can only invoke endpoints verified against explicit OpenAPI schemas.
   • Human Confirmation for High-Risk Actions: Actions crossing financial, destructive, or access thresholds pause execution pending human approval.
4. Non-Repudiation Audit Trails & Emergency Kill-Switches:
   • Immutable logging of prompt inputs, decision metadata, tool invocations, and response hashes.
   • Immediate kill-switch mechanisms capable of revoking all active agent capability tokens globally within seconds.

---

5. Continuous Testing, Observability & Architecture Selection (L4 & Practices)

Layer 12: Security Testing, Auditing & Threat Monitoring

OWASP Top 10 API Security Risks & Target Defenses

The Four-Step Observability & Continuous Auditing Loop

1. Structured Audit Logging: Record tamper-proof security events (actor, action, resource, timestamp, ip, user_agent, status, decision_reason).
2. Telemetry Metrics: Monitor authentication failure rates, token refresh spikes, and 401/403 anomaly distributions.
3. SIEM / User and Entity Behavior Analytics (UEBA): Ingest audit events into SIEM pipelines; trigger heuristics for "impossible travel", credential stuffing, and unusual bulk export patterns.
4. Automated Incident Response: High-risk threat detection triggers immediate IdP session invalidation, terminating tokens and enforcing step-up biometric MFA on subsequent requests.

---

Production Architecture Selection Matrix (8 Core Scenarios)