Access deny redirects now carry an account_id!

Hi everyone, it's Shii-chan! I found a small but handy Zero Trust update.

Cloudflare Changelog developers.cloudflare.com

What was announced?

The Cloudflare Changelog says Access (Cloudflare One) deny redirects have been updated. App-aware deny redirects now include an account_id query parameter when account context is available.

The story so far

Custom block pages already received values like kid, which represents the application, in the redirect URL. But you couldn't tell from the URL which account owned that application.

What changes

Your custom block page can now identify the account that owns the application represented by kid. That makes it easier to look up applications through account-scoped APIs.

Dive Deep

Here is an example custom redirect:

https://denied.example.com/?kid={APP_AUD}&account_id={ACCOUNT_ID}&original_url=app.example.com%2Fadmin

• kid identifies the application
• account_id is the ID of the account that owns it (only present when account context is available)
• original_url is the original destination

One important note: the changelog says account_id is context, not proof of authentication or authorization. Don't base permission decisions on this value alone. See "Custom redirect URL parameters" in the docs for details.

Wrap-up

• App-aware deny redirects now include account_id when available
• Custom block pages can identify the owning account
• Useful for lookups through account-scoped APIs
• Not proof of authentication or authorization

This one is for anyone building custom Access block pages!