Auth

User Status

Active, invited, suspended, banned, deleted.

What each user status means for login and admin flows.

Status answers one question: can this user authenticate?

Status	Can log in?	Typical meaning	How it usually changes
`active`	Yes	Normal account	From invite accept; admin reactivate
`invited`	No	Invite sent; no password yet	→ `active` via accept-invite
`suspended`	No	Temporary block	Admin `PATCH …/status`; optional `suspended_until`
`banned`	No	Permanent block	Admin; rarely reversed
`deleted`	No	Soft-deleted	Admin delete; restore via `POST …/restore`

Email verification, lockouts, and product policy live in other fields — do not overload status for those.

from outlabs_auth.models.sql.enums import UserStatus
# active | invited | suspended | banned | deleted

Behavior notes

Login checks status before password verification and raises an inactive / banned style error per status (invited users are pointed at the invite email).
Only active users authenticate (JWT, API keys, refresh), subject also to lockout (failed_login_attempts / locked_until) when that path is enabled.
On suspend / ban / delete, revoke refresh tokens (and API keys) in the same admin action if you need immediate cut-off; short-lived access JWTs may still work until expiry unless you enable Redis blacklist.
Admin status PATCH on the users router allows active | suspended | banned only — not deleted (use delete / restore endpoints). See 23.

Concern	Fields / mechanism
Invite in flight	`invite_token`, `invite_token_expires`, `invited_by_id`
Soft delete	`deleted_at`
Timed suspend	`suspended_until` (host/auto-reactivation logic)
Brute-force lock	`failed_login_attempts`, `locked_until`
Email proof	`email_verified` (separate from status)

ABAC

Attribute conditions on roles and permissions.

Core Authorization Concepts

Users, roles, permissions, entities, and tree access.