Disabling a user or downgrading their role terminates their live sessions, not just future logins

This evidences SOC 2 CC6.2, which requires that access is removed when no longer authorized: an auditor reads "removes access" to include in-flight sessions, not just the next login attempt. AI-generated apps fail this in a very specific way: the scaffold ships stateless JWTs with long lifetimes (next-auth defaults to 30 days) and an admin "ban user" route that flips a banned or is_active column, and nothing ever consults that column again until the token expires. The result is a deprovisioning gap where a fired employee, a compromised account, or a demoted admin keeps full live access for days or weeks after the org believes it was cut off. That gap is exactly what a SOC 2 auditor probes during the logical-access walkthrough ("show me what happens to an active session when you disable this user"), and it is the difference between a clean CC6.2 test and an exception in the report.

In every handler that disables a user or downgrades a role, revoke their live access in the same code path: call supabase.auth.admin.signOut(userId) (or clerkClient.sessions.revokeSession(...) per active session, or prisma.session.deleteMany({ where: { userId } }) for database sessions) immediately after the status write. If you are on stateless JWTs, either shorten the access-token lifetime to one hour or less and revoke refresh tokens on disable, or add a per-request check in middleware.ts that re-reads is_active and role from the database so stale sessions die on the next request.

• ID: sessions-revoked-on-access-change
• Severity: high
• What to look for: First find the user-disable / role-mutation surfaces: admin routes under app/api/admin/**, pages/api/admin/**, or Express routers mounted at /admin; server actions or handlers matching /(ban|suspend|disable|deactivate|demote|revoke|set[_-]?Role|update[_-]?Role)/i; DB writes touching role, is_active, banned, disabled, suspended_at, or status on a users/profiles/members table (prisma.user.update, supabase.from('users').update, raw UPDATE users SET role); admin SDK calls (supabase.auth.admin.updateUserById, clerkClient.users.updateUser, Auth0 ManagementClient user updates, firebase-admin updateUser({ disabled: true })). Python/Go equivalents: Django user.is_active = False or DRF admin viewsets; Go handlers doing UPDATE users SET role/active. If no such surface exists anywhere, skip. Enumerate every disable/role-mutation surface you find and quote the status/role write line for each; then for each surface trace whether its path revokes live access via any of: (a) server-side session invalidation in the same path (prisma.session.deleteMany, DELETE FROM sessions WHERE user_id, redis.del('sess:...'), Lucia invalidateUserSessions, Django Session.objects.filter(...).delete()); (b) an admin revocation call (supabase.auth.admin.signOut(userId), clerkClient.sessions.revokeSession, Auth0 Management API session/refresh-token revocation, firebase-admin revokeRefreshTokens); (c) access-token lifetime <= 1 hour (session.maxAge, expiresIn, jwt.sign(..., { expiresIn }), Supabase jwt_expiry in supabase/config.toml) combined with refresh-token revocation on disable; (d) per-request middleware (middleware.ts, Express/Fastify auth middleware, Django middleware) that re-reads is_active/role from the database rather than trusting JWT claims.
• Pass criteria: At least one disable/role-mutation surface exists, and every such path (directly or via a shared helper it demonstrably calls) contains mechanism (a), (b), (c), or (d), with the revocation call or DB re-read actually invoked in code, quoted as evidence. Report the count even on pass: N mutation surfaces found, N of N wired to a revocation mechanism.
• Fail criteria: A disable/role-mutation surface exists, none of its paths touches sessions or tokens, and sessions are long-lived (JWT/session maxAge over 24 hours, or unset with a long-lived default such as next-auth's 30 days). Also fail the sneaky variants: a revocation helper (e.g. invalidateUserSessions) defined but never called from any mutation path; a signOut/revoke call commented out or behind a permanently false flag; middleware that reads role/banned only from JWT claims (stale by definition) instead of the database; a disable handler that is a stub returning success without writing or revoking anything. Do NOT pass when only some mutation surfaces revoke while others do not, when the sole mechanism is short-lived access tokens with no refresh-token revocation on disable, or when revocation exists only in a comment, README, or dead code path.
• Skip (N/A) when: The codebase has no user-disable or role-mutation surface at all (no admin user management). Quote: "No admin user-management surface: no routes, server actions, or admin SDK calls mutating role/is_active/banned on any user table".
• Before evaluating, quote: The mutation-surface file path plus 1-3 lines of the status/role write, AND either the revocation mechanism excerpt (session delete, admin signOut, token-lifetime config, or middleware DB re-read) or the session-lifetime config proving tokens are long-lived with no revocation. If skipping, quote the search scope that proves no mutation surface exists.
• Report even on pass: "Disable/role surface at <path>; revocation mechanism: session-store delete | admin signOut | short-lived tokens + refresh revocation | per-request DB status check at <path>".
• Detail on fail: "app/api/admin/users/[id]/route.ts sets is_active=false via prisma.user.update but never touches the sessions table; next-auth uses JWT strategy with default 30-day maxAge, so a banned user keeps live access until token expiry" or "invalidateUserSessions() is defined in src/lib/auth.ts but has no callers; the ban server action in app/admin/actions.ts only flips users.banned and middleware.ts trusts the role claim in the JWT".
• Remediation: In the disable/downgrade handler, revoke live access in the same code path as the status write: supabase.auth.admin.signOut(userId), clerkClient.sessions.revokeSession(...), or prisma.session.deleteMany({ where: { userId } }). On stateless JWTs, shorten access-token lifetime to <= 1 hour and revoke refresh tokens on disable, or add a middleware.ts check that re-reads is_active and role from the database per request. Deeper session-hardening coverage: the saas-authentication Pro audit.