Closed by default, identity end to end.

Flexway validates JWTs with JWKS keys discovered and cached in the background; key rotation happens with no restart and no wave of 401s. The issuer (iss) and audience (aud) are checked, and several issuers from different providers coexist in one configuration (auth.issuers). An issuer can accept several audiences for the duration of a rename. By default only asymmetric algorithms are accepted: none and HS* are refused.

Opaque tokens are checked through RFC 7662 introspection (opaque_tokens), with the same rules as a JWT and a response cached without exceeding its expiry; an unreachable provider gives 503. The gateway consumes identities, it does not issue them: the issuer remains your organisation's own.

Binding a token to its holder, through an mTLS certificate (RFC 8705) or DPoP proof of possession (RFC 9449), is upcoming; the choice between the two remains open.

The authentication requirement comes from the contract's security section, not from a separate table: scopes for oauth2 and openIdConnect, roles for http bearer, supplemented by x-flexway-scopes. An operation with no anonymous alternative requires an identity; tags carry no requirement. No operation is served with a weaker requirement than the one declared.

Roles are read from the claim named by roles_claim; without it, no role is satisfied. Refusals follow HTTP semantics - 401 when the identity is missing or fails verification, 403 when it is not sufficient - with WWW-Authenticate and an RFC 9457 body. Whether a resource belongs to a tenant is still checked by the service, the only one that knows its data.

Whatever is not declared does not pass: an undeclared header is removed, an undeclared query parameter is refused by name, an undeclared method receives 405 with Allow, a non-allowed origin is refused. CORS is declared as a policy, global or per host, and security response headers are set on every response.

Body and parameters are validated against the contract schema: 422 naming each faulty field, with a code taken from the JSON Schema keyword and renamable (errors.field_codes). The body is read only if the operation declares one, within the server.limits.max_body bound (413 beyond). The mode is set per host or per operation (x-flexway-validation) - full, params or off - and the allow list of headers and parameters is kept in every mode.

No upstream error is relayed as is: gateway refusals follow RFC 9457, with a closed catalogue of codes and a request_id and trace_id in the response, the details staying in the log.

When a caller can produce neither a workload identity nor an OAuth token, an API key remains possible, constrained by design. It is presented in a header only (Authorization: ApiKey), never in a URL parameter; an apiKey scheme placed elsewhere is refused at load. The store keeps only the SHA-256 fingerprint, compared in constant time, and the key exists in clear only once, at creation. Each key is bound to a tenant, to named operations and to a mandatory expiry.

Rotation keeps two active entries during the switchover; revocation means removing the entry, re-read by each replica on reload, with no restart. A stable prefix (fwk_) lets secret scanners spot a key published by mistake, and each call carries the key's identifier, never its value, in the trace and the log.

A client certificate is verified by the TLS listener (server.tls) or attested by the edge through x-forwarded-client-cert, trusted from a trusted peer only; it is bound to a tenant and to operations (auth.mtls.clients). The contract decides which mechanism satisfies which alternative: a token never replaces a key, nor the reverse. Neither the key nor the attested certificate reaches the upstream, and an API key remains an identity, not an authorisation.

The tenant comes from the verified identity - the claim declared for the issuer (tenant_claim) - and never from a client-supplied header, which can be forged. The gateway writes it upstream under auth.tenant_header; an incoming tenant header is overwritten. Rate and quota counters are indexed by tenant, with no possible sharing.

Rate limiting counts per caller (issuer and subject, otherwise the client address behind server.trusted_proxies), never per calling pod: two users behind the same server-side client have separate counters. An authenticated response is cached only with a tenant and subject key, declared by the operation alone; without tenant and subject, nothing is cached.

This cache isolation is held by a blocking test run on every change, with a counter-test that strips the subject from the key. Cross-tenant access is treated as a critical vulnerability, not a defect.

audit.decisions writes one authz_decision line per decision - all of them, or refusals only - with the operation, the path template, the hashed subject and the agent chain. Each line is chained to the previous one (seq, prev, hash) per replica, which makes deletion or tampering verifiable. The log holds no personal data in clear.

The rest of defence in depth lies in the product itself: distroless non-root image, read-only filesystem, SBOM, signature and attestation on the image digest, no native plugin and no script in the configuration. The administration surface sits on a separate port and accepts no key. A timestamped, correlated and verifiable audit helps you meet the logging and cybersecurity requirements that apply to your platform.