Cloudflare Access

Cloudflare Access can restrict who reaches Studio before its own sign-in. Studio can also verify that normal application requests passed through the intended Access application. This is optional and disabled by default.

Access and Studio authentication are separate. Passing Access does not create a Studio session, map an identity to a Studio role, or replace Studio’s authentication requirements.

Enable Studio Verification

1. Configure an Access application and policy in Cloudflare for the Studio HTTPS origin.
2. Visit that protected origin and sign in to Studio as an administrator.
3. Open Operations from an allowed IP and unlock it with the Operations token.
4. Open Studio access and enable the requirement after verification succeeds.

Studio verifies the current Cf-Access-Jwt-Assertion signature against the issuer’s JWKS endpoint before saving the exact issuer, audience, and HTTPS origin. These values are derived from the verified request rather than entered manually. This feature needs no additional Worker variable, API token, or service token and does not change Cloudflare configuration.

What Studio Checks

When verification is required, Studio checks the JWT signature, algorithm, application type, time claims, issuer, and audience. The issuer and audience must match the saved requirement, and the request origin must match the origin captured during setup.

Result	Studio response
Missing, expired, invalid, or mismatched assertion	403 CLOUDFLARE_ACCESS_REQUIRED
Stored configuration or signing-key verification unavailable	503 CLOUDFLARE_ACCESS_VERIFICATION_UNAVAILABLE

A verification outage does not fall back to Studio authentication alone. Moving the Worker to a different hostname can therefore require recovery and re-enrollment of the Access requirement.

Coverage

The Studio-side gate covers normal APIs and protected Studio-managed media. System status, installation, and Operations routes have separate entry rules. Initial and recovery modes also bypass the stored Studio-side requirement so installation and repair remain possible.

The operational Access settings endpoint independently requires an allowed IP, Operations token, and administrator session. If Access is already required, it also checks the current Access assertion. Its Operations path is not an unprotected disable endpoint.

Cloudflare still applies its own outer policy to these routes. Studio cannot override a denial that happens before the request reaches the Worker. Cloudflare also owns Access protection for the HTML and static assets; Studio’s additional checks protect its stateful application boundaries.

Expiry in the Browser

Studio distinguishes an expired outer Access session from an expired Studio session. If Access interrupts an active workspace, a blocking prompt offers to continue through a page reload so Access can authenticate again. Studio does not mint, renew, or store an Access cookie itself.

Recovery and Origin Changes

If the saved requirement no longer matches the intended deployment:

1. Preserve a Studio database backup and set STUDIO_SITE_MODE=recovery.
2. Open Operations using its IP and token boundary.
3. Choose Disable Cloudflare Access requirement and confirm DISABLE CLOUDFLARE ACCESS.
4. Check the intended outer Access policy, then return Studio to operational mode.
5. Visit the final protected HTTPS origin and enable the requirement again.

The recovery operation changes only Studio’s saved requirement. If Cloudflare itself blocks Operations, correct that outer policy first.

SQL backups include this setting. Restoring a backup to another hostname can restore an old bound origin; use the same recovery path. Assertions, cookies, JWTs, and the saved identity fields are not written to operational logs.

Cloudflare documents Access token validation.