azp enforcement (#8877) ships in a patch release and will sign out users whose cookie tokens legitimately lack azp

[glenn-jocher]

Filing from Ultralytics — we run cross-subdomain Clerk SSO in production and are the reporters of #8231.

Summary

#8877 ("Enforce azp when configured", merged 2026-07-07, released in @clerk/backend@3.11.1) rejects cookie session tokens with a missing or empty azp claim whenever authorizedParties is configured.

Per Clerk's own analysis in #7332, the Frontend API mints cookie __session tokens without azp when the minting request carries no Origin header — which is every top-level document navigation, per spec. Those tokens are then reused until refresh.

So the population that #8877 now rejects is not hypothetical or attacker-controlled. It is ordinary users, produced by Clerk's own token minting. #8877's description says:

To be a problem this needs a system emitting azp-less tokens in an environment where an app expects azp to be set.

That is precisely the configuration #7929 was added to warn about, and it is ours: authorizedParties correctly configured across all apps, receiving tens of thousands of azp-less cookie tokens per day (~21,900/day when last measured — see #8231).

Why this seems wrong

1. It shipped as a patch. 3.11.0 → 3.11.1, and the PR checklist marks it 🐛 Bug fix, not 🔨 Breaking change. Any consumer on ^3.x picks this up from a routine dependency update. For us that means an unattended bun update can sign users out of production.

2. It contradicts the stated intent. In Clerk: Session token from cookie is missing the azp claim. In a future version of Clerk, this token will be considered invalid. Please contact Clerk support if you see this warning. #8231, @jacekradko wrote:

   We didn't want to make this a hard-fail case in Core 3, hence the warning was introduced to find any legitimate code paths that could end up in this situation.

   Cookie tokens minted on document navigations are a legitimate code path — Clerk creates them. fix(backend): Enforce azp when configured #8877 turns that into a hard fail.

3. feat(backend): Error if azp is missing on a cookie-based token #7332 anticipated this and paired enforcement with recovery. That PR errored on missing azp and triggered a handshake so the request could recover with a fresh token. It was closed unmerged. fix(backend): Enforce azp when configured #8877 appears to enforce without any equivalent recovery, so there is no path back to a valid token — the user is simply rejected.

Impact

For any app with authorizedParties set, upgrading @clerk/backend to ≥ 3.11.1 converts a benign warning into intermittent authentication failures, affecting exactly those sessions whose token happened to be minted during a top-level navigation. Intermittent sign-outs are harder to diagnose than a clean break.

Questions

1. Was the interaction with azp-less cookie tokens from Clerk: Session token from cookie is missing the azp claim. In a future version of Clerk, this token will be considered invalid. Please contact Clerk support if you see this warning. #8231/feat(backend): Error if azp is missing on a cookie-based token #7332 considered when fix(backend): Enforce azp when configured #8877 was scoped? The two threads appear not to have been connected.
2. Should fix(backend): Enforce azp when configured #8877 be paired with handshake recovery (as feat(backend): Error if azp is missing on a cookie-based token #7332 did) before enforcement, so a token lacking azp is refreshed rather than rejected?
3. If enforcement is intended to stand, can it be released behind a major version or an explicit opt-in, given it changes authentication outcomes from a patch release?
4. Is the underlying minting behaviour — no azp when Origin is absent — itself going to be fixed? That would resolve Clerk: Session token from cookie is missing the azp claim. In a future version of Clerk, this token will be considered invalid. Please contact Clerk support if you see this warning. #8231 and make enforcement safe.

Happy to provide a HAR via support@clerk.com referencing #8231, as requested there.

Related: #8231 · #7929 (warning) · #8698 (warn-once) · #7332 (closed enforcement + handshake) · SEC-313