Identity Guard
Identity Guard is Apiway’s layered security model. It goes beyond simple authentication to verify who is calling, what they’re allowed to access, and whether their subscription entitles them to the requested operation.
Three Security Layers
Section titled “Three Security Layers”Layer 1 — Partner Verification
Section titled “Layer 1 — Partner Verification”Before any request is processed, the gateway verifies the caller’s identity:
- JWT validation — Signature, expiry, issuer, audience
- Subscription check — Does this credential belong to an active subscription?
- Tenant verification — Is the calling organisation registered and in good standing?
Invalid or expired credentials are rejected immediately. No backend resources are consumed.
Layer 2 — Identity Filtering
Section titled “Layer 2 — Identity Filtering”Not every authenticated user should see everything. Identity filtering controls access based on context:
- Scopes — The JWT carries only the scopes the subscription entitles. Each operation requires specific scopes.
- Roles — Roles are bundles of scopes. A
payments-readerrole grants read operations;payments-admingrants write operations too. - Subscription tier — Different SLA tiers can entitle different operations. A Free tier might exclude bulk export endpoints.
Layer 3 — Entitlement Protection
Section titled “Layer 3 — Entitlement Protection”The finest-grained control — per-operation entitlement enforcement:
- The gateway reads the
SecurityCheckPolicyElementon each operation - Resolves the caller’s current entitlements as part of validating the request — by subscription for a machine caller, by identity for a person or an agent acting for one
- Compares those against the operation’s required scopes, and returns 403 if any are missing
- The token’s scope claim proves who the caller is; it is not the grant. Authorising from it would let an entitlement withdrawn since the token was minted keep working until the token expired, which is why removing access takes effect on the very next request
How It’s Enforced
Section titled “How It’s Enforced”All three checks run on every request, before anything reaches your backend:
| Check | Failure Response |
|---|---|
| Invalid/expired token | 401 Unauthorized |
| Missing required scope | 403 Forbidden |
| Subscription inactive | 401 Unauthorized |
The token proves who the caller is. It is not the authorisation grant.
The gateway validates the token, then resolves the caller’s entitlements on every request — by identity for a human or on-behalf-of token, by subscription for a machine token — and authorises against that resolved set rather than against any scope claim carried in the token.
This is deliberate, and it is what makes revocation immediate. Authorising from a scope claim would let an entitlement withdrawn after the token was minted keep working until the token expired. Resolving live means a change to someone’s access takes effect on their very next request, with no waiting for expiry and no cache to flush.
If entitlements cannot be reached, the gateway keeps authorising every request against the last authorisation it knew to be good. Every request is still fully authorised; this is not a bypass. The bounded consequence is that an entitlement revoked during that window is not honoured until the service is reachable again.
External Identity Providers
Section titled “External Identity Providers”Apiway integrates with external IdPs for user authentication:
| Provider | Integration |
|---|---|
| Azure AD B2C | Native integration via admin-service |
| Microsoft Entra ID | Supported — standard OIDC |
| Okta | Supported — standard OIDC |
| Google Workspace | Supported — standard OIDC |
| Keycloak | Supported — standard OIDC |
| Clerk, Azure AD B2C | Supported — typically for your customers’ end users rather than your workforce |
| Any OIDC provider | Standard OpenID Connect discovery + JWKS validation |
You can configure different providers for different populations — your workforce directory for internal users, and a consumer identity product for the developer portal if your integrators are individuals rather than employees.
Credential Lifecycle
Section titled “Credential Lifecycle”Credentials are managed per subscription:
- Provisioned automatically when a subscription is approved
- Rotation — Generate new credentials without downtime; revoke old ones after migration
- Expiry tracking — Apiway monitors credential age and notifies consumers when rotation is recommended
- Gateway injection — For consumed external APIs, the gateway injects the provider’s credentials automatically
Revenue Protection
Section titled “Revenue Protection”Identity Guard isn’t just security — it protects revenue. Every request that bypasses authentication is an unmetered request:
- No authentication → no RU tracking → no billing
- Identity Guard ensures every request is tied to a subscription
- Unmetered consumption is impossible — the gateway rejects before the backend is reached