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.

[glenn-jocher]

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs

• I have searched for existing issues: https://github.com/clerk/javascript/issues

• I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

• This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction

https://platform.ultralytics.com

Publishable key

pk_test_ZGl2aW5lLWZveGhvdW5kLTIyLmNsZXJrLmFjY291bnRzLmRldiQ

Description

Bug: Cookie-based session tokens missing azp claim after upgrading to @clerk/nextjs v7

Environment

• @clerk/nextjs: 7.0.8
• @clerk/backend: 3.2.4
• Framework: Next.js 16.2 (App Router)
• Deployment: Vercel (Production)
• Node.js runtime: Vercel serverless

Description

After upgrading from @clerk/nextjs v6 (^6.38.0) to v7 (^7.0.8), every authenticated API request produces the following warning in Vercel serverless function logs:

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.

This is fires on authenticated requests (~2,000+ warnings/day in production). The warning originates from @clerk/backend@3.2.4 (dist/internal.js:6428), added in clerk/javascript#7929:

const { data, errors } = await verifyToken(authenticateContext.sessionTokenInCookie, authenticateContext);
if (errors) {
 throw errors[0];
}
if (!data.azp) {
 console.warn(
 "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."
 );
}

Setup

We run a multi-app monorepo on *.ultralytics.com with cross-subdomain SSO:

• account.ultralytics.com — primary auth domain
• platform.ultralytics.com — SaaS app (where all warnings appear)
• portal.ultralytics.com, docs.ultralytics.com, academy.ultralytics.com, handbook.ultralytics.com

Sessions are shared across subdomains via the __client cookie. Each app's middleware correctly passes authorizedParties to clerkMiddleware():

const clerkHandler = clerkMiddleware(
 async (auth, req) => {
 // route protection logic
 },
 (req) => ({
 authorizedParties: getClerkAllowedOrigins(
 req.nextUrl.origin,
 process.env.VERCEL_URL ? `https://${process.env.VERCEL_URL}` : undefined,
 ),
 }),
);

Where getClerkAllowedOrigins() returns all production origins (https://account.ultralytics.com, https://platform.ultralytics.com, etc.) plus localhost for development.

What we've verified

1. authorizedParties is correctly configured in all 6 apps' proxy.ts middleware — this is not a missing configuration issue
2. We are on the latest stable versions — no newer fix available
3. The azp claim is a Clerk default claim set by the Frontend API based on the browser Origin header — it is not configurable via JWT templates or code
4. Auth still works — tokens are accepted, users stay signed in. The warning is non-breaking today, but #7332 indicates Clerk plans to make this a hard error in a future version

Expected behavior

Cookie-based session tokens issued by Clerk's Frontend API should include the azp claim, populated from the browser's Origin header. No warning should appear when authorizedParties is correctly configured and sessions are accessed from known origins.

Actual behavior

Cookie-based session tokens on platform.ultralytics.com are missing the azp claim, producing a console.warn on authenticated requests. This floods production logs and makes them unusable for real debugging.

Questions

1. Why are tokens issued by the Frontend API missing the azp claim in this cross-subdomain SSO configuration?
2. Is there a configuration change needed on our end (Clerk Dashboard, environment variables, SDK options) to ensure azp is populated?
3. What is the timeline for azp becoming a hard requirement (per feat(backend): Error if azp is missing on a cookie-based token #7332)?

Environment

(.venv) glennjocher@Glenns-MacBook-Pro portal % pnpm dlx envinfo --system --browsers --binaries --npmPackages
 WARN The "workspaces" field in package.json is not supported by pnpm. Create a "pnpm-workspace.yaml" file instead.
Packages: +1
+
Progress: resolved 1, reused 0, downloaded 1, added 1, done

 System:
 OS: macOS 26.4
 CPU: (12) arm64 Apple M4 Pro
 Memory: 432.34 MB / 24.00 GB
 Shell: 5.9 - /bin/zsh
 Binaries:
 Node: 25.2.1 - /opt/homebrew/bin/node
 npm: 11.6.2 - /opt/homebrew/bin/npm
 bun: 1.3.11 - /Users/glennjocher/.bun/bin/bun
 Browsers:
 Chrome: 146.0.7680.178
 Firefox: 149.0
 Safari: 26.4
 npmPackages:
 @biomejs/biome: ^2.4.10 => 2.4.10 
 @next/third-parties: ^16.2.2 => 16.2.2 
 knip: ^6.3.0 => 6.3.0 
 next: ^16.2.2 => 16.2.2 
 svix: ^1.90.0 => 1.90.0 
 turbo: ^2.9.3 => 2.9.3

[glenn-jocher]

Following up — this is still firing in production at scale (now ~21,900 occurrences/day on platform.ultralytics.com), with no response here in ~7 weeks.

Since filing, I traced the mechanism through your own #7332: azp is derived from the Origin / sec-fetch-dest headers at token-mint time, so the cookie __session token minted during a top-level document navigation (which omits Origin per spec) has no azp. That token is then reused for every subsequent authenticated request until it refreshes, which is why a single user generates thousands of warnings.

Status as I see it from the outside:

• The warning (feat(backend): Warn if azp is missing on a cookie-based session token #7929) lives in @clerk/backend and the logic is unchanged through the current 3.4.13 (packages/backend/src/tokens/request.ts) — not gated on authorizedParties, and with no opt-out.
• The change that would actually resolve it — feat(backend): Error if azp is missing on a cookie-based token #7332 (require azp, and trigger a handshake to recover a fresh token on document requests) — is closed without merging, and I can't find a successor PR.

So it looks like the warning shipped but the corresponding fix did not. Questions:

1. Is there anything we can do on our end (Dashboard setting, env, SDK option) to get azp populated on cookie tokens in a cross-subdomain SSO setup? Our authorizedParties is correctly configured across all apps.
2. What replaced feat(backend): Error if azp is missing on a cookie-based token #7332, and what is the timeline before azp becomes a hard requirement on cookie tokens (which, per that PR, would start signing users out)?
3. In the meantime, is there a supported way to suppress this one warning without monkey-patching console.warn?

Happy to provide a HAR / instance details via support if that helps.

[jacekradko]

Hi @glenn-jocher, sorry for the slow response. We really appreciate your detailed write-up of the issue.

This is a noisy warning, so I opened a PR that should significantly reduce the amount of logging it does: #8698. It should stop flooding your app logs. 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.

A HAR of the request that triggers the warning would be extremely useful. Since it'll contain live session tokens, best to send it to support@clerk.com (or our Discord) rather than attach it here, and feel free to reference this issue.