fix(security): invalidate JWT sessions after password change

[claygeo]

Problem

Fixes #28392

Existing JWT sessions persist after password change, allowing stolen tokens to retain access for up to 30 days.

Fix

• Add passwordChangedAt to User model
• Set it when password is changed
• Check token.iat <= changedAtSeconds in JWT callback to invalidate old sessions

3 files, 17 lines. Replaces #28642 which had unrelated changes.

[cubic-dev-ai]

2 issues found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/features/auth/lib/next-auth-options.ts">

<violation number="1" location="packages/features/auth/lib/next-auth-options.ts:664">
P1: Returning an empty JWT breaks downstream assumptions (`token.email!`) in the jwt callback and can cause invalid user lookup/session behavior after password-change invalidation.</violation>
</file>

<file name="packages/trpc/server/routers/viewer/auth/changePassword.handler.ts">

<violation number="1" location="packages/trpc/server/routers/viewer/auth/changePassword.handler.ts:76">
P2: Password hash update and passwordChangedAt update are not atomic; a failure after the upsert can leave passwordChangedAt unset, allowing old JWTs to remain valid despite the password change.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[claygeo]

Thanks for the review @cubic-dev-ai — both issues are addressed in the latest push.

P1 — Empty JWT breaking downstream assumptions (fixed)

The previous approach of returning { ...token, email: "", name: "", id: 0 } was fragile: subsequent autoMergeIdentities calls would hit the DB with email: "", get null back, return the broken token unchanged, and still expose token.email! assertions.

Replaced with an explicit error: "SessionInvalidated" flag following NextAuth's documented error pattern:

• autoMergeIdentities now has an early-exit: if (token.error === "SessionInvalidated") return token; — no DB lookup, no broken assertions
• The invalidation return is now return { ...token, error: "SessionInvalidated" } — preserves token shape
• The session callback propagates the flag: if (token.error === "SessionInvalidated") return { ...session, error: "SessionInvalidated" } — client can detect and redirect to sign-in
• Both Session and JWT interfaces in packages/types/next-auth.d.ts now declare error?: "SessionInvalidated" for type safety

P2 — Non-atomic password + passwordChangedAt update (already addressed)

The changePassword handler at changePassword.handler.ts:76 already wraps both operations in prisma.$transaction([...]):

await prisma.$transaction([
  prisma.user.update({ where: { id: user.id }, data: { password: { upsert: ... } } }),
  prisma.user.update({ where: { id: user.id }, data: { passwordChangedAt: new Date() } }),
]);

If the second update fails, Prisma rolls back the first — passwordChangedAt and the password hash are always in sync. The atomicity concern cubic flagged was valid for an earlier version of this PR; the transaction was added in a prior commit.

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/features/auth/lib/next-auth-options.ts">

<violation number="1" location="packages/features/auth/lib/next-auth-options.ts:671">
P2: Invalidated JWTs now keep identity fields and server-side session creation ignores token.error, so password-change invalidation can still yield authenticated sessions on server routes.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Invalidated JWTs now keep identity fields and server-side session creation ignores token.error, so password-change invalidation can still yield authenticated sessions on server routes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/features/auth/lib/next-auth-options.ts, line 671:

<comment>Invalidated JWTs now keep identity fields and server-side session creation ignores token.error, so password-change invalidation can still yield authenticated sessions on server routes.</comment>

<file context>
@@ -661,10 +665,10 @@ export const getOptions = ({
+            // Mark the token as invalidated. The early-exit at the top of autoMergeIdentities
+            // prevents any further DB lookups on subsequent JWT refreshes, and the session
+            // callback propagates the error to the client so it can redirect to sign-in.
+            return { ...token, error: "SessionInvalidated" } as JWT;
           }
         }
</file context>