Standards reference
The guides on this site describe each feature in plain language and avoid specification numbers. This page is the one place that maps those plain names back to the standards LumoAuth implements, for readers who need to cite a specification, check interoperability, or audit compliance.
Each entry gives the name used elsewhere on this site, the standard, and what LumoAuth uses it for.
Signing in and issuing tokens (OAuth 2.0 and OpenID Connect)
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| OAuth 2.0 (the core sign-in and token protocol) | RFC 6749 | The authorize and token endpoints, the authorization code, client credentials and refresh token grants, and every other flow on this site builds on it. |
| OAuth 2.1 (the consolidated best-practice edition of OAuth 2.0) | OAuth 2.1 (draft) | The baseline the MCP authorization pages follow: PKCE for every client, no implicit or password grants, exact redirect URI matching. |
| Bearer tokens | RFC 6750 | How an access token is sent in the Authorization: Bearer header. |
| OpenID Connect (OIDC) | OpenID Connect Core 1.0 | ID tokens, the UserInfo endpoint, and standard claims such as sub, email and name. |
| Discovery document | RFC 8414 and OpenID Connect Discovery | The /.well-known/openid-configuration and /.well-known/oauth-authorization-server files that list your organization's endpoints and keys. |
| Proof Key for Code Exchange (PKCE) | RFC 7636 | Protects the authorization code for browser and mobile apps that cannot keep a client secret. |
| Pushed authorization requests (PAR) | RFC 9126 | Lets an app send the authorization request to the server first and redirect with a short reference, so the request cannot be tampered with in the browser. |
| Signed authorization requests (JAR) | RFC 9101 | Authorization requests carried as a signed token, required by the highest-security profile. |
| Signed authorization responses (JARM) | OpenID JWT Secured Authorization Response Mode | Authorization responses returned as a signed token (response_mode=jwt), so the app can verify the redirect came from LumoAuth. |
| OAuth 2.0 security best practice | OAuth 2.0 Security Best Current Practice | The hardening rules LumoAuth applies by default: exact redirect URI matching, PKCE, no implicit grant, sender-constrained or short-lived tokens. |
| Issuer identifier in the response | RFC 9207 | The iss parameter on the redirect back to your app, which prevents a mixed-up redirect from another server. |
| Rich authorization requests | RFC 9396 | The authorization_details parameter: fine-grained, structured descriptions of what a token may do, used by agent and payment-style consent. |
| Resource indicators | RFC 8707 | The resource parameter that pins a token to one API (audience). |
| Device authorization (sign in on another device) | RFC 8628 | Sign-in for TVs, CLIs and other devices without a browser: the user enters a short code on their phone or laptop. |
| Client-initiated backchannel authentication (CIBA) | OpenID CIBA Core 1.0 | A service (or an AI agent) asks a user to approve a sign-in or an action on their own device, without a redirect. |
| OAuth for native apps | RFC 8252 | Best practice for mobile and desktop apps: system browser, PKCE, loopback and custom-scheme redirects. |
| Dynamic client registration | RFC 7591 and RFC 7592 | Lets an application (for example an MCP client) register itself through the API instead of in the portal, and read its registration back afterwards with the registration access token (LumoAuth implements the read endpoint of RFC 7592, not update or delete). |
| Token exchange (delegation) | RFC 8693 | Swapping one token for another with a narrower audience or on behalf of another party. This is the basis of agent delegation chains and Cross App Access. |
| JWT client authentication and the JWT bearer grant | RFC 7523 | Clients that prove who they are with a signed token instead of a secret, and workload federation. |
| Mutual TLS client authentication | RFC 8705 | Clients that authenticate with a certificate; also binds a token to that certificate. |
| Token revocation | RFC 7009 | The endpoint an app calls to invalidate a token at sign-out. |
| Token introspection | RFC 7662 | The endpoint an API calls to ask whether a token is still valid and what it allows. |
| Logout | OpenID Connect RP-Initiated Logout, Front-Channel Logout, Back-Channel Logout and Session Management | Signing a user out of LumoAuth and of every application at once. |
| Step-up authentication challenge | RFC 9470 | How an API tells a client that the user must sign in more strongly (for example with a second factor) before it will serve a request. |
Authentication method reference (amr) values | RFC 8176 | The claim that records how a user signed in (password, one-time code, passkey and so on). |
| Financial-grade API (FAPI) 2.0 | FAPI 2.0 Security Profile | The strictest profile, which combines PAR, PKCE, sender-constrained tokens and signed requests for banking and other high-value APIs. |
Token formats and keys
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| JSON Web Token (JWT) | RFC 7519 | The signed token format for ID tokens, access tokens and agent tokens. |
| JWT access token profile | RFC 9068 | The standard claims (iss, aud, client_id, scope, …) inside a JWT access token, and the application/at+jwt type. |
| JSON Web Key (JWK) and key sets (JWKS) | RFC 7517 | The format of the public keys published at /.well-known/jwks.json so that applications can verify tokens. |
| Key thumbprint | RFC 7638 | A stable fingerprint of a public key, used as the key ID and as the agent's identity in signed requests. |
| Sender-constrained tokens (DPoP) | RFC 9449 | Binds a token to a key the client holds, so a stolen token cannot be replayed from another machine. |
Protecting APIs, resources and MCP servers
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| Protected resource metadata | RFC 9728 | The /.well-known/oauth-protected-resource document an API or MCP server publishes so that clients can discover which authorization server protects it. |
| Model Context Protocol (MCP) authorization | MCP Authorization specification | How AI agents obtain tokens for MCP tool servers. It builds on OAuth 2.0, PKCE, dynamic client registration and protected resource metadata. |
| Client ID metadata documents | OAuth Client ID Metadata Document (draft) | Lets an MCP client identify itself with a URL to a metadata file instead of registering first. |
| Cross App Access (identity assertion JWT authorization grant, ID-JAG) | Identity Assertion Authorization Grant (draft) | An enterprise identity provider issues an assertion that lets one application (or agent) call another application's API on a user's behalf, without a second sign-in. |
| Authorization API (AuthZEN) | OpenID AuthZEN Authorization API 1.0 | The standard "may this subject do this action on this resource?" request and response shape used by the /api/v1/authz endpoints. |
AI agent identity (AAuth)
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| Signed HTTP requests (HTTP message signatures) | RFC 9421 | How an agent proves who it is: every request carries a signature made with the agent's private key, covering the method, target, headers and body digest. |
| Request body digest | RFC 9530 | The Content-Digest header that the signature covers, so the body cannot be altered in transit. |
| Structured HTTP header fields | RFC 8941 | The syntax of the Signature and Signature-Input headers. |
| Token exchange (delegation) | RFC 8693 | The chain-of-agency tokens that record which user asked which agent to act. |
| Actor claims in delegated tokens | OAuth Actor Profile for Delegation (draft) | The act claim chain inside a delegated token that names every agent in the chain. |
| Transaction tokens | Transaction Tokens (draft) | Short-lived tokens that carry one request's context across internal services. |
| Attestation-based client authentication | Attestation-Based Client Authentication (draft) | An agent or app proves it runs in a trusted environment before it receives credentials. |
| Workload identity (SPIFFE JWT-SVID) | SPIFFE JWT-SVID | Workload federation: a Kubernetes or cloud workload trades its platform identity token for a LumoAuth agent token. |
| Agent cards (A2A) | Agent2Agent protocol v1.0 | The signed /.well-known/agent.json document that describes and verifies an agent. |
| Trace correlation | W3C Trace Context | The traceparent header that links agent requests, approvals and audit entries. |
Security events and shared signals
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| Security event tokens | RFC 8417 | The signed event format for "session revoked", "credential changed" and similar notifications. |
| Push delivery of security events | RFC 8935 | LumoAuth posts events to a receiver's URL. |
| Poll delivery of security events | RFC 8936 | A receiver fetches events from LumoAuth on its own schedule. |
| Account-risk event types (RISC) | OpenID RISC Profile 1.0 | Event types such as account disabled or credential compromised, alongside the CAEP catalogue. |
| Subject identifiers for security events | RFC 9493 | How an event names the user, device or session it is about. |
| Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP) | OpenID SSF 1.0 and OpenID CAEP 1.0 | The stream configuration (/.well-known/ssf-configuration) and the catalogue of event types that LumoAuth sends and receives. |
Directory sync and enterprise sign-in
| Plain name used on this site | Standard | What LumoAuth uses it for |
|---|---|---|
| SCIM 2.0 (user and group provisioning) | RFC 7642, RFC 7643 and RFC 7644 | Automatic creation, update and removal of users and groups from an identity provider or HR system, and outbound sync to other apps. RFC 7643 defines the user and group schema; RFC 7644 defines the HTTP protocol. |
| SCIM event notifications (feeds and subscriptions) | SCIM Notify (draft) | The /Feeds and /Subscriptions resources that let a provisioning client subscribe to change events instead of polling. |
| SAML 2.0 | OASIS SAML 2.0 | Enterprise single sign-on, both as an identity provider for your applications and as a service provider that trusts your customers' identity providers. |
| LDAP authentication | RFC 4513 | Sign-in against a corporate directory using simple bind over TLS. |
| Passkeys (WebAuthn and FIDO2) | W3C Web Authentication and FIDO Alliance CTAP | Phishing-resistant sign-in with a device biometric or security key, and the FIDO Metadata Service lookup used to verify authenticators. |
| Private network address ranges | RFC 1918 | Addresses that outbound integrations (webhooks, log sinks, SCIM targets) refuse to call, to prevent requests being aimed at your internal network. |
Why the guides avoid specification numbers
Most readers want to know what a feature does and how to turn it on, not which document defines its wire format. The guides therefore use the plain names in the left-hand column. When you need the exact specification, for a security review, a vendor questionnaire or an interoperability test, this page is the lookup table.