feat(users): Enforce account suspension across all auth paths

[dashed]

Enforce the new is_suspended field (added in #114328) across all authentication and authorization paths so that suspended users are fully locked out while their account and data are preserved.

Auth Enforcement

• login() (utils/auth.py): Returns False for suspended users — blocks all session-based login.
• EmailAuthBackend.authenticate() (utils/auth.py): Intentionally returns the user even if suspended, so callers (AuthenticationForm, auth_login endpoint) can show a specific "suspended" error instead of generic "invalid credentials."
• EmailAuthBackend.user_can_authenticate() (utils/auth.py): Unchanged — returns True unconditionally (existing behavior since PR feat(django 1.10): continue to let inactive/soft-deleted users authenticate #15974 to support /reactivate/ for inactive users).
• EmailAuthBackend.get_user() (utils/auth.py): Returns None for suspended users, invalidating existing sessions on next request.
• AuthenticationForm.clean() (web/forms/accounts.py): Checks is_suspended after authenticate() returns — raises a "Your account has been suspended" error. This is the primary gate for both web form and API login flows.
• SocialAuthBackend.get_user() (social_auth/backends/__init__.py): Returns None for suspended users (in addition to the existing is_active check), invalidating social-auth-backed sessions.
• RecoverPasswordForm.clean_user() (users/web/accounts_form.py): Filters out suspended users silently (returns None, same as non-existent users) to prevent password recovery emails from being sent.
• recover_confirm() (users/web/accounts.py): Early return for suspended users before any password reset form processing, blocking a code path that uses Django's login_user() instead of auth.login().
• User auth tokens (api/authentication.py): Raises AuthenticationFailed("User account is suspended") for non-system tokens.
• ViewerContext auth (api/authentication.py): Rejects suspended users with distinct "user_suspended" log reason (vs "user_inactive").
• Signed links (utils/linksign.py): Returns None for suspended users, invalidating email confirmation links etc.
• SSO pipeline (auth/helper.py): Checks is_suspended in _finish_login_pipeline() before entering the handler dispatch, preventing an infinite redirect loop where login() returns False and org-subdomain auto-SSO retriggers.
• 2FA flow (web/frontend/twofactor.py): Replaces assert auth.login() with a conditional check — if a user is suspended mid-2FA flow, they get redirected to login instead of a 500 error.
• Login API endpoint (api/endpoints/auth_login.py): Defense-in-depth is_suspended check before auth.login(). AuthenticationForm.clean() already catches suspended users (see above), but this explicit check prevents a silent success if the form validation path is ever bypassed.

Superuser API

Superusers can suspend/unsuspend users via PUT /api/0/users/{id}/ with is_suspended. The serializer:

• Validates that superusers cannot suspend their own account.
• Validates that Sentry App proxy users cannot be suspended (suspending a proxy user would silently break the entire integration's API token auth).
• Refreshes the session nonce only on actual state transition (not on idempotent PUTs where the user is already suspended), preventing unnecessary session invalidation.
• Performs the nonce refresh before super().update() so suspension and nonce invalidation happen in a single DB write.
• Includes is_suspended in audit logging for privileged field changes.

User Serializer

isSuspended is added to the base UserSerializerResponse so all user serializations include it.

Reactivation View

Suspended users who reach /reactivate/ see a dedicated account-suspended.html template instead of the self-reactivation form, since only an admin can lift a suspension.

API Docs

isSuspended is added to user objects in API docs examples. Non-user objects (project keys, ownership rules, team roles, replay event users) that were incorrectly given the field are cleaned up.

Test Coverage

• test_user_details.py: Suspend, unsuspend, self-suspension guard, sentry_app proxy guard, session nonce on transition only, idempotent PUT
• test_authentication.py: Token auth and Viewer Context auth reject suspended users
• test_auth.py: login() rejects suspended users, authenticate() intentionally returns them, get_user() returns None for suspended users
• test_helper.py: SSO pipeline blocks suspended users with ERR_USER_SUSPENDED
• test_linksign.py: Signed links reject suspended users
• test_reactivate_account.py: Suspended users see suspension template
• test_twofactor.py: Suspended user in 2FA flow gets redirect to login
• test_auth_login.py (api): Suspended user API login attempt returns 400
• test_auth_login.py (web): Suspended user web form login shows suspension error
• test_accounts.py: Suspended users cannot initiate password recovery, recovery emails not sent
• test_auth_index.py: Suspended user cannot verify password (sudo)
• test_utils.py (social_auth): Social auth get_user() returns None for suspended users

Stacked on #114328.

[geoffg-sentry]

I think I spotted a possible bypass code flow. In src/sentry/users/web/accounts.py there's a direct login_user(request, user) call that's made that users Djangos auth.login instead of our sentry.utils.auth.login. The authenticate check before it doesn't look at is_suspended today.

[geoffg-sentry]

Login API endpoint (api/endpoints/auth_login.py): Defense-in-depth is_suspended check before auth.login(). Form validation already catches suspended users with a generic error (per OWASP — don't reveal account state on login forms), but this explicit check prevents a silent success if the form validation path is ever bypassed.

This doesn't match the change. AuthenticationForm.clean() only fails when authenticate() returns None and suspended users won't reutrn that.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ad32f06. Configure here.}

[dashed]

I think I spotted a possible bypass code flow. In src/sentry/users/web/accounts.py there's a direct login_user(request, user) call that's made that users Djangos auth.login instead of our sentry.utils.auth.login. The authenticate check before it doesn't look at is_suspended today.

@geoffg-sentry yep this is valid. this should be addressed in 88ebf04 (this PR). Fixed the primary bypass in recover_confirm() in src/sentry/users/web/accounts.py; it checks for suspension status before the login_user() call.

we also do not send the recovery email in RecoverPasswordForm.clean_user() for suspended users.

[dashed]

Login API endpoint (api/endpoints/auth_login.py): Defense-in-depth is_suspended check before auth.login(). Form validation already catches suspended users with a generic error (per OWASP — don't reveal account state on login forms), but this explicit check prevents a silent success if the form validation path is ever bypassed.

This doesn't match the change. AuthenticationForm.clean() only fails when authenticate() returns None and suspended users won't reutrn that.

AuthenticationForm.clean() now has an explicit suspension status check. this should be addressed in ad32f06

[michelletran-sentry]

Generally LGTM.

Got thumbs up from Michelle.