Refresh token rotation is implemented

A refresh token that never rotates is a long-lived credential equivalent: steal it once, impersonate the user indefinitely. Token refresh without rotation means CWE-613 (Insufficient Session Expiration) applies in practice even when session expiry is configured correctly — the refresh token keeps re-issuing access tokens forever. NIST 800-63B §7.1 (Session Bindings) requires that bound authenticators be invalidated when the session ends, and RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) requires refresh tokens for public clients to be sender-constrained or use rotation with reuse detection. OWASP A07 (Identification and Authentication Failures) lists perpetual credentials as a named failure mode.

Invalidate the old refresh token in the same database transaction that issues the new one — a non-atomic rotation creates a race condition where both tokens are briefly valid:

async function rotateRefreshToken(oldToken: string) {
  const newToken = crypto.randomUUID()
  await db.$transaction([
    db.session.update({
      where: { refreshToken: oldToken },
      data: { refreshToken: newToken, rotatedAt: new Date() }
    })
  ])
  return newToken
}

Supabase Auth rotates automatically when using @supabase/ssr. NextAuth with database sessions rotates automatically. For custom implementations, any non-atomic rotation is a security gap.