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.