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 names an identifier: email, phone number, employee number, or service account name. That is an entry point, not proof.
- An identifier lets you find a record, not trust the caller: the next step proves identity, the name alone never does.
- If a record is not unique inside its domain — tenant, organization, or system — two different subjects will eventually start receiving each other's rights.
Authentication
Authentication / AuthN: proof of identity
- Factors are verified: password, one-time code, passkey, client certificate, or workload key.
- It yields a verified subject, verification method, and identity claims — and the access decision downstream rests on exactly those.
- A single password is no longer the baseline: for users, the floor is MFA and flows where a stolen password does not open the door.
Authorization
Authorization / AuthZ: access decision
- The question here is not “who is this” but “may they do this”: the right to perform a specific action on a specific resource in the request context.
- RBAC, ABAC, ReBAC, or policy-as-code with OPA/Cedar are common approaches.
- The more signals feed the decision — subject, action, resource, tenant, time, device — the sharper the access, but the costlier it is to debug denials and explain why a request was rejected.
BCP
OAuth 2.0 Security BCP
Current IETF recommendations for secure OAuth 2.0 implementations (BCP 240, January 2025).
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 shrink the blast radius of a leak: a stolen long-lived secret works for months, an expired token for minutes.
- An internal API is not a trusted zone by default: it needs fine-grained authorization too, or one compromised service unlocks everything behind it.
- The audit trail should show who called what, why, and with which policy decision.
Control plane
- When users, groups, services, and their status live in one directory, access has a single source of truth; scattered per-app accounts turn every audit into guesswork.
- 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 fire the moment a role changes or a person leaves — otherwise old rights outlive the employee and become a quiet attack vector.
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 is dated next to OIDC, yet in large organizations it stays mandatory: without it, some corporate integrations simply will not connect.
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 - Takes on secret and key lifecycles: without their rotation and safe storage, production authentication runs on luck.