Security
Apiway enforces security at the gateway — per operation, not per API. Every API deployed through the platform gets authentication and authorisation out of the box.
Secure by Default
Section titled “Secure by Default”If your OpenAPI specification defines no security schemes, Apiway applies them automatically:
- OAuth 2.0 client credentials flow is configured
- Each operation gets a scope based on its
operationId - Consumers receive a JWT with only the scopes their subscription entitles them to
- The gateway enforces scopes on every request
You don’t need to configure security manually unless you want to override the defaults.
Security Model
Section titled “Security Model”Per-operation enforcement. Security is driven by a SecurityCheckPolicyElement on each operation’s inbound policy pipeline — not by a single API-wide setting. This means different operations can have different security requirements.
Authorisation is resolved on every request. The gateway does not cache an authorisation decision for the life of a token. On each request it verifies the credential and then resolves the caller’s current entitlements from the entitlements service. Revoke an entitlement and the next request fails — you do not wait for a token to expire.
The only thing cached on the security path is the signing key set (JWKS), for five minutes.
Two Authorisation Paths
Section titled “Two Authorisation Paths”Which path applies depends on who is calling, and they behave differently. This matters if you are designing around joiner-mover-leaver or revocation.
| Machine-to-machine | Human and on-behalf-of | |
|---|---|---|
| Credential | OAuth 2.0 client credentials | Authorisation code, or a delegated (OBO) token |
| Scopes in the token | Yes — correlated from the subscription at mint | None, by design |
| How authorisation is decided | The token’s scope claim is authoritative for the operation | The caller’s delegated role, resolved server-side into entitlements |
| Entitlements read per request | Yes | Yes |
| Effect of revoking access | Next request | Next request |
For machine-to-machine callers the token’s scope claim states what was granted, and the gateway enforces it per operation. For human and on-behalf-of callers the token deliberately carries no scope claim at all — a person’s authority comes from their delegated role, which is resolved when the request arrives rather than when they signed in.
Zero Trust
Section titled “Zero Trust”The gateway is the enforcement point, and it makes no assumption based on where a request came from.
- No network-derived trust. Enforcement is driven by each operation’s security element, derived from your OpenAPI specification. When the gateway runs inside your cluster as a micro-gateway, a service-to-service call is checked exactly like one arriving from the internet.
- Explicit verification, every request. A missing or malformed credential returns 401 with a
WWW-Authenticatechallenge, and the failure is recorded as a security event rather than silently dropped. - A verified credential is not an authorised one. A valid token presented to an operation it
lacks the scope for returns 403
insufficient_scope— authentication and authorisation are separate decisions and both are made per request. - Least privilege by operation. Scopes are per operation, not per API, so a consumer entitled to read is not thereby entitled to write.
Supported Authentication
Section titled “Supported Authentication”| Method | Use Case |
|---|---|
| OAuth 2.0 Client Credentials | Machine-to-machine, service accounts |
| OAuth 2.0 Authorization Code | User-facing applications |
| OAuth 2.0 PKCE | Single-page apps, mobile apps |
| API Keys | Simple integrations, development |
| JWT Bearer | Token-based access from external IdPs |
Multiple authentication methods can coexist on the same API — even on the same operation.
OIDC Convenience Endpoints
Section titled “OIDC Convenience Endpoints”When an API uses OAuth 2.0 security, Apiway’s gateway automatically exposes standard OpenID Connect endpoints:
| Endpoint | Path |
|---|---|
| Discovery | /.well-known/openid-configuration |
| JWKS | /.well-known/jwks |
| Authorize | /oauth2/v2/authorize |
| User Info | /oauth2/v2/userinfo |
| Revoke | /oauth2/v2/revoke |
| Introspect | /oauth2/v2/introspect |
These are generated automatically — you don’t need to implement them in your backend.
In This Section
Section titled “In This Section”- Authentication — OAuth flows and API key configuration
- Scopes & Entitlements — How permissions are modelled and enforced