Standards & Security Extensions
cidaas builds on proven OAuth 2.0, OpenID Connect, and related standards. This page helps you choose which feature for which guarantee — not by RFC number alone. Deep how-tos are linked where they exist; entries marked Overview only describe capability without a dedicated guide yet.
Guarantees
Not RFC numbers — concrete outcomes. Use these to pick the right standard below.
Standards
Jump to a tile or read the category details below.
Client authentication & request integrity
RFC 7523 — JWT client authentication
The client authenticates at the token endpoint with a signed JWT (client_assertion) instead of posting client_id + client_secret. With private_key_jwt the secret never leaves the client; with client_secret_jwt the secret only signs the assertion (HMAC) and is not sent as a form field.
When to choose: Confidential apps that should avoid sending a raw client secret on every token request.
Docs: Validate token / JWKS · App management · Introspect token
RFC 7523 — JWT bearer grant (NHI)
A non-human identity proves itself with a signed JWT as the grant — no password, no interactive login. Distinct from JWT client authentication on this page, where the JWT only authenticates the OAuth client (client_assertion).
When to choose: Workloads, agents, or services that should get a token from a cryptographic identity instead of a shared secret.
Docs: Overview on this page
RFC 9126 — PAR (pushed authorization requests)
The client pushes authorize parameters to /par first and receives a short-lived request_uri. The browser then only sends client_id + request_uri — scopes, PKCE, and hints never travel in a long authorize URL.
When to choose: You want less URL exposure, better audit of authorize params, or complex authorize payloads.
Docs: Pushed Authorization Request (PAR) · OAuth2 flows overview
CIBA — Backchannel auth + Ping mode
The user authenticates on a separate device (out-of-band). With ping mode, cidaas notifies the client when authentication is done; the client then fetches the token once.
When to choose: Call-centre, POS, Smart TV, or other flows where the initiating device should not host the full login UI.
Docs: CIBA flow
RFC 9101 — JAR (signed authorization requests)
Authorize parameters are packed into a signed JWT (request). cidaas verifies the signature with the app public key. Typical combo: sign once inside PAR, then the browser only carries client_id + request_uri.
When to choose: You need tamper-proof authorize parameters end-to-end (often with PAR).
Docs: Overview on this page · related: PAR, JWKS on validate token
RFC 8176 — AMR value standardization
Standardizes Authentication Methods References (amr) values (password, MFA, biometrics, passkeys, and more) so relying parties interpret how the user authenticated consistently.
When to choose: You enforce or log authentication strength from token claims.
Docs: AMR value catalog · MFA / step-up ACR · Pluggable verification
Token security
RFC 8705 — mTLS + token binding
The access token is bound to the client certificate present at issuance (cnf.x5t#S256). Later calls must present the same cert — a stolen bearer token is useless without it.
When to choose: High-assurance backend clients that already use mutual TLS.
Docs: Overview on this page · see also Client credentials
RFC 9449 — DPoP (proof of possession)
The token is bound to the client’s key pair. Each request carries a signed DPoP proof; an intercepted token is useless without the private key — same class of protection as mTLS binding, without certificates. Fits mobile apps and SPAs (e.g. SDK .useDPoP()).
When to choose: Public or mobile clients where you want holder-of-key tokens without deploying client certs.
Docs: Overview on this page · App management (DPoP app flag)
RFC 7516 — JWE (encrypted tokens)
cidaas can encrypt the token with the client’s public key. Only the holder of the private key can read claims — intermediaries see ciphertext.
When to choose: Claims must stay confidential in transit beyond TLS (regulated or high-sensitivity payloads).
Docs: Access / ID token & JWE
RFC 8037 — Ed25519 for JWTs
Support for Ed25519 / EdDSA signing — modern, compact elliptic-curve signatures for JWTs alongside RSA and other algorithms.
When to choose: Prefer modern asymmetric signing for third-party API clients and key rotation hygiene.
Docs: Validate token / JWKS · Client secret and signing key rotation
Authorization & least privilege
RFC 8707 — Resource indicators
The client requests a target API (resource); the issued access token is scoped to that audience — not valid everywhere. Limits blast radius if a token leaks.
When to choose: Multiple APIs / audiences and you want least-privilege tokens by default.
RFC 8693 — Token exchange
Exchange one token for another for delegation, microservices, or context change — without handing long-lived user credentials between services.
When to choose: Service-to-service acting on behalf of a user, BFF patterns, or narrowing scopes between tiers.
Docs: Token exchange
RFC 9396 — Rich authorization requests (RAR)
More expressive least-privilege authorization payloads than scopes alone — the client can describe the exact action and resource in the request.
When to choose: APIs where a scope string is too coarse (payments, fine-grained resource access).
Docs: Overview on this page
RFC 9470 — Step-up authentication
An API or RP can demand stronger authentication for a sensitive action. The user steps up (re-auth or MFA) only when needed — not on every request.
When to choose: High-value actions (payments, profile changes) that need a higher acr than the existing session.
AuthZEN — Standard authorization API
OpenID AuthZEN enriches OAuth: scopes and roles still gate which APIs a token may call; the PDP then evaluates the concrete action on a resource using attributes, runtime context, PIP data, and relationships. Versioned policies and evaluation audit add versionability and traceability.
When to choose: You already use scopes and roles, but need centralized, context-aware decisions (and an audit trail) that a token claim cannot carry.
Docs: AuthZEN overview
RFC 9728 — Protected resource metadata
A protected API can advertise its own OAuth metadata so clients discover requirements instead of hard-coding every endpoint configuration.
When to choose: Multi-API landscapes where clients should auto-discover authorization server and resource requirements.
Docs: Overview on this page
Advanced / regulated
FAPI 2.0 — Message signing (phase 1)
Adds signing at the message level so request/response integrity and non-repudiation go beyond transport security — aimed at regulated finance-style workloads.
When to choose: Open-banking or similar regimes that require signed application messages.
Docs: Overview on this page
Token Status List
Revocation and status at scale for large token populations without per-token introspection storms.
When to choose: High-volume token issuance where you still need timely revocation.
Docs: Overview on this page · related: Introspect token
Related documentation
- OAuth2 Basics
- OAuth2 Flows overview — choose Authorization Code, PKCE, Client Credentials, Device Code, PAR, Token Exchange
- Access Token / ID Token Claims
- Integration Roadmap — project planning; link back here for security posture choices
Contact us on our support page or at [email protected].