Foundational

A map of IAM standards

Choose the right family of standards for authentication, authorization, and provisioning.

IAM standards solve different problems. Before selecting one, describe the interaction: who is communicating, which trust relationship exists, and what result the recipient needs.

The quick map

NeedRelevant standard or familyWhat to read here
Delegate access to an APIOAuth 2.0OAuth, grant types, endpoints
Sign in to an application using an identity providerOpenID ConnectOpenID Connect, in depth
Discover authorization servers and protected APIsRFC 8414, OIDC Discovery, RFC 9728Discovery and metadata
Accept tokens in an API and request step-upRFC 6750, RFC 9470Resource servers
Bind tokens to a client keyDPoP, RFC 9449DPoP
Protect or enrich the authorization requestPAR, JAR, RARPAR and JAR, RAR
Use OAuth from browsers and mobile appsBrowser-based apps draft, RFC 8252BFF, native apps
Manage browser sessionsHTTP cookies, RFC 6265Cookies and sessions
Exchange identity assertions, often for enterprise SSOSAML 2.0SAML
Create and manage users and groups across systemsSCIM 2.0SCIM
Authenticate with public-key credentials on the webWebAuthn / FIDOModern authentication
Represent and validate a set of claimsJWT, JWS, JWKJWT and token validation, token claims
Sign in devices, exchange tokens, or bind tokens to a clientOAuth extensionsAdvanced OAuth
Access a directory or authenticate inside a Windows domainLDAP, KerberosLDAP and Kerberos
Notify other systems of revocations and compromiseShared Signals, CAEP, RISCShared Signals
Ask a policy engine for an authorization decisionAuthZEN, XACMLPolicy engines
Give workloads an identity without stored secretsSPIFFE, workload federationNon-human identities

A format is not a complete protocol

A JWT is a token format. It does not tell you, by itself, which issuer is trusted, which keys are accepted, which recipient it is intended for, or whether it is the right kind of token for a request. JWT and token validation lists the checks a recipient applies.

Likewise, “uses JSON” says little about the trust model. A secure integration needs the surrounding protocol, validation rules, and operational controls.

Avoid one-protocol thinking

A business application can use OIDC for sign-in, SCIM for account management, and an application-specific API for permission assignment. Those choices can coexist.

An enterprise portfolio may support both SAML and OIDC because applications have different capabilities. Evaluate the actual integration and supported profiles rather than assuming one label describes every behavior.

Read standards in layers

Start with the core specification, then identify security guidance, applicable profiles, errata, and your implementation’s documentation. A published standard may contain older options that current security guidance advises against.

The articles in this section explain concepts. They are not complete implementation or conformance checklists.

References

Knowledge is better when it is shared.Improve this page

Type to search the entire handbook.