Изучите основные концепции
Аутентификация является ключевой функцией в любом реальном проекте. В студенческие годы я месяцами пытался найти оптимальный способ создания полнофункциональной системы аутентификации и авторизации с использованием стека MERN.
Проблема заключалась в том, что существуют разные способы реализации системы аутентификации с использованием современных технологий. У вас есть системы на основе файлов cookie, системы на основе токенов, и когда дело доходит до выбора различных пакетов, вы можете использовать различные пакеты, такие как паспорт.js, библиотеки на основе Microsoft. Кроме того, существуют сторонние решения, такие как OAuth.
Итак, как мы можем выбрать наиболее подходящий подход? Для этого у вас должно быть базовое представление о потоке аутентификации при выборе правильного технологического подхода. Эта статья представляет собой более общее объяснение того, как работают системы аутентификации.
Если вы хотите поддержать меня как писателя, рассмотрите возможность подписки стать участником Medium. Чтобы я мог тратить больше времени на обмен знаниями и создание большего количества контента. Всего 5 долларов в месяц, и вы получаете неограниченный доступ к Medium.
Прежде чем мы начнем
Некоторые из вас, возможно, встречали слова Аутентификация и Авторизация. Прежде чем мы продолжим, лучше понять разницу между двумя словами. Аутентификация и авторизация — это два разных раздела системы входа в систему.
Аутентификация проверяет имя пользователя, пароль и позволяет пользователю войти в систему, если имя пользователя и пароль совпадают. Авторизация проверяет, есть ли у вошедшего в систему пользователя надлежащее разрешение на выполнение различных действий. Возможно, авторизованный пользователь должен только просматривать вещи, но не удалять их. Другой пользователь может иметь разрешение как на просмотр, так и на удаление. Такое разрешение для каждой роли проверяется с помощью авторизации
Основы аутентификации
Аутентификация может выполняться либо на основе файлов cookie, либо на основе токенов. во-первых, давайте посмотрим, каковы основные шаги, которые происходят в любом потоке аутентификации.
Обзор аутентификации
На приведенной выше диаграмме клиент — это приложение (веб-браузер), которое мы используем для доступа к ресурсам (интернету). Думайте, что приведенная выше диаграмма предназначена для сценария входа пользователя на веб-сайт членства. Веб-сайт членства предоставляет контент, доступный только зарегистрированным пользователям.
- Пользователь вводит логин и пароль на странице входа
- Сервер проверяет введенные учетные данные.
- Если учетные данные действительны, вход на сервер выполнен успешно и создается часть данных для идентификации вошедшего в систему пользователя.
- Отправьте этот фрагмент данных на сторону клиента.
- Клиент сохраняет этот фрагмент данных и использует его всякий раз, когда отправляет запрос на серверную часть, запрашивая содержимое членства.
- При запросе данных о членстве с сервера клиент прикрепляет часть данных к запросу.
- Сервер проверяет прикрепленные данные перед отправкой ресурсов.
- Если проверка прошла успешно, сервер отправляет запрошенные данные.
На приведенной ниже диаграмме показано, как работает процесс аутентификации, когда учетные данные недействительны.
Существуют разные подходы к созданию этой части проверенной информации и ее повторному использованию. Для выполнения этих сценариев в основном используются подходы на основе токенов или файлов cookie. У каждого подхода есть свои плюсы и минусы.
На основе файлов cookie
Как я уже говорил ранее, существуют разные подходы к созданию фрагмента данных, говорящего о том, что пользователь действителен. Давайте посмотрим, как файлы cookie используются при аутентификации.
В системе аутентификации на основе файлов cookie после ввода действительных учетных данных сервер создает идентификатор активного сеанса и сохраняет его в базе данных. А также прикрепите к браузеру cookie с соответствующим sessionId, совпадающим с созданной активной сессией в базе данных.
Идентификатор активного сеанса, хранящийся в БД, и идентификатор сеанса в браузере совпадают.
Веб-браузеры автоматически сохраняют файл cookie, который отправляется со стороны сервера. Поэтому разработчикам не нужно писать код для обработки входящего файла cookie для сохранения в браузере.
Всякий раз, когда браузер запрашивает защищенный ресурс, он отправляет идентификатор сеанса с запросом браузера. Сервер может сравнить отправленный идентификатор сеанса с сохраненными активными записями идентификатора сеанса в базе данных и проверить.
Если полученный идентификатор сеанса совпадает с идентификатором активного сеанса в БД, отправьте защищенный ресурс
Свойства аутентификации на основе файлов cookie
Аутентификация на основе файлов cookie зависит от состояния, поскольку записи аутентификации должны храниться как во внешнем, так и во внутреннем интерфейсе. Таким образом, в любое время внутри системы аутентификации на основе файлов cookie в базе данных есть список вошедших в систему пользователей.
После того, как пользователь выходит из системы, и файл cookie на стороне браузера/клиента, и идентификатор сеанса на стороне сервера удаляются.
Аутентификация на основе токенов
Аутентификацию на основе токенов можно использовать внутри веб-браузеров, мобильных приложений, настольных приложений и даже с устройств IoT. Таким образом, клиент не ограничен веб-браузером, как при использовании файлов cookie.
Очевидно, что внутри системы аутентификации на основе токенов он отправляет подписанный токен на сторону браузера, если учетные данные пользователя верны. Одно из основных отличий заключается в том, что система на основе токенов, основанная на файлах cookie, не отправляет подписанный файл cookie как обычные данные на сторону клиента. Таким образом, клиент не может отдельно идентифицировать токен, отправленный с сервера.
Поэтому нам нужно написать отдельный код на стороне клиента для обработки этого входящего токена. мы должны извлечь его и сохранить в браузере. Мы можем сохранить токен в локальном хранилище или хранилище сеанса, или даже мы можем сохранить входящий токен в файле cookie.
При запросе данных с сервера клиент отправляет запрос, присоединяя к своему запросу токен. Токен прикрепляется к его заголовку авторизации, а также мы добавляем слово Bearer перед токеном.
как только токен получен со стороны сервера, он декодирует токен и проверяет, является ли он действительным токеном. Если токен действителен, запрошенные данные передаются.
Свойства аутентификации на основе токенов
Аутентификация на основе токенов быстрее, чем аутентификация на основе файлов cookie. Основная причина заключается в том, что всякий раз, когда система на основе файлов cookie хочет проверить пользователя, она должна выполнять поиск в базе данных активных пользователей, чтобы найти соответствующий идентификатор сеанса, что занимает больше времени.
Системы аутентификации на основе токенов подходят для приложений, использующих несколько доменов и поддоменов.
Системы аутентификации на основе токенов могут использоваться как в мобильных, так и в веб-системах. Таким образом, единую реализацию аутентификации можно использовать на мобильных и настольных устройствах.
Надеюсь, вам понравилось это читать. Если вы хотите поддержать меня как писателя и время, которое я трачу на обмен знаниями, рассмотрите возможность подписки стать участником Medium. Всего 5 долларов в месяц, и вы получаете неограниченный доступ к Medium.
