Identity Manager

OIDC, OAuth 2.0, JWT, JOSE — one identity surface for every API and agent.

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.

Request a demo Read the docs

StandardsOIDC · OAuth 2.0 · JWT · JOSE · SAML · mTLS
FederationLDAP · AD · OIDC · REST · Database
TiersSystem · Project · Team

01 · Authentication standards

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

policy-oidc
policy-oauth-2-auth
policy-jwt-auth
policy-jose-implementation
policy-jose-validation
policy-mtls-authentication
policy-saml
basic-auth
digest-auth

Same lane for AI

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.

Authentication standards panel — OIDC selected, with discovery URL, client ID, scopes, and a row of nine supported method tabs underneath.

02 · OIDC + OAuth 2.0

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

PKCE
Discovery URL
JWKS
RS256 · ES256 · PS256 · EdDSA
hybrid mode
nonce + state
role mapping
distributed session

OIDC + OAuth 2.0 flow — browser to identity provider, Apinizer validates the ID token via JWKS, role claims map to Apinizer scopes, the request is forwarded with a hybrid token.

03 · JWT authentication

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

RS256
RS384
RS512
rotating JWKS
refresh tokens
claims-to-header
third-party JWT

Decoded JWT view — header showing alg RS256 and kid, payload with iss, sub, aud, exp, scope, roles, and a signature panel highlighting the JWKS endpoint that validated it.

04 · JOSE — JWS + JWE

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

policy-jose-implementation
policy-jose-validation
JWS
JWE
dynamic JWKS
kid · x5t · x5c
RSA · EC · OKP
sign-by-issuer

Same lane for AI

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.

JOSE policy editor — sign + encrypt toggles on, claims list with iss, aud, exp, jti, sub, and a dynamic key panel pulling a JWK from a remote URL with TTL 3600 seconds.

05 · Directory federation

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

AuthenticationLDAP
AuthenticationDatabase
AuthenticationApi
policy-saml
Keycloak
Azure AD
Okta

06 · Credentials & API keys

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

@SecretData
API key rotation
per-credential RL
endpoint ACL
IP groups
geo restrictions
time-of-day

07 · Three-tier permission model

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

PermissionService
System / Project / Team
custom roles
RBAC
Repository-layer enforcement

Permission matrix — three columns System, Project, Team; rows for read proxy, deploy proxy, manage credentials, rotate keys; checks on the cells, denied marks where appropriate.

08 · Audit & traceability

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

analytic-auth-record
Elasticsearch
Repository audit aspect
@SecretData masking
diff capture
APIops parity

Same lane for AI

Same audit pipeline records every AI Gateway authentication — token spend per credential, denied prompts, and rotation events all in one log.

In the box

What's included

The capabilities below are part of the standard install — no add-on SKUs and no separate licenses.

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

Keep going

Identity Manager docs

Configuring federation, issuing credentials, and writing ACLs.

Read the docs

OIDC + OAuth 2.0 quickstart

Sample configurations for Keycloak, Azure AD, Okta, and Auth0.

Open quickstart

JOSE recipes

Sign and encrypt request bodies for B2B and regulated partners.

Browse recipes

API Portal

Self-service credentials backed by Identity Manager.

See API Portal

Architecture

How identity flows through the gateway, manager, and portal.

See the suite

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.

Request a demo Read the docs