Auth ломается не там, где пароль слабый, а где не закрыты границы доступа

Auth ломается не там, где пароль слабый, а где не закрыты границы доступа

Чаще всего проблемы в auth появляются не в форме логина, а вокруг неё:
• токены хранятся слишком долго и без понятной ротации
• refresh token доступен там, где его легко украсть
• сессия создаётся до проверки статуса пользователя
• reset-password и email-confirm идут через один и тот же слабый сценарий

Если у тебя Supabase или любой Postgres-backed backend, разделяй аутентификацию и авторизацию. Auth отвечает за «кто вошёл», а rls — за «что ему можно». Не смешивай эти слои: проверка в API без rls почти всегда превращается в дыру, особенно когда появляются сервисные ключи, фоновые задачи и ручные SQL-запросы.

Отдельно проверь edge cases:
— пользователь удалён, а токен ещё жив
— email поменяли, а старые сессии не отозваны
— magic link можно переиспользовать
— чужой invite попадает в уже существующий аккаунт
— роль в БД не совпадает с ролью в профиле

Хорошая auth-схема — это не «чтобы можно было войти», а чтобы нельзя было сделать лишнего даже при утечке токена. Держи короткий чек: короткая жизнь access token, контролируемый refresh, отзыв сессий, rls на всех таблицах, отдельные политики для service role и ручной аудит критичных действий.