Validate the Access audience and rotating signing keys at a Cloudflare-protected origin

A forwarded identity header becomes trustworthy only after the intended token is verified.

Source facts

Cloudflare sends an Access application token to the origin in the Cf-Access-Jwt-Assertion header. The documentation recommends validating this header because the browser authorization cookie is not guaranteed to be present. Signing keys belong to the account and rotate; verification should select the appropriate key using the token’s key identifier instead of hard-coding one public key. The application’s AUD value identifies which application a token is valid for. Cloudflare’s programmatic examples verify the expected issuer and application audience as well as the signature.

Source: Cloudflare — Validate JWTs.

Applicability

This covers origins and Workers receiving Cloudflare Access tokens. It does not replace application-level authorization or independently establish that every route to the origin passes through Access.

DSE recommendation

DSE recommends placing token validation in the request path before privileged application work occurs. Configure the expected team issuer and application audience explicitly, and use a maintained verification library with support for remote key sets. Review the origin’s direct reachability and reject missing or invalid tokens on protected routes. Design key retrieval and caching to handle rotation without accepting arbitrary issuers. Log a safe reason code for rejection while excluding raw tokens and sensitive claim values from ordinary diagnostic output.

Verification

In a test deployment, try a valid intended token, a missing token, and a valid token issued for another application. Confirm rejection of the wrong audience. Exercise key-refresh behavior using the vendor’s documented test options and verify that signature validation remains enforced throughout.

Official reference

Cloudflare — Validate JWTs. Reviewed October 15, 2026.