Когда мы используем различные приложения и веб-сайты, постоянно выполняются три основных шага в области безопасности:
Идентичность
Идентификация
Авторизация
На приведенной ниже диаграмме показано, где эти методы применяются в типичной архитектуре веб-сайта, и их значение.
В этой серии из 2 частей мы рассмотрим различные методы аутентификации, включая пароли, сеансы, файлы cookie, токены, JWTs (веб-токены JSON), SSO (единый вход) и OAuth2. Мы обсуждаем проблемы, которые решает каждый метод, и как выбрать правильный метод аутентификации для наших нужд.
Аутентификация по паролю
Аутентификация по паролю — это фундаментальный и широко используемый механизм для проверки личности пользователя на веб-сайтах и в приложениях. В этом методе пользователи вводят свою уникальную комбинацию имени пользователя и пароля, чтобы получить доступ к защищенным ресурсам. Введенные учетные данные сверяются с сохраненной в системе информацией о пользователе, и если они совпадают, пользователю предоставляется доступ.
Хотя аутентификация по паролю является основополагающим методом верификации пользователя, у него есть некоторые ограничения. Пользователи могут забыть свои пароли, а управление уникальными именами пользователей и паролями для нескольких веб-сайтов может оказаться непростой задачей. Кроме того, системы, основанные на паролях, могут быть уязвимы для атак, таких как атаки методом перебора или по словарю, если не приняты надлежащие меры безопасности.
Для решения этих проблем современные системы часто внедряют дополнительные меры безопасности, такие как многофакторная аутентификация, или используют другие механизмы аутентификации (например, сеансовые файлы cookie или аутентификация на основе токенов), чтобы дополнить или заменить аутентификацию на основе пароля для последующего доступа к защищенным ресурсам.
В этом разделе мы сначала рассмотрим аутентификацию на основе пароля, чтобы понять ее историю и то, как она функционирует.
Базовая аутентификация доступа по протоколу HTTP
Проверка подлинности базового доступа по протоколу HTTP требует, чтобы веб-браузер предоставлял имя пользователя и пароль при запросе защищенного ресурса. Учетные данные кодируются с использованием алгоритма Base64 и включаются в поле заголовка HTTP Authorization: Basic.
Вот как это обычно работает:
Клиент отправляет запрос на доступ к защищенному ресурсу на сервере.
Если клиент еще не предоставил никаких учетных данных для аутентификации, сервер отвечает кодом статуса 401 неавторизованный и включает заголовок WWW-Authenticate: Basic, указывающий, что требуется базовая аутентификация.
Затем клиент предлагает пользователю ввести свое имя пользователя и пароль, которые объединяются в единую строку в формате username:password.
Объединенная строка закодирована в Base64 и включена в заголовок "Authorization: Basic" в последующем запросе к серверу, например, Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=.
Получив запрос, сервер декодирует учетные данные в кодировке Base64 и разделяет имя пользователя и пароль. Затем сервер проверяет предоставленные учетные данные по своей пользовательской базе данных или службе аутентификации.
Если учетные данные совпадают, сервер предоставляет доступ к запрошенному ресурсу. Если нет, сервер выдает код состояния 401 "Неавторизованный".
Базовая аутентификация доступа по протоколу HTTP имеет ограничения. Имя пользователя и пароль, закодированные с использованием Base64, могут быть легко расшифрованы. Большинство веб-сайтов используют протокол TLS (Transport Layer Security) для шифрования данных между браузером и сервером, повышая безопасность. Однако учетные данные пользователей по-прежнему могут подвергаться перехвату или атакам типа «человек посередине».
При проверке подлинности HTTP Basic Access браузер отправляет заголовок авторизации с необходимыми учетными данными для каждого запроса на защищенные ресурсы в пределах одного домена. Это обеспечивает более плавный пользовательский интерфейс без повторного ввода имени пользователя и пароля. Но, поскольку каждый веб-сайт использует свои собственные имена пользователей и пароли, пользователям может быть трудно запомнить свои учетные данные.
Этот механизм аутентификации устарел для современных веб-сайтов.
Аутентификация с использованием сеансовых файлов cookie
Аутентификация с использованием сессионных файлов cookie устраняет неспособность аутентификации базового доступа по протоколу HTTP отслеживать статус входа пользователя в систему. Идентификатор сеанса генерируется для отслеживания статуса пользователя во время его посещения. Этот идентификатор сеанса записывается как на стороне сервера, так и в файле cookie клиента, служа механизмом аутентификации. Это называется сессионным файлом cookie, потому что это файл cookie с сохраненным внутри идентификатором сеанса. Пользователи по-прежнему должны изначально указать свое имя пользователя и пароль, после чего сервер создает сеанс для посещения пользователя. Последующие запросы включают файл cookie, позволяющий серверу сравнивать идентификаторы сеанса на стороне клиента и на стороне сервера.
Давайте посмотрим, как это работает:
Клиент отправляет запрос на доступ к защищенному ресурсу на сервере. Если клиент еще не прошел аутентификацию, сервер выдает запрос на вход в систему. Клиент отправляет свое имя пользователя и пароль на сервер.
Сервер проверяет предоставленные учетные данные по своей пользовательской базе данных или службе аутентификации. Если учетные данные совпадают, сервер генерирует уникальный идентификатор сеанса и создает соответствующий сеанс в хранилище на стороне сервера (например, в памяти сервера, базе данных или сервере сеансов).
Сервер отправляет идентификатор сеанса клиенту в виде файла cookie, обычно с заголовком Set-Cookie.
Клиент сохраняет сессионный файл cookie.
Для последующих запросов он отправляет файл cookie вместе с заголовками запросов.
Сервер проверяет идентификатор сеанса в файле cookie на соответствие сохраненным данным сеанса для аутентификации пользователя.
В случае подтверждения сервер предоставляет доступ к запрошенному ресурсу. Когда пользователь выходит из системы или по истечении заданного времени истечения срока действия, сервер аннулирует сеанс, а клиент удаляет сессионный файл cookie.
Источник: https://blog.bytebytego.com/p/password-session-cookie-token-jwt?utm_source=substack&utm_medium=email