# Identity and zero trust

> Verifies each caller's identity against your identity provider, and requires exactly what the contract asks, operation by operation. Four first-class…

Concept - Since version 0.3.0 - Flexway v1.6.3 - https://flexway.io/en/docs/product-identity/

> 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](https://flexway.io/en/docs/operations-identity/), [API keys](https://flexway.io/en/docs/operations-api-keys/), [Client certificates (mTLS)](https://flexway.io/en/docs/operations-client-certificates/) |