6 Методы входа в систему каждый разработчик должен знать
18 июня 2025 г.Когда я впервые начал создавать веб -приложения, «Аутентификация» просто означала вход. Просто, просто, верно?
Но потом появились вопросы - что такое жетон? Стоит ли использовать файлы cookie или api -клавиши? Почему так много вариантов просто для проверки пользователя?
Оказывается, у каждого метода есть цель. Некоторые устарели, некоторые безопасны, а другие отлично подходят для конкретных вариантов использования.
В этом блоге я сломаю шесть общих методов аутентификации -Basic Auth, cookie, токены, клавиши API, OTP и SSO- и объясните, когда (и почему) использовать каждый.
Давайте начнем.
Основная аутентификация
Основная аутентификация работает, отправляя кодированное имя пользователя и пароль на сервер с каждым запросом. Эти учетные данные включены в заголовки запроса.
Имя пользователя и пароль объединяются в одну строку и кодируются с использованием BASE64. Эта кодированная строка затем отправляется вAuthorizationЗаголовок HTTP -запроса.
Основная аутентификация является одним из старейших механизма аутентификации, который восходит к 1990 -м годам.
Хотя базовая аутентификация проста и эффективна, она не очень безопасна, поскольку учетные данные просто основаны на базе 64, что делает их легко обратимыми. Это оставляет его уязвимым для атак человека в среднем уровне, особенно при использовании небезопасного протокола, такого как HTTP.
Также нет простого способа вывести пользователя через сервер.
Даже с безопасным протоколом внизу базовая аутентификация может страдать от атак CSRF. По этим причинам большинство современных веб -приложений отошли от него в поисках более безопасных механизмов аутентификации.
Аутентификация на основе печенья
Аутентификация на основе cookie работает, генерируя идентификатор сеанса, когда пользователь входит в систему, который затем хранится в качестве cookie в браузере пользователя. Для последующих запросов браузер автоматически включает в себя этот файл cookie, что позволяет серверу проверить личность пользователя.
Сгенерированному идентификатору сеанса дается время истечения, чтобы убедиться, что одно печенье не может использоваться для бесконечности.
Аутентификация на основе cookie улучшается при базовой аутентификации, позволяя серверу управлять пользовательскими сеансами. Это включает в себя такие функции, как вход на сторону сервера, где пользователь может быть принудительно выйти из строя, не допустив своего сеанса на сервере.
Современные браузеры предлагают несколько механизмов, которые помогают защитить файлы cookie от угроз безопасности, таких как сценарии поперечного сайта (XSS) и подделка по перекрестным запросам (CSRF). Особенности, такие какHttpOnlyВSecure, иSameSiteФлаги печенья помогают уменьшить эти уязвимости.
Тем не менее, аутентификация на основе файлов cookie не без недостатков. Данные сеанса должны храниться на сервере, который потребляет ресурсы и не может легко масштабироваться. Кроме того, файлы cookie в основном предназначены для веб-браузеров и не подходят для других типов клиентов, таких как мобильные приложения или API.
Аутентификация на основе токенов
В этом методе аутентификации сервер отвечает на запрос входа в систему пользователя, выпустив токен. Токен является автономным, что означает, что он содержит всю информацию, необходимую для проверки, и предназначена для защиты от подделки.
В аутентификации на основе токенов серверу не нужно хранить какие-либо данные сеанса-только открытый ключ (если использование подписанных токенов, таких как JWTS) для проверки токена, предоставленного клиентом. Это контрастирует с аутентификацией на основе сеанса, где сервер должен поддерживать состояние сеанса.
Как только клиент получает токен, он может включить его в заголовки запроса для выполнения аутентифицированных запросов. Это делает токеновую аутентификацию без сохранения состояния и подходящим для масштабируемых распределенных систем.
Приложения, использующие аутентификацию на основе токков, проще в масштабе и могут поддерживать широкий спектр клиентов.
Самая популярная аутентификация на основе токенов - это JSON Web Tokens (или JWT).
Есть и некоторые недостатки. Если токены не хранятся на стороне клиента, их можно украсть и использовать для выдачи за пользователя. Кроме того, токены, особенно те, которые содержат данные о полезной нагрузке, такие как JWTS, обычно больше по размеру по сравнению с другими механизмами аутентификации, что приводит к немного более высоким использованию полосы пропускания.
Аутентификация на основе ключей API
Аутентификация на основе ключей API-это метод для аутентификации пользователей или приложений, доступа к API (интерфейс прикладного программирования).
Ключ API - это уникальный идентификатор (обычно длинная буквенно -цифровая строка), выданная разработчику или приложению для доступа к API. Он действует как простой токен доступа, идентифицируя вызовный проект или приложение.
Ключи API выпускаются, когда разработчики регистрируются у провайдера API и доступа к запросу. Эти ключи обычно связаны с конкретными проектами и могут быть настроены с различными уровнями контроля доступа. Поставщики API используют их для мониторинга использования и применения ограничений ставок, часто для счетов, аналитики или целей безопасности.
Есть несколько различных способов, которыми клиент может отправить ключ API на сервер -
- HTTP -заголовок -
Authorization: Api-Key <your_api_key>илиx-api-key: <your_api_key> - Параметр запроса -
https://api.example.com/data?api_key=<your_api_key> - Запросить тело(для запросов сообщений) -
{ "api_key": "<your_api_key>" }
OTP на основе аутентификации
Другим широко используемым методом аутентификации в современных программных приложениях являетсяАутентификация на основе OTP (одноразовый пароль)Полем В отличие от традиционных фиксированных паролей, OTP-аутентификация опирается на уникальный, чувствительный ко времени код, который действителен только для одного сеанса входа в систему или транзакции.
Когда пользователь пытается войти в систему, сервер генерирует однократный пароль с коротким окном с истечением (обычно от 30 секунд до нескольких минут). Этот OTP отправляется пользователю через доверенный, предварительно подтвержденный канал, такой как зарегистрированный номер мобильного телефона (через SMS) или адрес электронной почты. Пользователь должен ввести правильный OTP, чтобы завершить процесс входа в систему.
Этот метод добавляет дополнительный уровень безопасности по:
- Сокращение риска повторного использования паролей и фишинговых атак
- Обеспечение того, чтобы только был закончен законным пользователем (с доступом к надежному устройству/электронной почте) вход в систему
После проверки OTP и пользователь успешно аутентифицируется, система обычно выпускаетСессионный токен или cookieПоддерживать аутентифицированное состояние пользователя на протяжении всей сеанса. Затем этот токен используется для последующих запросов, избегая необходимости повторного входа в учетные данные.
🔐 Аутентификация OTP часто используется в качестве формыдвухфакторная аутентификация (2FA)В сочетании с традиционным паролем, дальнейшее усиление безопасности учетной записи.
Одиночный знак (SSO)
Single Sign-On (SSO)-это способ позволить пользователям войти в систему только один раз, а затем получить доступ к нескольким приложениям или системам без необходимости входить в систему каждый раз. После того, как пользователь вошел через поставщика SSO, токен создается и передается другим доверенным сервисам, поэтому пользователь может перемещаться между ними плавно, не прося снова ввести свои учетные данные.
Вот как это работает
- Пользователь посещает веб -сайт и пытается войти в систему.
- Веб -сайт проверяет, если пользователь уже вошел в систему через наличие некоторых токенов или файлов cookie. Если это так, запрос обрабатывается.
- Если нет, пользователь перенаправляется на страницу входа в систему SSO.
- Пользователь входит в систему SSO.
- SSO проверяет учетные данные с поставщиком идентификаций (например, Active Directory).
- После успешной проверки SSO отправляет информацию о аутентификации на веб -сайте.
- Веб -сайт предоставляет доступ и использует токены/файлы cookie для поддержания аутентификации в других приложениях или страницах.
С этим мы достигаем конца этого блога! Если вам понравилось читать это, подумайте о том, чтобы оставить подобное!
Оригинал