Identity Access Management Standards

Identity and access management (IAM) standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when designing, implementing or reviewing: OAuth 2.1/OIDC flows (authorization_code+PKCE, client_credentials, device code, token exchange), token design and validation (JWT/opaque, aud, scope, TTL, refresh rotation, revocation), SAML federation, deployment and configuration of IdPs (Keycloak, Authentik, Authelia, Zitadel, FreeIPA, Entra ID, Okta, Ory), passkeys/WebAuthn and MFA policy, SSO and SCIM provisioning, authorisation models (RBAC/ABAC/ReBAC) and policy engines (OpenFGA, SpiceDB, Cedar, OPA), PAM and just-in-time elevation, break-glass accounts, workload identity (SPIFFE/SPIRE, OIDC federation towards cloud), session management and single logout, and the joiner-mover-leaver cycle with access recertification.

Not applicable: see aws-standards/azure-standards/gcp-standards (the specific provider's IAM: policies, roles, conditions, SCPs), microservices-architecture-standards (mTLS/service mesh and context propagation between services), appsec-standards (authorisation failures inside the application code: IDOR, broken access control), secrets-management-standards (custody and rotation of static secrets), cryptography-pki-standards (signature algorithms, JWKS at the cryptographic level, certificate issuance), cicd-standards (configuration of the pipeline that consumes OIDC), windows-server-ad-standards (the directory and the Windows platform: forest, GPO, Kerberos and NTLM, Tier 0/PAW, gMSA/dMSA, krbtgt, AD CS — here, the modern federation and identity that sit on top of it or replace it), incident-response-forensics-standards (mass revocation of sessions and tokens during an identity compromise), identity-threat-detection-standards (the attack against identity, its detection and its response —session theft, token abuse, malicious OAuth consent, revocation as containment—; here, identity architecture, SSO, MFA and the account lifecycle), privacy-engineering-standards (the personal data the directory holds and its lifecycle).

2. Default decisions

Verify the latest version on the web before pinning it in a real project (§8). This domain moved a lot in 2025-2026: do not pin versions or spec statuses from memory.

3. Structure and conventions

Flow by client type (there are no other options)

Dead: implicit (response_type=token) and ROPC (password grant) — removed in OAuth 2.1 and discouraged by the security BCP (RFC 9700). If they show up in a design, they are a finding, not an option.

Token design

• aud mandatory and verified by every resource; a token valid for "everything" is a master key. iss, exp, nbf/iat validated; alg against an explicit allowlist (RFC 8725): forbidden to accept the token's alg without a list, and forbidden none.
• TTL: access 5-15 min; refresh rotating with reuse detection (reusing a refresh revokes the whole family). On public clients rotation is not optional.
• Revocation (RFC 7009) + propagation via CAEP/SSF. Assume revoking a JWT takes no effect until exp: the TTL is your revocation latency, size it accordingly.
• Fine-grained scope named by resource+action (invoices:read), never admin:all nor wildcards. Per-object permissions do not live in the token: they are queried from the PDP.
• Authorisation claims in the token only if they are stable and low-cardinality; dynamic roles in the token = stale permissions for the whole TTL.

Session and logout

• BFF session cookie: __Host- prefix, HttpOnly, Secure, SameSite=Lax (Strict if the flow allows it), without Domain. Rotation of the session identifier on authentication and on privilege elevation.
• Logout: RP-Initiated Logout (user trigger) + Back-Channel Logout (effective server to server). The four OIDC logout specs have been Final Specifications since September 2022; Session Management 1.0 (iframe + polling) is useless under third-party cookie restrictions: do not use it as the only mechanism.
• Inactivity and absolute timeouts defined by risk level; re-authentication (prompt=login, max_age) before sensitive operations (payments, MFA change, credential enrolment).

Passkeys and MFA policy

• Passkey/WebAuthn by default. WebAuthn Level 3 was proposed to W3C Recommendation on 20 Jul 2026 (CR of 26 May 2026); check its status before citing the version.
• NIST SP 800-63B-4: AAL2 must offer a phishing-resistant option; AAL3 requires a phishing-resistant authenticator with a non-exportable key → a synced passkey reaches AAL2 at most, and administrators need a device-bound key (FIDO2 hardware) or certificate-based authentication.
• Attestation: do not require it in public applications (it pushes the user to worse methods, such as SMS OTP); in corporate fleets requiring device-bound is reasonable.
• Portability solved: FIDO CXF (format, Proposed Standard) and CXP (encrypted transport) already deployed on iOS and on Android 14+ with Play Services 26.21+. Provider lock-in is no longer an argument for not adopting passkeys.

Authorisation

• RBAC for the organisational axis (roles per domain, not per person), ABAC for conditions (tenant, data sensitivity, time, network, device posture), ReBAC (Zanzibar model: OpenFGA, SpiceDB) when the real question is "what relationship does this subject have with this object?" (hierarchies, sharing, inheritance).
• Centralised PDP (decision) + PEP in every service (enforcement). Deny by default. The frontend hides options; it does not authorise.
• The authorisation model is versioned code with tests (§4) and its decision is auditable: subject, action, object, result, policy and policy version.
• Multi-tenant: the tenant is derived from the token/context, never from a request parameter.

Workload identity and federation

• Between services: SPIFFE/SPIRE SVIDs (X.509 for mTLS, JWT-SVID for APIs). Zero long-lived static secrets between services.
• OIDC federation towards cloud (CI, K8s): exact per-claim conditions. In GitHub Actions use repository_id, job_workflow_ref and environment; a sub with a wildcard requires StringLike (with StringEquals a * is compared literally and never matches, which tends to get "fixed" by widening permissions).
• GitHub issues an immutable subject claim (numeric IDs with @) on repos created, renamed or transferred from 15 Jul 2026: if AssumeRoleWithWebIdentity fails after a rename, the condition is fixed — the wildcard is never widened.

// Trust policy: the minimum acceptable (neither a wildcard sub, nor an absent sub)
"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
    "token.actions.githubusercontent.com:repository_id": "123456789",
    "token.actions.githubusercontent.com:environment": "production"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:job_workflow_ref": "org/infra-workflows/.github/workflows/deploy.yml@refs/heads/main"
  }
}

Joiner-mover-leaver cycle

• Single source of truth (HR → IdP). Onboarding, change and offboarding propagated by SCIM the same day; deprovisioning does not wait for the quarterly cycle.
• Recertification: privileged access quarterly, the rest half-yearly or yearly, with evidence and effective revocation of whatever is not confirmed (ISO 27001:2022 A.5.15/A.5.16/A.5.17/ A.5.18; NIST SP 800-53 AC-2/AC-5/AC-6).
• Service accounts: named owner, expiry, rotation and review; no shared human accounts.
• Third-party SaaS/OAuth integrations: inventory of connected apps, minimum scopes, periodic review and immediate revocation during an incident. In the UNC6395 campaign against Salesloft Drift OAuth tokens (8-18 Aug 2025, 700+ organisations) there was no malware nor MFA bypass: valid tokens and legitimate APIs were enough.

PAM, JIT and break-glass

• Zero standing access to production: JIT elevation with approval, short window, recorded reason and session recording. Ephemeral credentials (SSH/DB certificates lasting minutes), not stored passwords.
• Break-glass: ≥2 accounts, credentials under split/physical custody, an MFA method different from the usual one (FIDO2 or cert-based), excluded from conditional access policies but not exempt from the platform's mandatory MFA (Entra enforces it at the client application level, independently of CA exclusions), an alert on every use and documented periodic testing. An untested break-glass does not exist.

4. Quality and testing (CI gates)

1. Negative token tests (mandatory, they break the build): expired, foreign aud, invalid signature, tampered alg and none, different iss, unknown kid, replay of the code, missing PKCE or incorrect code_verifier, redirect_uri not an exact match, reused refresh (must revoke the family).
2. Policy as code with tests: OpenFGA/Cedar/OPA ship a test runner. Permit and deny cases, including cross-tenant. Policy without a test = policy not reviewed.
3. Federated trust scanning: a linter/policy that fails on a sub with a broad wildcard, an absent sub/aud condition, or StringEquals with * in trust policies.
4. Secret scanning of tokens and client secrets in repos and logs (the scanner is set by secrets-management-standards, as is the rotation procedure after the leak).
5. Conformance when implementing or parameterising an OP/RP: pass the OpenID Certification suites before exposing it, not after the incident.
6. Deprovisioning test: an integration test verifying that offboarding in the source of truth cuts access in the target systems.

5. Security

• Flow surface: redirect_uri with an exact match (no wildcards or suffixes), state and nonce verified, iss parameter in the response (RFC 9207) to avoid mix-up between several IdPs, PAR (RFC 9126) and/or JAR (RFC 9101) in high-risk profiles.
• Consent phishing / device code phishing: a consent screen naming the application and the data, controlled client registration (no open dynamic client registration), and an alert on new high-privilege consents.
• Token theft: a stolen bearer = access. Bind (DPoP/mTLS) what is valuable, short TTL, anomalous-use detection (geo/UA/volume) and propagated revocation.
• SAML (legacy only): validate the signature over the Response and the Assertion, Audience, Recipient, Destination, InResponseTo, NotOnOrAfter; reject unsigned assertions; watch for XML Signature Wrapping and canonicalisation; metadata and signing certificates rotated with overlap.
• User enumeration: uniform responses and timings in login, registration and recovery.
• Account recovery: it is the weak link of the entire MFA policy — treat it at the same level (do not fall back to SMS/email OTP to recover an account with a passkey).
• Passwords (where they exist): hashing and policy in cryptography-pki-standards and appsec-standards; here only the rule — no composition rules, no periodic expiry without a reason, with a check against breached lists.

6. Operability

• Authentication events as first-class telemetry: login ok/failed, MFA, method change, consents, token issuance/refresh/revocation, break-glass use and role changes. Logs kept intact and retained for forensics; alert on patterns (distributed brute force, MFA fatigue, break-glass use, credential enrolment on a privileged account).
• JWKS: cache per kid respecting the TTL, tolerance to rotation (publish the new key before signing with it, retire the old one afterwards), and do not hit the endpoint on every request. JWKS failure = fail-closed.
• The IdP is a SPOF: multi-AZ HA, capacity sized for the login peak, rehearsed DR and a degradation plan (what keeps working with the IdP down, and for how long).
• SSF/CAEP (SSF 1.0, CAEP 1.0 and RISC 1.0 approved as Final Specifications on 2 Sep 2025; CAEP interoperability profile in final review until 25 Sep 2026) to propagate revocation and risk changes in real time between providers.
• Rate limiting and anti-automation protection on /token, /authorize, login and recovery.

7. Sustainability and prohibitions

• Cadence: review the IdP's version and CVEs at least quarterly; self-hosted IdPs and IGA systems receive critical advisories frequently (e.g. Apache Syncope published in July 2026 patches for six vulnerabilities, including the privilege escalation CVE-2026-62183, with no binary hotfixes: they force an upgrade or a recompile).
• Follow the specs' status, not memory: OAuth 2.1 was still an Internet-Draft (draft-ietf-oauth-v2-1-15, 2 Mar 2026) in August 2026, although its content is already enforceable via RFC 9700 and the RFCs it consolidates.
• Debt with a fixed deadline: every exception (legacy client with a static secret, SAML, TOTP on admins) carries a date and a ticket.

FORBIDDEN

• ❌ implicit and ROPC (password grant) in any new design.
• ❌ Tokens in localStorage/sessionStorage or in the URL; tokens in logs.
• ❌ redirect_uri with a wildcard or prefix/suffix matching.
• ❌ Accepting the token's alg without an allowlist; alg: none; not verifying aud or iss.
• ❌ Non-rotating refresh tokens on public clients; access tokens lasting hours or days.
• ❌ Long-lived static secrets between services or in CI (OIDC federation exists).
• ❌ Federated trust policies with a wildcard sub (repo:org/*, :*) or without a sub condition.
• ❌ Shared human accounts, permanent admins, and break-glass without periodic testing.
• ❌ SMS/voice/email OTP as a factor on privileged accounts.
• ❌ Authorisation decided in the frontend or duplicated ad-hoc in every service.
• ❌ Dynamic client registration open to the internet without control or review.
• ❌ Manual deprovisioning or deprovisioning deferred to the audit cycle.
• ❌ Syncing passwords between systems instead of federating identity.

Quick review checklist

• Correct flow per client type, PKCE present, exact redirect_uri, state/nonce verified.
• Token with verified aud, alg on an allowlist, short TTL, rotating refresh, revocation with a plan.
• Phishing-resistant MFA; passkeys; admins with a device-bound key; recovery at the same level.
• Centralised authz, deny-by-default, tenant derived from the token, decisions audited and with tests.
• Workload identity without secrets; federated conditions by exact claim.
• SCIM with same-day deprovisioning; recertification with evidence; connected apps inventoried.
• JIT with approval and recording; break-glass ≥2 with independent MFA, alerted and tested.
• Auth events in the SIEM; JWKS cached and fail-closed; IdP with HA and rehearsed DR.

8. Mandatory web verification

Before pinning a version, spec status or behaviour in a deliverable:

1. OAuth 2.1: status in the IETF datatracker (is it still an Internet-Draft or already an RFC?) and the current revision; also the BCP for browser-based applications (draft-ietf-oauth-browser-based-apps) and FAPI 2.0 if it applies to the profile.
2. Versions and EOL of your IdP (Keycloak, Authentik, Authelia, Zitadel, FreeIPA, Ory) and its breaking changes in the latest major, plus open CVEs for the component.
3. WebAuthn Level 3: is it already a W3C Recommendation? Status of CXP/CXF and of real support in browsers and platforms.
4. SSF/CAEP/IPSIE: status of the interoperability profile and what your provider really supports (what is published ≠ what is implemented).
5. Authorisation engines: version and status of OpenFGA, SpiceDB, Cedar and OPA (syntax/major changes that break existing policies) and of SPIRE.
6. Federated claim format of the provider (GitHub, GitLab, K8s) before writing conditions: they change and break deployments.
7. NIST SP 800-63B-4 and the current phishing-resistant MFA guidance, if there is a compliance requirement.

If the web contradicts this document, the web wins — flag the discrepancy.