Identification, authentication, and authorization get collapsed into one topic far too often, even though architecturally they are three different layers of trust.
The chapter separates decisions about subjects, federation, sessions, tokens, service identity, and access policy so OAuth 2.0/OIDC, SAML, WebAuthn, SCIM, and mTLS each land in the right place.
In interviews and architecture reviews, it helps you separate sign-in from access policy, explain trust assumptions clearly, and avoid mixing user authentication with service-to-service trust.
Practical value of this chapter
Design in practice
Separate identification, authentication, and authorization in the architecture: who the subject is, how it proved itself, and which action is allowed.
Decision quality
Review token lifecycle, service identity, policy enforcement points, and audit trail instead of focusing only on the sign-in form.
Interview articulation
Frame the answer as a flow: identifier, proof of identity, session or token, access decision.
Trade-off framing
Make the cost of MFA, short-lived tokens, centralized policies, and access revocation explicit.
Spec
OpenID Connect Core
Core OIDC specification for user authentication on top of OAuth 2.0.
In production, identity systems usually fail not because cryptography is weak, but because responsibility boundaries are blurred: where identification ends, where authentication begins, and where authorization is decided.
This chapter gives a practical model for users and services: identity lifecycle, identity providers, tokens, OIDC/OAuth, SAML, WebAuthn, mTLS, SCIM, and access policies.
Identity architecture diagrams
The three modes separate the core questions: who the subject is, how it proves itself, and who decides access.
The subject presents an identifier
An identifier lets the system find a subject record, but it does not prove that the caller is that subject.
1. Who claims identity
Subject
A user, service, or device presents a username, email, employee number, or account name.
2. Lookup and normalization
Directory / IdP
The directory maps the identifier to a record, tenant, status, and source of truth.
3. Result
Identity record
The system gets a normalized record and identity claims, but authentication still has to happen.
Key reminder
- An identifier is not proof of identity.
- The record must be unique inside its domain.
- Identity lifecycle matters as much as sign-in.
Trio: Identification - AuthN - AuthZ
Identification
Who the subject claims to be
- The subject presents an identifier: email, phone number, employee number, or service account name.
- The identifier helps find a record, but it does not prove the caller's identity by itself.
- The record must be unique inside its domain: tenant, organization, or system.
Authentication
Authentication / AuthN: proof of identity
- Factors are verified: password, one-time code, passkey, client certificate, or workload key.
- Authentication produces a verified subject, verification method, and identity claims.
- For users, the baseline is MFA and avoiding password-only flows for sensitive scenarios.
Authorization
Authorization / AuthZ: access decision
- The system checks whether a subject can perform an action on a resource in the request context.
- RBAC, ABAC, ReBAC, or policy-as-code with OPA/Cedar are common approaches.
- The decision depends on subject, action, resource, tenant, time, device, and other context signals.
BCP
OAuth 2.0 Security BCP
IETF recommendations for secure OAuth 2.0 implementation.
How it is usually implemented now
User → app/API
- The identity provider signs the user in through OIDC or SAML.
- The application receives a session, ID Token, Access Token, and sometimes a refresh token.
- The API validates token signature, issuer, audience, expiry, and not-before time.
- Authorization runs in the API or through a dedicated access-policy mechanism.
Service → service
- mTLS proves service identity at the secure channel level.
- Short-lived credentials are safer than long-lived secrets.
- Use fine-grained authorization policies for internal APIs.
- The audit trail should show who called what, why, and with which policy decision.
Control plane
- A central IdP and directory connect users, groups, services, status, and sources of truth.
- Separate the policy store and policy decision point from application code.
- JIT access, least privilege, and access reviews reduce accumulated permissions.
- Revocation and deprovisioning must trigger when role or employment status changes.
Main protocols and standards
OAuth 2.0 + PKCE
Use: Delegated API access on behalf of a user or application.
Where: Web apps, mobile clients, and public clients that cannot safely keep a secret.
Note: Use Authorization Code Flow with PKCE; avoid implicit flow in new systems.
OpenID Connect (OIDC)
Use: Authentication layer on top of OAuth 2.0.
Where: Single sign-on, user login, and federation with an external identity provider.
Note: ID Token describes the user sign-in, while Access Token grants limited permission to call an API.
SAML 2.0
Use: Enterprise single sign-on.
Where: Corporate portals, legacy IdPs, and B2B/B2E integrations.
Note: SAML remains a required standard in many large organizations.
WebAuthn / FIDO2
Use: Passwordless sign-in and phishing resistance.
Where: Client applications, admin panels, and sensitive operations.
Note: WebAuthn, FIDO2, and passkeys reduce password-theft risk.
mTLS + SPIFFE/SPIRE
Use: Authentication for services and workloads.
Where: Microservices, service meshes, and zero-trust networks.
Note: Combine mTLS with workload identity and short-lived certificates.
SCIM
Use: Identity lifecycle: account creation, updates, and deprovisioning.
Where: B2B/B2E, user and group sync between a directory and applications.
Note: SCIM does not replace AuthN/AuthZ; it automates provisioning and deprovisioning.
Important: JWT is a token format, not an authentication or authorization protocol. Without validation rules, key rotation, and revocation, it does not solve the security problem by itself.
Common mistakes in production
- Confusing authentication and authorization: a successful sign-in does not imply access to every action.
- Keeping access tokens alive for too long or without strict key rotation.
- Using a single admin role without permissions scoped by operation, resource, and tenant.
- Checking a JWT signature but ignoring issuer, audience, expiry, and not-before time.
- Leaving permanent service keys instead of short-lived credentials.
- Not keeping a single audit trail for authorization decisions and access events.
Additional materials
Related chapters
- Rights management approaches: ACL, RBAC, ABAC, ReBAC - Extends the authorization side by comparing policy models and ACL/RBAC/ABAC/ReBAC trade-offs.
- Zero Trust: a modern approach to architectural security - Shows how service identity and continuous verification become the trust foundation for every request.
- API Security Patterns - Applies AuthN/AuthZ to the API layer: token validation, object-level authorization, and default deny.
- Encryption, keys and TLS: how it works in practice - Connects identity to cryptographic trust: certificates, PKI, mTLS, and authenticated channels.
- Secrets Management Patterns - Complements the chapter with secret and key lifecycles required for reliable production authentication.