# Identity Manager > Federate with the directory you already run, validate any standard token at the edge, and govern who can call what — all from the Manager UI. Same identity policy enforces API and AI traffic, with three-tier permissions and Repository-layer audit on every change. *Identity Manager* ## OIDC, OAuth 2.0, JWT, JOSE — one identity surface for every API and agent. [Request a demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) **Highlights** - **Standards** — OIDC · OAuth 2.0 · JWT · JOSE · SAML · mTLS - **Federation** — LDAP · AD · OIDC · REST · Database - **Tiers** — System · Project · Team --- ## Capabilities ### 01 · Nine standards. One policy surface. Modern OAuth 2.0, OIDC, JWT, and JOSE alongside the mTLS, SAML, Basic, Digest, and Base64 flows still living in your legacy estate. Every method is a first-class policy with a UI — not a plugin you have to write — and the same enforcement runs in front of API and AI traffic. - OAuth 2.0 — Authorization Code (with PKCE), Client Credentials, ROPC, Refresh Token - OIDC — discovery URL, ID token + access token, JWKS, hybrid External + Internal mode - JWT — issue, validate, sign with RS256 / RS384 / RS512, third-party JWT with rotating JWKS - JOSE — JWS sign + JWE encrypt for claims, dynamic key fetching at the edge - mTLS, SAML 2.0, HTTP Basic, Digest, Base64 for every legacy partner that still needs them **Concepts:** `policy-oidc` · `policy-oauth-2-auth` · `policy-jwt-auth` · `policy-jose-implementation` · `policy-jose-validation` · `policy-mtls-authentication` · `policy-saml` · `basic-auth` · `digest-auth` > AI Gateway requests carry the same credential — every LLM call is authenticated by the OAuth or OIDC token already issued to the caller, not a shared API key. ### 02 · OpenID Connect, real Authorization Code with PKCE — out of the box. The OIDC policy is one Mongo collection with the full surface: Discovery URL or per-endpoint config, JWKS-backed signature validation, ID token + access token verification, hybrid mode (External IdP + Internal credentials), nonce + state replay protection, and role mapping from claims. Apinizer talks to Keycloak, Azure AD, Okta, or your in-house IdP using the same form. - Authorization Code Flow with PKCE enabled by default — protects public clients - Discovery URL auto-fills issuer, authorize, token, userinfo, and JWKS endpoints - JWKS-backed signature validation — RS256, RS384, RS512, ES256, ES384, ES512, PS256, EdDSA - ID token + access token validation, with iss / aud / exp / nonce / state checks and clock skew tolerance - Hybrid mode — external IdP for the user identity, Apinizer credentials for API authorization - Claim mapping for username, email, display name, and roles — straight into the request context - Distributed cache-backed session — `OIDC_SESSION` cookie survives a Worker restart - Logout endpoint with `id_token_hint` and post-logout redirect **Concepts:** `PKCE` · `Discovery URL` · `JWKS` · `RS256 · ES256 · PS256 · EdDSA` · `hybrid mode` · `nonce + state` · `role mapping` · `distributed session` ### 03 · JWT — issued by Apinizer, or validated against any third-party issuer. Apinizer can issue its own JWTs (RS256 / RS384 / RS512, environment-bound JwtKey2048), or validate tokens issued by another platform — with rotating JWKS and per-credential refresh tokens. Token claims, including custom mappings, are forwarded into the request context as headers (`X-Authenticated-UserId`, `X-Authenticated-UserRoles`) so upstream services don't re-decode the token. - Issue JWTs with RS256, RS384, RS512 — keys live in environment-scoped Secret Manager - Validate third-party JWTs (`jwt-3rd-party-auth`) — rotating JWKS, multiple issuers per policy - Grant types: Password, Client Credentials, Refresh Token — refresh count and TTL configurable - Token expiry per credential or per policy — configurable in seconds, minutes, hours - Claims-to-headers mapping — `sub`, `email`, `roles`, plus any custom claim - Per-policy variable resolution — `getResolvedXxx()` only, never raw fields, no cross-request leaks - Optional URL-parameter tokens for legacy callers, still audited and rate-limited **Concepts:** `RS256` · `RS384` · `RS512` · `rotating JWKS` · `refresh tokens` · `claims-to-header` · `third-party JWT` ### 04 · Sign and encrypt claims with JOSE — the standard, not a homegrown wrapper. When the body of a request needs to be a signed or encrypted JWT — banking partners, regulated payloads, B2B handshakes — Apinizer's JOSE Implementation policy turns any field, header, or body into a JWS / JWE with the right `iss`, `aud`, `exp`, `iat`, `jti`, `sub` claims and a chosen JWK. The JOSE Validation policy does the inverse on incoming traffic. Keys are fetched from Secret Manager — or pulled live from a remote endpoint with a cached, rotating fetch. - JOSE Implementation — sign (JWS) and / or encrypt (JWE) the request body, headers, or any variable - JOSE Validation — verify signature, decrypt, and project the claims back into the request context - Standard JWT claims — `iat` with offset, `iss`, `aud` list, `sub`, `jti`, `exp` from issue time or now - Custom claims map — additional fields injected from request variables - Dynamic key fetching — pull a JWK from a partner endpoint, cache it (TTL, capacity, mTLS, retry) - JWK formats — RSA, EC, OKP, oct — with `kid`, `x5t`, `x5c` thumbprint validation - Algorithms — RS256/384/512, ES256/384/512, PS256/384/512, EdDSA, plus HS family for shared-secret partners - Sign-by-issuer — pick the JWK at runtime from the resolved issuer claim, no hard-coded key id **Concepts:** `policy-jose-implementation` · `policy-jose-validation` · `JWS` · `JWE` · `dynamic JWKS` · `kid · x5t · x5c` · `RSA · EC · OKP` · `sign-by-issuer` > Same JOSE policy can sign the prompt sent to an external LLM — partner can verify the request really came from your gateway, not a stolen API key. ### 05 · Federate with the directory you already run. LDAP, Active Directory, SAML 2.0, an external REST IdP, or a database table — Apinizer authenticates against any of them with a configuration form, not a custom integration. Group memberships map to Apinizer roles on first login, so your existing org chart drives access without a parallel user store. - LDAP / Active Directory — bind, search filter, group mapping, advanced config (referral, paging, TLS) - SAML 2.0 service provider — IdP-initiated and SP-initiated SSO with assertion validation - Custom IdP via REST — `AuthenticationApi` calls your endpoint, maps the response, caches the result - Database-backed — authenticate against MySQL, PostgreSQL, Oracle, MSSQL with parameterized queries - External IdP federation through the same OIDC policy — Keycloak, Azure AD, Okta, Auth0 - Auto-provisioning on first sign-in — operator becomes a Project member without a ticket - All four backends usable as the password validator behind a JWT or OAuth 2.0 grant **Concepts:** `AuthenticationLDAP` · `AuthenticationDatabase` · `AuthenticationApi` · `policy-saml` · `Keycloak` · `Azure AD` · `Okta` ### 06 · Credentials with rotation, ACLs, and encryption built in. Every consumer — human, application, or agent — is a `Credential` with a `@SecretData` password, an issued API key, allowed proxies and methods, per-credential rate limits, IP groups, geo restrictions, and time-of-day windows. Rotation is a Manager action that the Worker picks up over the cache without breaking in-flight calls. - Issue, validate, rotate, revoke API keys from the Manager UI or APIops - @SecretData encryption at rest — passwords and secrets never persisted in plaintext - Per-credential rate limits, quotas, and burst windows — independent of API-level limits - Allowed and disallowed API proxies, endpoint-level ACLs, method-level restrictions - IP allow-lists and geo location data attached to the credential - Time-restricted access — partner contracts that only run during specific hours - Rotation flow coordinated with Worker cache — in-flight calls drain cleanly - Self-service via API Portal — applications request, approve, and rotate without filing a ticket **Concepts:** `@SecretData` · `API key rotation` · `per-credential RL` · `endpoint ACL` · `IP groups` · `geo restrictions` · `time-of-day` ### 07 · System · Project · Team — every check, the same service. A single `PermissionService` enforces three-tier access on every read, write, and deploy — UI, REST, AI Gateway, APIops. System administrators see everything; Project owners see only what they own; Team members see only the slice they were granted. Custom roles let you add narrower scopes without touching the gateway or the audit pipeline. - Three scopes — System, Project, Team — applied to every entity (proxy, credential, secret, policy) - Custom roles with RBAC — define them once, attach them anywhere - Permission checks at the service and Repository layer — UI cannot bypass them - Same `PermissionService` enforces UI actions, REST API calls, and APIops applies - Project-scoped secret manager — keys, certificates, JWKs visible only to the owning Project - Team membership drives Manager UI visibility and AI Gateway request authorization - Permission denial returns a structured 403 with the exact missing scope — easy to debug **Concepts:** `PermissionService` · `System / Project / Team` · `custom roles` · `RBAC` · `Repository-layer enforcement` ### 08 · Every authentication, every change — captured at the Repository layer. Authentication outcomes (success, denial, throttled, blocked) flow into the same Elasticsearch analytic store as request traffic. Manager-side changes — credentials, policies, ACLs, role mappings — are captured by an audit aspect at the Repository layer, so 'who issued the key, who rotated it, who granted the scope' is never an open question for the security team. - Authentication attempts indexed in Elasticsearch (`analytic-auth-record`) — success, denial, reason - Repository-layer audit aspect — every save / update / delete logged with user, timestamp, diff - Credential and policy changes carry the operator's identity end-to-end (UI → REST → DB) - Diff capture — old value, new value, masked for `@SecretData` fields - APIops applies appear in the same audit stream — no shadow change path - Realtime tail in the Manager UI plus long-term retention in Elasticsearch - Failed-authentication trends and brute-force detection sit on the same dashboard as traffic **Concepts:** `analytic-auth-record` · `Elasticsearch` · `Repository audit aspect` · `@SecretData masking` · `diff capture` · `APIops parity` > Same audit pipeline records every AI Gateway authentication — token spend per credential, denied prompts, and rotation events all in one log. --- ## Use cases ### Bring your existing directory to Apinizer LDAP, Active Directory, SAML 2.0, or an OIDC provider — your operators sign in with the credentials they already have, and group memberships map to Apinizer roles on first login. - LDAP / AD bind with group mapping - SAML 2.0 SSO and OIDC federation - Auto-provisioning on first login - Audit on every authentication attempt ### Self-service credentials for external developers Identity Manager backs the API Portal — applications request keys, get them auto-issued (or manually approved), and rotate them without filing a ticket. - Self-service credential request - Manual or auto-approval flows - Rotation without breaking in-flight calls - @SecretData encryption on storage ### Provision identities for agents and machines Agents and machine-to-machine clients get their own credentials, scoped to a Project, with token quotas and audit just like human users. - OAuth 2.0 Client Credentials for machines - Per-credential token quotas (works with AI Gateway) - ACLs at the API Proxy and endpoint level - Time-restricted access if needed --- ## What ships in the box ### Authentication - OIDC — Authorization Code with PKCE, ID + access token, hybrid mode - OAuth 2.0 — Authorization Code, Client Credentials, ROPC, Refresh Token - JWT — issue + validate, RS256/384/512, third-party JWKS, refresh tokens - JOSE — JWS sign + JWE encrypt, dynamic key fetching, kid / x5t / x5c - mTLS, SAML 2.0, HTTP Basic, Digest, Base64 - LDAP / AD federation, custom REST IdP, database-backed ### Authorization & governance - Three-tier permission model (System / Project / Team) - Custom roles + RBAC, applied across UI, REST, APIops, AI Gateway - Per-API-Proxy / endpoint / method ACLs - API Key issuance, validation, rotation, revocation - Per-credential rate limits, quotas, IP groups, geo restrictions - Time-of-day access windows for partner contracts - Repository-layer audit aspect with diff capture and `@SecretData` masking --- ## Resources - [Identity Manager docs](https://apinizer.com/developers/docs) — Configuring federation, issuing credentials, and writing ACLs. - [OIDC + OAuth 2.0 quickstart](https://apinizer.com/developers/docs/identity) — Sample configurations for Keycloak, Azure AD, Okta, and Auth0. - [JOSE recipes](https://apinizer.com/developers/docs/identity) — Sign and encrypt request bodies for B2B and regulated partners. - [API Portal](https://apinizer.com/products/api-portal) — Self-service credentials backed by Identity Manager. - [Architecture](https://apinizer.com/products) — How identity flows through the gateway, manager, and portal. --- ## Next step *One identity surface* **Stop running an identity layer per system.** See OIDC, OAuth 2.0, JWT, and JOSE running on the same gateway as your existing LDAP and SAML — and the same audit trail behind every credential rotation. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.