Identity, authentication, and authorization get collapsed into one topic far too often, even though architecturally they are three different layers of trust.
The chapter breaks them into a sequence of decisions about user identity, federation, sessions, tokens, and access policy, while OAuth 2.0/OIDC, SAML, WebAuthn, and mTLS each land in their proper place.
In interviews and architecture reviews, it helps you separate the login flow from access policy, explain trust assumptions clearly, and avoid mixing user auth with service-to-service trust.
Practical value of this chapter
Design in practice
Use guidance on identification, authentication, and authorization in a modern identity stack to define architectural security requirements before implementation starts.
Decision quality
Validate solutions through threat model, security invariants, and production control operability, not compliance checklists alone.
Interview articulation
Frame answers as threat -> control -> residual risk, linking business scenario to concrete protection mechanisms.
Trade-off framing
Make trade-offs explicit for identification, authentication, and authorization in a modern identity stack: UX friction, latency overhead, operational cost, and compliance constraints.
Spec
OpenID Connect Core
Basic OIDC specification for user authentication over OAuth 2.0.
In production, what most often breaks down is not cryptographic algorithms, but the boundaries of responsibility: where identification ends, where authentication begins, and where to make an authorization decision. This chapter captures a practical model Identification Authentication Authorizationand shows which protocols are commonly used today for user and service scenarios.
Trio: Identification - AuthN - AuthZ
Identification
Who did you say you were?
- The subject reports the identifier: email, phone, employee ID, service account name.
- An ID does not prove identity by itself.
- Must be unique in its domain (tenant/org/system).
Authentication (AuthN)
Are you really who you say you are?
- Factor checking: password, OTP, passkey (WebAuthn), client certificate.
- AuthN result: verified identity + method and confidence level.
- Current standard for users: MFA and no password-only scenarios.
Authorization (AuthZ)
What are you allowed to do
- Checking rights to act on a resource in a specific context.
- RBAC, ABAC, ReBAC or policy-as-code (OPA/Cedar).
- AuthZ's decision always depends on subject + action + resource + context.
BCP
OAuth 2.0 Security BCP
IETF Guidelines for Secure Implementation of OAuth 2.0.
How it is usually implemented now
User -> App/API
- The IdP (OIDC) authenticates the user.
- The application receives session or tokens and updates them according to a secure policy.
- The API checks the access token (issuer, audience, expiry, signature).
- AuthZ runs on the API or in a dedicated policy engine.
Service -> Service
- mTLS to confirm service identity at the network level.
- Short-lived credentials/tokens instead of long-lived secrets.
- Fine-grained AuthZ by policy-as-code for internal APIs.
- Full audit trail: who, where, why and with what decision policy.
Control Plane
- Centralized IdP + identities directory.
- Separate policy store and policy decision point.
- JIT access, least privilege, periodic access review.
- Automatic revoke and deprovision when role/status changes.
Basic protocols and standards
OAuth 2.0 + PKCE
For: Delegated access to APIs
Where: Web/mobile/public clients
Note: Use Authorization Code Flow + PKCE; Do not use implicit flow.
OpenID Connect (OIDC)
For: Authentication layer on top of OAuth 2.0
Where: SSO, user login, identity claims
Note: ID Token is about identity, Access Token is about access to API.
SAML 2.0
For: Enterprise SSO
Where: Legacy enterprise integrations
Note: Often found in corporate IdP/SSO portals.
WebAuthn / FIDO2
For: Passwordless and phishing-resistant auth
Where: End-user authentication
Note: Passkeys as a modern baseline for user authentication in client applications.
mTLS + workload identity
For: Service-to-service authentication
Where: Microservices and zero-trust networks
Note: Combine with SPIFFE/SPIRE or similar trust system.
SCIM
For: Identity provisioning lifecycle
Where: B2B/B2E user lifecycle
Note: Not the AuthN/AuthZ protocol, but the provisioning/deprovisioning standard.
Important: JWT is a token format, not an authentication/authorization protocol. Without valid rules for verifying and managing keys, JWT by itself does not solve the security problem.
Common mistakes in production
- Confuse AuthN and AuthZ: successful login does not mean the right to any action.
- Store access tokens for too long or without strict key rotation.
- Use one 'admin' role without detailed rights for operations and resources.
- Validate JWT signature, but do not validate issuer/audience/expiry/nbf.
- Leave 'eternal' service keys instead of short-lived identity-based credentials.
- Do not maintain a single audit log of authorization decisions and access events.
Additional materials
Related chapters
- Rights management approaches: ACL, RBAC, ABAC, ReBAC - Expands the AuthZ part by comparing policy models and their practical ACL/RBAC/ABAC/ReBAC trade-offs.
- Zero Trust: a modern approach to architectural security - Shows how identity becomes the foundation for continuous verification and policy enforcement per request.
- API Security Patterns - Applies AuthN/AuthZ to API runtime: token validation, object-level authorization and deny-by-default checks.
- Encryption, keys and TLS: how it works in practice - Connects identity to cryptographic trust: certificates, PKI, mTLS and authenticated service channels.
- Secrets Management Patterns - Complements the chapter with secret/key lifecycle controls required to keep production authentication reliable.