Пусть одна система владеет идентичностью
Форма входа собирает запрос. Система аутентификации решает, устанавливает ли этот запрос идентичность, и выдаёт сессию, которой доверяет остальное приложение. Удержание этой ответственности в одном месте не даёт каждому маршруту изобретать собственную интерпретацию вошедшего пользователя.
supastack использует Better Auth для идентичности и сессий. Код приложения разрешает сессию на защищённых границах и связывает её с воркспейсом. Интерфейс может показывать полезные состояния доступа, но клиентское состояние не должно становиться доказательством авторизации операции.
Правило должно держаться на каждой поверхности, которую поставляет продукт. Web-, mobile- и desktop-клиенты должны потреблять одно и то же решение об идентичности, а не реализовывать его трижды, — три интерпретации «вошёл» — это то, откуда берутся баги аккаунтов.
Выбирайте способы входа осознанно
Каждый способ — это обмен трения на поверхность атаки и внешнюю зависимость. Паролям нужны потоки сброса и ограничение частоты. Magic-ссылки и одноразовые коды зависят от доставляемости почты. OAuth делегирует идентичность провайдерам вроде Google, GitHub или Apple — и наследует их сбои, экраны согласия и правила колбэков.
supastack компонует их через Better Auth — OTP по e-mail, пароль, magic-ссылка, OAuth, с доступными двухфакторной аутентификацией и пассключами — за единым решением об идентичности. Поставляйте наименьший набор, который реально нужен вашей аудитории: каждый дополнительный способ — ещё один путь колбэка, ещё один режим сбоя и ещё один поток для проверки перед запуском. Руководство по аутентификации покрывает подключение.
Когда человек может войти более чем одним способом, решите, как способы соединяются. Аккаунт Google и magic-ссылка по e-mail, разрешающиеся в один адрес, должны попадать на одну идентичность, а не на две. Правила связывания аккаунтов — часть решения об идентичности, и их ошибка создаёт дублирующихся пользователей, которые всплывают месяцами позже как загадочно пропавшие данные.
Сессии — креденшел, который имеет значение
После входа сессия — не пароль — это то, что несёт каждый запрос. Её срок жизни, хранение и правила инвалидации определяют реальную позицию безопасности. Сессия, переживающая выход, или та, которую удалённый участник воркспейса может продолжать использовать, — провал аутентификации, который не исправит никакой отполированный экран входа.
Решите жизненный цикл заранее: как долго живут сессии, могут ли пользователи видеть и отзывать свои активные сессии и что делают с ними смена пароля, смена e-mail или удаление из воркспейса. Управление сессиями существует модулем в ките именно потому, что эти решения легко откладывать и дорого внедрять задним числом.
Свяжите сессию с запрошенной записью
Вход не даёт доступа к каждой записи. Разрешайте воркспейс пользователя на сервере и включайте эту область в чтения и мутации. Идентификатор задачи или ссылка восстановления — это ссылка на работу, а не разрешение её получить, — пост о границах воркспейса подробно покрывает эту сторону границы.
Разрешайте область в фиксированном порядке: аутентифицируйте сессию, загрузите членство, затем читайте или пишите с этим контекстом воркспейса — никогда наоборот. Middleware может перенаправить анонимного посетителя, но не может авторизовать операцию; проверка принадлежит серверному действию или обработчику маршрута, где запись реально затрагивается.
У аккаунтов есть жизненный цикл, а не только начало
Провижининг — первое испытание этой границы. Когда пользователь регистрируется, воркспейс и записи владения, следующие за этим, должны быть безопасны для создания более одного раза — хуки жизненного цикла могут воспроизводиться провайдерами, повторами или инструментами поддержки. Дублирующее событие должно быть холостой операцией, а не дублирующейся организацией.
Конец жизненного цикла заслуживает той же заботы. Смена e-mail, сброс пароля, удаление участника, удаление аккаунта и экспорт данных — каждый маленький поток со своими случаями злоупотребления: ссылка сброса, работающая дважды, экспорт, утекающий записи коллеги. supastack поставляет экспорт GDPR и управление сессиями по этой причине; на чём бы вы ни строили, закладывайте бюджет на скучные потоки.
Тестируйте жизненный цикл, включая его конец
Успешный тест входа полезен, но неполон. Отработайте неверные креденшелы, истёкшие или повторно использованные коды верификации, анонимные запросы и межворкспейсный доступ. Проверьте, что выход инвалидирует сессию и что возвращающийся клиент не может продолжать использовать ранее авторизованный экран для защищённой работы.
Различайте тесты обработчиков и приёмку развёртывания. Memory-адаптер может установить семантику реального обработчика аутентификации, не доказывая персистентность Postgres или колбэк провайдера. Проверьте настроенный origin, путь колбэка, восстановление сессии и выход с развёрнутыми зависимостями, прежде чем заявлять, что полный путь входа работает.
- Неверные креденшелы и истёкшие или повторно использованные коды верификации отклоняются.
- Анонимные и межворкспейсные запросы не получают никаких принадлежащих данных.
- Выход инвалидирует сессию — устаревший клиент не может продолжать действовать.
- Подготовленные записи остаются идемпотентными при повторном воспроизведении хуков жизненного цикла.
- Колбэки реальных провайдеров работают на настроенном origin — проверено, а не предполагается.
Частые вопросы об аутентификации
Вопросы ниже всплывают, когда форма входа готова и системе нужно продолжать работать.
- Достаточно ли middleware для защиты маршрутов? — Middleware — удобный редирект, а не слой авторизации. Каждое серверное действие и маршрут самостоятельно разрешает сессию и воркспейс; защита на уровне страниц скрывает экраны, не авторизуя операции.
- Строить аутентификацию самому или использовать библиотеку? — Семантика сессий редко является местом, где SaaS отличается. Поддерживаемая библиотека вроде Better Auth за чёткими границами модулей даёт проверенные примитивы, оставляя значимые решения — ограничение области, жизненный цикл — в вашем коде.
- Как сессии соотносятся с воркспейсами? — Сессия идентифицирует человека; воркспейс идентифицирует записи, к которым ему можно обращаться. Разрешайте членство на сервере для каждого запроса и никогда не доверяйте ID воркспейса, присланному клиентом.
- Что B2B-клиенты ожидают от аутентификации? — Командные воркспейсы с ролями, вход через OAuth, видимость и отзыв сессий и журнал аудита. Двухфакторная аутентификация и пассключи всё чаще ожидаются для административных ролей.
- Что ломает аутентификацию в продакшене? — Обычно края: URL колбэка, существующий только локально, хук, провизионирующий дважды, сессия, переживающая членство. Тестируйте концы потоков, а не только их начала.