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

[PsukheDelos]

This is 100% of native Expo/React Native apps, not an intermittent subset.

Same root cause as above, but worse for native clients. @clerk/clerk-expo (React Native) hits this on every token.

{"message":"Invalid JWT Authorized party claim (azp) undefined. Expected \"...\". (reason=token-invalid-authorized-parties, token-carrier=header)"}

token-carrier=header here, so this is a Bearer token, no cookie involved.

The cookie case above is intermittent: only tokens minted during a top-level navigation lack Origin/azp. Native apps don't have that split. Mobile networking stacks never send Origin, so no native-minted token can ever carry azp. With authorizedParties configured, that's not a subset of traffic failing, it's every native client, permanently, as of @clerk/backend@3.11.1.

azp enforcement is a browser CSRF mitigation. Native clients aren't a CSRF-relevant context, so this check can't pass for them no matter what. Given the all-or-nothing scope (authorizedParties set means enforced for every client, including ones that structurally can't satisfy it), could this get a native/non-browser exemption instead of a hard reject? Happy to share repro details if useful.

Worth noting this isn't limited to consumers on @clerk/backend directly: @clerk/express (and presumably other wrapper packages) pull in the enforcement transitively through their own @clerk/backend dependency, so anyone on an affected @clerk/express version is exposed too.

[github-actions]

Hello 👋

We currently close issues after 40 days of inactivity. It's been 30 days since the last update here. If we missed this issue, please reply here. Otherwise, we'll close this issue in 10 days.

As a friendly reminder: The best way to see an issue fixed is to open a pull request. If you're not sure how to do that, please check out our contributing guide.

Thanks for being a part of the Clerk community! 🙏