Identity and zero trust

Product guide: what the capability brings, for whom, its limits and the version that delivered it - no configuration syntax.

What it does	Verifies each caller's identity against your identity provider, and requires exactly what the contract asks, operation by operation. Four first-class identities: an OIDC token (a JWT or an introspected opaque token), an API key, a client certificate (mTLS), the headers of a trusted mesh. Closed by default: an undeclared header does not reach the upstream, an undeclared parameter is refused, so is a browser origin not allowed
Why it matters	Security no longer depends on each API team. The caller's tenant comes from a verified source (a signed claim, a key, a certificate), never from a header the client writes itself. Every authorization decision can be written to an audit log, subject hashed
Use cases	One provider for employees and another for customers, in the same gateway; API keys for a partner or a batch, bound to a tenant, operations and an end date; a bank's server presenting a certificate; renaming an audience without cutting the old tokens
Limits	Flexway consumes tokens, never issues them; sender-constrained tokens (DPoP, mTLS RFC 8705) are not built; verifying incoming webhook signatures and IP address lists come in 1.8.0
Since	0.3.0 (OIDC, closed by default), 0.1.0 (API keys, client certificates), 1.0.0 (opaque tokens, decision audit, several audiences)
Configure	Wiring your identity provider, API keys, Client certificates (mTLS)