Как добавить вход в приложение: пароли, волшебные ссылки, Google и роли

Чтобы добавить вход в приложение, выберите способ — email и пароль, волшебные ссылки (одноразовая ссылка для входа, которую присылают на почту) или «Войти через Google» — и реализуйте его с помощью проверенной библиотеки аутентификации или размещённого провайдера, а не писать с нуля. Затем решите, что может делать каждый тип пользователя (роли), и обеспечивайте это на сервере для каждой страницы и каждого API-запроса. Сессии должны использовать безопасные cookie, истекать и корректно завершаться при выходе.

Этот гид проходит по каждому выбору и по деталям, которые отличают рабочий вход от безопасного. Понятия, на которых всё это держится, — в гиде что такое аутентификация.

Сначала решите: нужен ли вообще вход?

Вход добавляет трение и ответственность. Он нужен, когда:

• У пользователей есть приватные данные (их брони, документы, счета)
• Пользователи могут менять то, что увидят другие
• Вы берёте плату за доступ
• Разным людям нужны разные права (владелец, сотрудник, клиент)

Он может не понадобиться для маркетингового сайта, публичного каталога или формы, которая просто отправляет вам письмо. Листу ожидания аккаунты не нужны; достаточно поля для email.

Четыре распространённых способа входа

Многие приложения комбинируют два способа: вход через Google плюс волшебные ссылки на email — популярная пара, которая покрывает большинство людей без хранения паролей.

Email и пароль

Если вы предлагаете пароли, это обязательные условия:

• Хешируйте пароли медленным алгоритмом хеширования. Рекомендации OWASP по хранению паролей советуют Argon2id, а альтернативами служат scrypt, bcrypt или PBKDF2. Никогда не храните пароли открытым текстом или быстрым общим хешем.
• Сброс пароля использует случайную одноразовую ссылку с ограниченным сроком, отправленную на подтверждённый email.
• Не раскрывайте, у каких email есть аккаунты. Лучше «Если этот email зарегистрирован, мы отправили ссылку для сброса», чем «Аккаунт не найден».
• Ограничивайте частоту попыток входа и сброса, чтобы замедлить подбор паролей.
• Разрешайте длинные пароли и менеджеры паролей; не вводите правила, которые заставляют использовать странные сочетания символов.

Волшебные ссылки и одноразовые коды

Волшебная ссылка — ссылка для входа, которую отправляют пользователю на почту. Клик по ней авторизует его. Одноразовый код — та же идея, только его вводят, а не кликают.

• Ссылки и коды быстро истекают и работают только один раз.
• Ссылка должна входить в систему на том устройстве, где по ней кликнули, а токен не должен оставаться в логах или в инструментах аналитики.
• Нужна надёжная отправка писем — см. как отправлять письма из приложения. Проверяйте в Gmail и Outlook и смотрите папку «Спам».

Вход через Google (и другие провайдеры OAuth)

«Войти через Google» использует OAuth и OpenID Connect: Google подтверждает, кто пользователь, и передаёт вашему приложению его email и имя. Настройка, по состоянию на сентябрь 2026 года, выполняется в разделе Google Auth Platform в Google Cloud Console:

1. Создайте или выберите проект и заполните страницу Branding — что видят пользователи на экране согласия (название приложения, email поддержки, логотип).
2. На странице Clients создайте клиента типа «Web application».
3. Добавьте authorized JavaScript origins и redirect URIs — точные адреса, по которым работает ваше приложение и куда Google возвращает пользователей после входа.
4. Храните client ID и client secret в секретах приложения.

Что обычно идёт не так, согласно документации OAuth от Google:

• redirect_uri_mismatch: адрес перенаправления должен совпадать точно, включая http и https, регистр символов и завершающий слэш. Добавьте один для адреса предпросмотра и один для вашего живого домена.
• Нужен HTTPS: redirect URI должны использовать HTTPS, кроме localhost во время разработки.
• Параметр state нужно проверять при возврате, чтобы защититься от межсайтовой подделки запросов. Хорошие библиотеки делают это за вас.

Если вы запрашиваете только базовую информацию для входа (имя, email, профиль), Google говорит, что верификация приложения не обязательна. Запрос доступа к Gmail, Drive или Календарю пользователей — другое дело, он требует верификации.

Писать самим или использовать провайдера?

Оба первых варианта разумны. Провайдеры берут на себя больше, но добавляют зависимость и иногда берут плату за активных пользователей; актуальные цены смотрите на их сайтах. Библиотеки хранят всё в вашей базе, но больше настроек нужно сделать правильно самим. Что бы вы ни выбрали, просите ИИ использовать это решение, а не писать собственную логику паролей или сессий.

Роли и права доступа

Вход говорит, кто человек. Права определяют, что он может делать. Сначала держите всё просто:

Правила, которые важнее названий ролей:

• Проверяйте на сервере, каждый раз. Скрытая в интерфейсе кнопка не мешает кому-то вызвать API напрямую.
• Ограничивайте по владельцу. Участник, запрашивающий «бронь 123», должен получить её только если она его.
• Пользователи не могут повысить себя сами. Игнорируйте поля ролей, присланные из браузера при обновлении профиля.
• По умолчанию доступа нет. Новые маршруты требуют входа, если вы не решили иначе.

Проверьте на двух аккаунтах: войдите под одним, запомните ID записи, затем войдите под другим и попробуйте её открыть. Полный тест — в нашем чек-листе безопасности.

Безопасность сессий

После входа приложение запоминает пользователя с помощью сессии — обычно это cookie. Рекомендации OWASP по управлению сессиями советуют:

• Cookie сессии с Secure (только HTTPS), HttpOnly (недоступно скриптам страницы) и SameSite
• Новый ID сессии выдаётся при входе и снова при изменении привилегий
• Тайм-аут простоя и абсолютный максимальный срок жизни, которые соблюдает сервер
• Выход завершает сессию на сервере, а не просто удаляет cookie
• Сессии аннулируются, когда пользователь меняет пароль

Хранение токенов входа в local storage браузера распространено в учебниках, но оставляет их доступными любому скрипту на странице; для веб-приложений безопасные cookie обычно лучший выбор.

Промпт, который покрывает основное

Добавь учётные записи пользователей в это приложение. Пользователи могут зарегистрироваться и войти по email и паролю или через Google. Используй [библиотеку или провайдера], а не собственный код аутентификации. Хешируй пароли с помощью Argon2id или bcrypt. Добавь сброс пароля по email с одноразовой ссылкой, которая истекает через час. Храни сессии в безопасных cookie HttpOnly. Защити /dashboard и каждый маршрут /api, чтобы ими пользовались только вошедшие пользователи, и убедись, что пользователи видят только свои проекты. Добавь роль «admin», которая может видеть всех пользователей; только администраторы могут открыть /admin, и это проверяется на сервере.

Затем проверьте: зарегистрируйтесь, выйдите, войдите, сбросьте пароль, откройте приватный URL, будучи вышедшим, и попробуйте запись другого пользователя.

Частые ошибки в логине, написанном с ИИ

• Защита только на странице. Страница перенаправляет вышедших пользователей, но API отдаёт данные любому.
• Секреты в браузере. Секреты клиента OAuth и административные ключи провайдера аутентификации должны находиться на сервере.
• Путаница между адресами предпросмотра и живым. Redirect URI Google или ссылка для сброса пароля указывают на предпросмотр, поэтому вход ломается после публикации.
• Нет подтверждения email. Любой может зарегистрироваться как anyone@company.com. Подтверждайте email, прежде чем выдавать что-либо, связанное с этим адресом.
• Тестирование только позитивного сценария. Попробуйте неверные пароли, истёкшие ссылки и второй аккаунт.

Вход в Mythex

В Mythex вход для пользователей вашего приложения — это то, что вы добавляете в своё приложение; он отделён от вашего собственного аккаунта Mythex. Mythex не предоставляет встроенного продукта аутентификации, поэтому вы подключаете библиотеку или провайдера и их ключи:

1. Выберите подход — например, email и пароль, которые хранятся в вашей базе, или SDK размещённого провайдера.
2. Если пользователей вы храните сами, приложению нужна база данных; попросите её в чате или используйте /database.
3. Храните ключи провайдера в секретах проекта (/secrets или настройки проекта).
4. Используйте промпт, похожий на приведённый выше, и проверьте в Preview. Для входа через Google добавьте redirect URI и для предпросмотра, и для опубликованного адреса.

См. Добавить вход в приложение в документации. Если вы создаёте платный продукт, как создать MVP SaaS описывает аккаунты и оплату вместе.

Вопросы