Separate API gateway JWT checks from backend authorization

What a gateway JWT check proves

A managed gateway that accepts a JWT has established a short list of facts. The token was signed by a key that the configured issuer publishes, it names that issuer and an audience the API was set up to accept, and the current time falls inside its validity claims. On an Amazon API Gateway HTTP API the JWT authorizer may also have confirmed that the token carries one of the route's scopes. Azure API Management's validate-jwt policy, Google API Gateway and Apigee's VerifyJWT policy run variations of the same checks, each with different defaults. ^[1][2][3][6]

Everything else stays with the backend. The gateway has not established that the token is an access token rather than an OpenID Connect ID token. It has not asked the issuer whether the token was revoked. A cached authorizer decision may have been made for a different route. Claim headers that the backend reads are only as trustworthy as the network path that delivered them. And no gateway can decide whether this caller may read or change the record named in the URL; OWASP puts that check in every function that uses a client-supplied identifier to reach data. ^[1][4]

The table maps each control question to the layer that can answer it, and the figure condenses the same split into four questions. The sections after them take the weakest rows in turn: token type, key caching, authorizer result caching, forwarded identity and object authorization. Provider documentation was reviewed on October 10, 2026.

Source. Conceptual model by the editors, based on AWS, Microsoft and Google gateway documentation and the OWASP API Security Top 10 2023. ^{[1][2][3][4][5]}

Method. Conceptual layering of documented gateway checks and OWASP guidance. It shows where a check can run, not how well any product performs it.

Accessible table and figure data

Figure 1 accessible table

Question	Checks	Where
Token is genuine	signature from a key the issuer publishes; valid time claims	gateway
Token is meant for this API	issuer, audience and, where possible, token type	gateway, when configured
Caller may use this route	scope or role for the method and path	gateway for coarse rules, backend for the rest
Caller may act on this object	ownership, tenant and record state	backend only

Figure 1 accessible table

Question	Checks	Where
Token is genuine	signature from a key the issuer publishes; valid time claims	gateway
Token is meant for this API	issuer, audience and, where possible, token type	gateway, when configured
Caller may use this route	scope or role for the method and path	gateway for coarse rules, backend for the rest
Caller may act on this object	ownership, tenant and record state	backend only

Download imageDownload table CSV

Claims each gateway validates

The matrix compares the built-in validators of the three managed gateways row by row. All three verify a signature against the keys their configuration points to, usually the issuer's published JWKS, and compare the issuer. AWS accepts only RSA-based algorithms, while validate-jwt lists PS256, RS256, RS512 and ES256 for asymmetric keys. The differences that change what a backend can assume sit in the audience, time and scope rows. ^[1][2][3] Microsoft's separate validate-azure-ad-token policy has its own trap: a tenant-id of organizations or common admits tokens from any directory, so set one tenant ID and explicit audiences. ^[8]

Audience is the row most often left loose. The AWS JWT authorizer compares aud with its audience list and falls back to client_id only when aud is absent. That fallback is what lets an Amazon Cognito access token, which has no aud, pass an authorizer whose audience is the app client ID, as in AWS's own template. Microsoft's validate-jwt page contradicts itself: the audiences element is marked as not required, yet its description says at least one audience must be specified. Google API Gateway makes audiences optional and, when they are omitted, accepts tokens whose aud is the API's service name with an HTTPS scheme. Audience separates APIs only when the issuer gives each API its own identifier, which RFC 9068 requires of authorization servers. It follows that an audience equal to a client ID shared by several APIs, as in the Cognito pattern, lets a token minted for one of them pass at the others, so give each API its own audience and set it explicitly on every product. ^{[1][2][3][7][9]}

Time checks differ in strictness. AWS checks that exp is in the future and that nbf and iat are in the past, and documents no clock leeway. APIM requires exp unless require-expiration-time is set to false, with a default clock-skew of 0 seconds. Google expects iat and exp in every token. Apigee's VerifyJWT checks expiry and not-before only if those claims are present, so a token without exp passes unless MaxLifespan is configured; that element faults when exp or nbf is missing. TimeAllowance defaults to zero. ^[1][2][3][6]

Scope is where coverage thins out. An HTTP API route passes a token that carries at least one of its authorizationScopes, up to ten per route. APIM checks scopes through required-claims, where match set to any with a space separator handles a space-delimited scp claim. Google's page documents no scope check, so on that gateway every route-level permission falls to the backend. Apigee extracts all claims into flow variables for later policies and conditions to evaluate. The table lists validators that change these rows. ^{[1][2][3][6][13]}

Source. AWS HTTP API JWT authorizer documentation, Azure API Management validate-jwt reference and Google API Gateway JWT authentication documentation, reviewed October 10, 2026. ^[1][2][3]

Method. Each cell restates the cited page. Not documented means the page describes no such check; it does not mean the product was tested and found to skip it.

Accessible table and figure data

Figure 2 accessible table

Check	AWS HTTP API	Azure APIM	Google API Gateway
Signature keys	jwks_uri; RSA algorithms only	OpenID config, certificate or inline key	JWKS, X509 or symmetric key file
Key ID (kid)	Must match a JWKS key	Matches key id, else tries each key	Not documented
Issuer	Must equal configured issuer	issuers list or OpenID config	x-google-issuer, one per definition
Audience	aud, or client_id if aud absent	audiences list	Optional; defaults to the service name
Time claims	exp, nbf and iat checked	exp required by default; 0 s skew	iat and exp required
Scopes	At least one route scope	required-claims, all or any	Not documented
Token type (typ)	Not checked; AWS says no standard way	Not documented	Not documented
Claims to backend	Request context claims	Jwt object in a context variable	Userinfo header, base64url payload

Figure 2 accessible table

Check	AWS HTTP API	Azure APIM	Google API Gateway
Signature keys	jwks_uri; RSA algorithms only	OpenID config, certificate or inline key	JWKS, X509 or symmetric key file
Key ID (kid)	Must match a JWKS key	Matches key id, else tries each key	Not documented
Issuer	Must equal configured issuer	issuers list or OpenID config	x-google-issuer, one per definition
Audience	aud, or client_id if aud absent	audiences list	Optional; defaults to the service name
Time claims	exp, nbf and iat checked	exp required by default; 0 s skew	iat and exp required
Scopes	At least one route scope	required-claims, all or any	Not documented
Token type (typ)	Not checked; AWS says no standard way	Not documented	Not documented
Claims to backend	Request context claims	Jwt object in a context variable	Userinfo header, base64url payload

Download imageDownload table CSV

Access tokens and ID tokens look alike

Token type is the weakest row in the matrix. RFC 9068 observes that its JWT access token layout is very similar to an OpenID Connect ID token, and AWS's JWT authorizer page says there is no standard mechanism to tell JWT access tokens from other JWTs such as ID tokens. A gateway that checks signature, issuer, audience and time can therefore accept an ID token as an API credential whenever the two kinds of token share those values. ^[1][9]

The standards answer is explicit typing. RFC 9068 requires a resource server to confirm that the typ header is at+jwt or application/at+jwt and to reject anything else. RFC 8725 recommends explicit typing for new uses of JWTs and requires mutually exclusive validation rules whenever one issuer can produce more than one kind, while warning that typing may not separate a new kind from older ones whose rules ignore typ. Its revision, draft-ietf-oauth-rfc8725bis-10 of August 21, 2026, keeps both points and adds that a typ of JWT is not effective explicit typing. On October 10, 2026, Datatracker showed it in the RFC Editor queue, blocked on a normative reference, so RFC 8725 remains the published practice. ^[9][10][11]

None of the four gateway validators documents a typ check. APIM's policy expression Jwt object has a Type property, but Microsoft does not say which header it reads, so confirm the value against a real token before writing a rule on it. Apigee's AdditionalHeaders element verifies named header values, so it could plausibly require typ, though Google does not describe that use. ^[2][6][12]

Until a gateway enforces the type, use the controls AWS names. Require authorization scopes on every route, or require an issuer or audience that the identity provider uses only for access tokens. On a REST API Cognito authorizer, adding scopes to a method is what switches it from ID token to access token handling. Where neither is possible, for example on Google API Gateway, which documents no scope check, in front of an identity provider that uses one issuer and audience for both kinds of token, the backend must reject ID tokens itself. ^[1][7]

Key caching sets the rotation and revocation window

Every gateway caches the issuer's signing keys, and the documented windows differ by a factor of 24. AWS caches the public key for up to two hours on a best-effort basis. APIM pulls the OpenID configuration, including the JWKS, every hour, and when a token names a kid missing from the cache, or retrieval fails, it fetches again at most once every five minutes; Microsoft says these intervals may change without notice. Google API Gateway caches the JWKS for five minutes, and Apigee caches a JWKS fetched by URL for 300 seconds. ^[1][2][3][6]

For rotation the arithmetic is simple. AWS advises a grace period during rotation in which both old and new keys are valid, because a key can stay cached for two hours. A workable rule is to publish the new key in the JWKS before the issuer signs with it, and to keep the old key published for at least the longest cache window among the gateways in front of your APIs. APIM's refresh on an unknown kid covers a new key quickly, but no more often than every five minutes. ^[1][2]

Removal is the uncomfortable direction. Taking a compromised key out of the JWKS does not stop a gateway that cached it. A reasonable inference from the documented windows is that tokens signed with a withdrawn key can keep passing for up to two hours on AWS, up to an hour on APIM and about five minutes on Google and Apigee. AWS documents no way to flush the cache. In APIM, one option is to list keys inline in issuer-signing-keys instead of using openid-config, which takes the cached document out of the path at the cost of rotating keys by policy change. ^[1][2]

Individual tokens fare no better. None of these validators asks the issuer about a token on each request, so a stolen but unexpired token passes until exp. Short access token lifetimes bound that, and AWS's HTTP API quotas bound the key fetch itself: the JWKS and OpenID discovery endpoints must answer within 1,500 ms, the JWKS response may not exceed 150,000 bytes, and none of these limits can be raised. Low-traffic APIs see more cache misses, so they pay the fetch latency more often. ^[1][13]

Source. AWS JWT authorizer workflow, APIM validate-jwt openid-config element, Google API Gateway JWT page introduction and Apigee VerifyJWT JWKS element, reviewed October 10, 2026. ^[1][2][3][6]

Method. Documented intervals converted to minutes: 2 hours x 60 = 120; 1 hour x 60 = 60; 5 minutes; 300 seconds / 60 = 5. AWS describes its value as a best-effort maximum; Microsoft says its intervals may change without notice. APIM's on-miss refetch, at most once per 5 minutes, is not plotted.

Accessible table and figure data

Figure 3 accessible table

Gateway validator	Documented wording	Minutes
AWS HTTP API JWT authorizer	Up to two hours, best effort	120
Azure APIM validate-jwt	Pulled every hour	60
Google API Gateway	Cached five minutes	5
Apigee VerifyJWT	Cached 300 seconds	5

Figure 3 accessible table

Gateway validator	Documented wording	Minutes
AWS HTTP API JWT authorizer	Up to two hours, best effort	120
Azure APIM validate-jwt	Pulled every hour	60
Google API Gateway	Cached five minutes	5
Apigee VerifyJWT	Cached 300 seconds	5

Download imageDownload table CSV

Cached authorizer decisions outlive the request

Lambda authorizers move every token check into your own function and then cache the answer. On REST APIs, authorizerResultTtlInSeconds defaults to 300 when unset, accepts up to 3,600 and turns caching off at 0. AWS's instruction for cached authorizers is that the returned policy must apply to all resources and methods across the API, because the gateway will not call the function again for the same identity within the TTL. ^[14][15]

The cache key explains why. A REST TOKEN authorizer is keyed on its token source header. A REST REQUEST authorizer combines all of its identity sources, in order. An HTTP API Lambda authorizer uses its identity sources as the key and, by default, applies one cached response to every route that uses the authorizer; with simple responses, that cached Boolean allows or denies all matching requests. The sequence shows a hypothetical orders API in which a read decision is reused for a delete. ^[14][16]

Two failure modes follow from that design. An IAM policy that names only the method that triggered the call will, once cached, deny the caller's next request to any other method, and the tempting fix, a wildcard Allow, removes the method distinction altogether. A route-aware decision returned as a simple response is silently reused on other routes. The documented remedies are to add $context.routeKey to an HTTP API authorizer's identity sources, to add $context.path and $context.httpMethod to a REST REQUEST authorizer's identity sources, or to return a policy that lists every method the principal may call. It also follows that identity sources which omit the credential, such as a tenant header alone, would let one caller's decision serve another. ^[14][16]

Staleness is the other cost. A cached Allow outlives a disabled account or a withdrawn role for the rest of the TTL, and any context values the authorizer returned are cached with it. Set the TTL to the longest period a revoked grant may keep working, not to the value that minimizes Lambda invocations.

# Example: an HTTP API Lambda authorizer whose cached result is keyed on the
# caller's token and on the route. Placeholder API ID, account and function.
aws apigatewayv2 create-authorizer \
  --api-id a1b2c3d4e5 \
  --name orders-authorizer \
  --authorizer-type REQUEST \
  --authorizer-uri 'arn:aws:apigateway:us-east-1:lambda:path/2015-03-31/functions/arn:aws:lambda:us-east-1:111122223333:function:orders-authorizer/invocations' \
  --authorizer-payload-format-version '2.0' \
  --enable-simple-responses \
  --identity-source '$request.header.Authorization' '$context.routeKey' \
  --authorizer-result-ttl-in-seconds 300

# Let only this API's authorizer invoke the function (def456 is the
# authorizer ID returned by the previous command).
aws lambda add-permission \
  --function-name orders-authorizer \
  --statement-id apigateway-orders-authorizer \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn 'arn:aws:execute-api:us-east-1:111122223333:a1b2c3d4e5/authorizers/def456'

Source. Conceptual hypothetical sequence built from the documented HTTP API Lambda authorizer caching behavior. ^[16]

Method. Hypothetical example, not a measured trace. The authorizer would have denied the delete if called; the gateway does not call it because the cache key, the Authorization header, matches.

Accessible table and figure data

Figure 4 accessible table

From	To	Message
Client	HTTP API	GET /orders with token A
HTTP API	Lambda authorizer	Identity source: Authorization header only
Lambda authorizer	HTTP API	isAuthorized true, cached for 300 s
HTTP API	Orders service	GET /orders forwarded
Client	HTTP API	DELETE /orders/42 with token A, 40 s later
HTTP API	HTTP API	Cache hit on token A; authorizer not called
HTTP API	Orders service	DELETE /orders/42 forwarded

Figure 4 accessible table

From	To	Message
Client	HTTP API	GET /orders with token A
HTTP API	Lambda authorizer	Identity source: Authorization header only
Lambda authorizer	HTTP API	isAuthorized true, cached for 300 s
HTTP API	Orders service	GET /orders forwarded
Client	HTTP API	DELETE /orders/42 with token A, 40 s later
HTTP API	HTTP API	Cache hit on token A; authorizer not called
HTTP API	Orders service	DELETE /orders/42 forwarded

Download imageDownload table CSV

Pass identity on a path only the gateway can use

Each gateway hands the validated identity to the backend differently. The AWS JWT authorizer passes the token's claims to the integration, where a Lambda function reads them from the request context. For HTTP integrations, parameter mapping can write a header from a context variable, and the choice of verb matters: overwrite replaces whatever the client sent under that name, while append, as its name and the comma-joining rule for repeated headers suggest, keeps the client's value alongside the gateway's. Authorization is a reserved header that mappings cannot change. ^[1][17]

Google API Gateway rewrites the request. When x-google-backend sets a backend address, the gateway replaces Authorization with an ID token for its own runtime service account, copies the original value to X-Forwarded-Authorization and sends the verified payload, base64url encoded, in X-Apigateway-Api-Userinfo. The extensions reference names that header X-Endpoint-API-UserInfo in one note, so check which one your backend receives. Google tells backends to accept only the gateway's identity, for Cloud Run by granting roles/run.invoker to the gateway's service account and not to allUsers. ^[3][21]

Microsoft describes two patterns. In the first, the token is intended for the backend, APIM passes it through unchanged and its own validation is defense in depth, so the backend still validates. In the second, the token is scoped to the gateway, APIM validates it and a separate mechanism, such as mutual TLS, secures the hop to the backend. Only the second pattern needs forwarded claims, and set-header defaults to override, which replaces a client-supplied header of the same name. ^[19][20]

The trust rule is an inference, but a direct one. A forwarded identity header is only as reliable as the narrowest path to the backend. If another API stage, a peered network or a public URL can reach the service without passing the gateway that wrote the header, that caller can send the same header. Close those paths: on a REST or WebSocket API, an API Gateway-generated client certificate lets an HTTP backend accept only requests from API Gateway even when it is publicly reachable, a Lambda resource policy can name the API's source ARN, and Cloud Run can admit only the gateway's service account. Google's pages do not say whether the gateway strips a client-supplied X-Apigateway-Api-Userinfo on methods without a security requirement, so test that before trusting it. ^{[1][3][18][21]}

<!-- Example inbound fragment: accept only an access token for this API with
     a delegated scope, then overwrite any caller header the client sent.
     v2.0 tokens carry the API's application (client) ID in aud. -->
<inbound>
  <base />
  <validate-jwt header-name="Authorization" require-scheme="Bearer"
                failed-validation-httpcode="401" output-token-variable-name="jwt">
    <openid-config url="https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration" />
    <audiences>
      <audience>00001111-aaaa-2222-bbbb-3333cccc4444</audience>
    </audiences>
    <issuers>
      <issuer>https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0</issuer>
    </issuers>
    <required-claims>
      <claim name="scp" match="any" separator=" ">
        <value>Orders.Read</value>
      </claim>
    </required-claims>
  </validate-jwt>
  <set-header name="x-caller-subject" exists-action="override">
    <value>@(((Jwt)context.Variables["jwt"]).Subject)</value>
  </set-header>
</inbound>

Object and function decisions stay in the backend

The gateway does not know who owns order 42. OWASP's API1:2023 says every endpoint that receives an object identifier and acts on it needs an object-level check that the logged-in user may perform that action on that object. It adds that comparing the user ID extracted from the JWT with the ID in the request addresses only a small subset of cases. Ownership in real systems runs through shared accounts, delegated access and records a user may read but not change, and the token describes none of that. ^[4]

Function-level rules are partly a gateway job. API5:2023 asks whether a regular user can reach administrative functions, including by changing GET to DELETE, recommends deny-by-default enforcement and notes that such protection is frequently provided by components outside the application code. Route scopes on an HTTP API and operation-scoped APIM policies are reasonable places for coarse rules of that kind. A rule that depends on the user's role within a tenant, or on the state of the record, belongs with the data. ^[1][2][5]

Key identities so the backend cannot confuse two people. Microsoft's access token guidance says a subject is interpreted within its issuer or tenant and that the tenant ID must be part of the key used to reach the user's data. Google API Gateway accepts several security definitions as long as each has a different issuer, which implies the same sub value can arrive from two issuers in one API. Store local principals under issuer, tenant and subject together, and accept only tokens whose audience is your own API; Microsoft describes accepting tokens meant for another resource as a confused deputy problem. ^[3][22]

Test the split from both sides

Run these cases against a non-production stage with test identities, and record which component rejected each request so a pass at the backend is not mistaken for a pass at the gateway. Include every route with no authorizer, such as health checks and provider webhooks: a health check should expose nothing, and a webhook depends on a signature that only the backend verifies.

• ID token: present an ID token from the same issuer to every route, and expect a 401 from the gateway or a logged rejection from the backend, never a 200. ^[1][9]
• Wrong audience: a valid token minted for a sibling API should fail at each gateway once the audience is set explicitly. ^[2][3]
• Withdrawn key: after removing a test signing key, time how long its tokens keep passing, and compare with 120 minutes on AWS, 60 on APIM and about 5 on Google and Apigee. ^[1][2][3][6]
• Cached decision: with a Lambda authorizer, call an allowed route and then a forbidden one with the same token inside the TTL, and expect the second to be denied. ^[14][16]
• Header injection: send the forwarded identity header yourself, through the gateway on an unauthenticated route and directly to the backend, and expect it to be replaced or the request refused. ^[17][20][21]
• Object and method swaps: with two test users, request each other's object IDs and switch GET to DELETE, and expect 403 or 404 from the backend. ^[4][5]

Place each check in this order

One decision rule covers most designs. If a check needs only the token and the route, configure it at the gateway explicitly rather than relying on defaults. If it needs the record, the tenant's current state or the user's live status, put it in the backend. If the backend can be reached any other way, it must repeat the gateway's work as well. Applied in order, that rule gives five steps.

• Close every path to the backend that bypasses the gateway, or have the backend validate the token itself.
• Set issuer and audience per API, and require scopes or another access-token-only property on every route.
• Key authorizer caches on the credential and the route, with a TTL no longer than a revoked grant may survive.
• Overlap signing keys for at least the longest cache in front of the API, two hours where an AWS HTTP API sits there.
• Write object and function checks in the backend, keyed on issuer, tenant and subject.