Что такое аутентификация? Логины, сессии и OAuth простыми словами

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

Почему это важно, когда вы создаёте приложение с ИИ

Добавление входа — один из самых частых запросов к ИИ-конструктору, и один из самых простых способов сделать что-то неправильно. Страницу входа легко сгенерировать. Сложная часть — всё вокруг неё:

• Надёжно ли хранятся пароли?
• Проверяет ли каждая закрытая страница и каждая конечная точка API, кто запрашивает данные?
• Может ли вошедший клиент увидеть данные другого клиента, просто поменяв число в адресной строке?
• Что происходит, когда кто-то забывает пароль?

Приложение может выглядеть безопасным и при этом провалить каждый из этих пунктов. Понимание движущихся частей помогает задавать правильные вопросы и проверять нужное.

Бытовая аналогия

Представьте, что вы заселяетесь в отель.

На стойке регистрации вы показываете документ. Это и есть аутентификация: подтверждение, кто вы. Администратор выдаёт вам карту-ключ. Эта карта — ваша сессия: на время проживания документ больше не показывается, вы просто прикладываете карту.

Карта открывает ваш номер, спортзал и лифт на ваш этаж, но не номера других гостей и не служебное помещение. Это и есть авторизация: к чему ваша личность имеет доступ. Если карту потеряли, отель может деактивировать её на стойке (отзыв сессии). При выезде она перестаёт работать (выход из аккаунта или истечение срока).

«Войти с Google» похоже на то, как отель принимает письмо от доверенного партнёра со словами «это именно этот человек», вместо того чтобы самому проверять ваш документ.

Основные способы входа

Как нужно хранить пароли

Безопасное приложение никогда не хранит ваш настоящий пароль. Вместо этого оно хранит хеш: результат односторонней функции, которая превращает пароль в строку фиксированной длины. При входе приложение хеширует введённое и сравнивает результат с сохранённым хешем.

Две детали делают это безопасным:

• Соль — случайное значение, которое добавляется к каждому паролю перед хешированием, поэтому у двух людей с одинаковым паролем разные хеши, и заранее вычисленные таблицы подбора бесполезны.
• Медленный алгоритм, созданный для паролей — например Argon2, bcrypt или scrypt. Универсальные хеши вроде MD5 или SHA-256 слишком быстры сами по себе: злоумышленники могут перебрать миллиарды вариантов.

Хеширование — это не то же самое, что шифрование. Зашифрованные данные можно расшифровать ключом; хеш пароля намеренно не обратим.

Сессии и токены

После входа приложению нужно узнавать вас при каждом запросе. Есть два распространённых подхода.

Для cookie важны три настройки: HttpOnly (JavaScript на странице не может прочитать cookie), Secure (отправляется только по HTTPS) и SameSite (ограничивает отправку при запросах с других сайтов). Хранение токенов в localStorage браузера распространено, но это открывает их любому скрипту, который работает на странице.

OAuth и «Войти с Google»

OAuth 2.0 — это стандарт делегированной авторизации: он позволяет приложению получить ограниченный доступ к вашему аккаунту в другом сервисе, например читать ваш Google Календарь, и при этом никогда не видеть ваш пароль от Google. Вас отправляют на Google, вы подтверждаете конкретные разрешения (их называют scopes), а Google выдаёт приложению токен только на эти разрешения.

Сам по себе OAuth создан, чтобы выдавать доступ, а не чтобы сообщать, кто вы. OpenID Connect (OIDC) — это слой поверх OAuth 2.0, который добавляет идентификацию; именно его использует «Войти с Google» или «Войти с Apple». Для настройки вы регистрируете приложение у провайдера и получаете client ID и client secret; секрет остаётся на вашем сервере.

Пример: вход в клиентский портал

Допустим, вы создаёте портал, где клиенты дизайн-агентства видят свои проекты и счета.

• Аутентификация: клиенты входят по email через волшебную ссылку, поэтому паролей нет. Сотрудники агентства входят через аккаунты Google Workspace.
• Роли: у каждого пользователя есть роль — client или staff.
• Правила авторизации:

• Где это соблюдается: на сервере, при каждом запросе. Сервер находит вошедшего пользователя и возвращает только те проекты, где project.company_id совпадает с компанией пользователя. Скрыть кнопку «Отметить оплаченным» недостаточно — конечная точка сама должна отказывать.

Основные термины

Распространённые ошибки и заблуждения

• Проверка прав только на странице. Если браузер прячет кнопку, а API не проверяет права, любой может вызвать API напрямую.
• Доверие ID из адресной строки. /invoices/1042 должен проверять, что счёт 1042 принадлежит вошедшему пользователю.
• Самодельная криптография. Используйте известные библиотеки или провайдеров; не давайте ИИ придумывать собственную схему хеширования.
• Слабый сброс пароля. Ссылки для сброса должны работать один раз, быстро истекать и не сообщать, есть ли аккаунт с таким email.
• Путаница вашего входа со входом в конструктор. Пользователи вашего приложения отделены от вашего аккаунта в инструменте, которым вы его создаёте.
• Нет ограничения попыток входа. Без него злоумышленники могут подбирать пароли бесконечно.

Что просить у вашего ИИ-конструктора

• «Добавь регистрацию и вход с помощью [известной библиотеки или провайдера]. Не пиши собственное хеширование паролей».
• «Храни пароли в хешах bcrypt или Argon2».
• «Используй для сессии cookie с HttpOnly и Secure».
• «Добавь роли: admin и member. Перечисли каждую конечную точку и то, какие роли могут её вызывать».
• «Обеспечь на сервере, что пользователи могут читать и редактировать только свои записи. Затем покажи, как ты это проверил».
• «Добавь сброс пароля с одноразовыми ссылками, которые истекают через час».
• «Ограничь число попыток входа».

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

Аутентификация в Mythex

Mythex не предоставляет встроенного продукта аутентификации для пользователей вашего приложения; вы выбираете подход — email и пароль, которые хранятся в базе данных проекта, или SDK внешнего провайдера — и просите агента его добавить. Ключи провайдера хранятся в секретах проекта, а не в чате. Это отдельно от того, как вы входите в сам Mythex. Рецепт в документации по добавлению входа в приложение содержит стартовый промпт, который можно адаптировать, а что такое API объясняет, где находятся серверные проверки.

Вопросы