Чтобы показать размер акулы, через которую современный Software development перепрыгнул, вот реальная история.
Пять лет назад надо было организовать JWT аутентификацию на сайте с PHP бэкендом. Взял
Через некоторое время делал JWT аутентификацию на другом проекте, заметил, что
Продолжение следует...
#laravel #dx #optimization #jwt
Пять лет назад надо было организовать JWT аутентификацию на сайте с PHP бэкендом. Взял
firebase/php-jwt - продукт разработчиков Google, ноль зависимостей, один файл среднего размера который делал всю криптографию. Логика там простая - сгенерировать JWT токен при логине и проверить подпись токена при запросе с фронтенда. Реализация на бэке заняла строк 50 кода, на фронте - столько же.Через некоторое время делал JWT аутентификацию на другом проекте, заметил, что
firebase/php-jwt переписался в ОО стиле - появились классы JWT, Key, ExpiredException и т.д. Логика та же, размер общий чуть увеличился.Продолжение следует...
#laravel #dx #optimization #jwt
Есть два основных подхода для аутентификации пользователя
Аутентификация на основе сессии
При этом подходе вы храните информацию о сессии в базе данных или хранилище сессий и передаете идентификатор сессии пользователю.
Представьте, что пассажир получает только идентификатор билета на свой рейс, а все остальные данные хранятся в базе данных авиакомпании.
Вот как это работает:
- Пользователь делает запрос на вход в систему, и он отправляется на внутренний сервер..
- Бэкэнд создает сессию с использованием секретного ключа и сохраняет данные в хранилище сессий.
- Сервер отправляет клиенту cookie с уникальным идентификатором сессии.
- Пользователь делает новый запрос, и браузер отправляет идентификатор сессии вместе с запросом.
- Сервер аутентифицирует пользователя по идентификатору сессии.
Аутентификация на основе JWT
В подходе на основе JWT информация о сессии не хранится в хранилище сессий.
Вся информация доступна в токене.
Представьте себе, что вы получаете авиабилет вместе со всеми деталями, имеющимися на билете, но в закодированном виде.
Вот как это работает:
- Пользователь делает запрос на вход в систему, и он отправляется на внутренний сервер.
- Сервер проверяет учетные данные и выдает JWT. JWT подписывается с помощью закрытого ключа и не требует хранения сессии.
- JWT передается клиенту либо в виде cookie, либо в теле ответа. У обоих подходов есть свои плюсы и минусы.
- При каждом последующем запросе браузер отправляет cookie с JWT.
- Сервер проверяет JWT с помощью секретного закрытого ключа и извлекает информацию о пользователе.
#jwt #auth
Аутентификация на основе сессии
При этом подходе вы храните информацию о сессии в базе данных или хранилище сессий и передаете идентификатор сессии пользователю.
Представьте, что пассажир получает только идентификатор билета на свой рейс, а все остальные данные хранятся в базе данных авиакомпании.
Вот как это работает:
- Пользователь делает запрос на вход в систему, и он отправляется на внутренний сервер..
- Бэкэнд создает сессию с использованием секретного ключа и сохраняет данные в хранилище сессий.
- Сервер отправляет клиенту cookie с уникальным идентификатором сессии.
- Пользователь делает новый запрос, и браузер отправляет идентификатор сессии вместе с запросом.
- Сервер аутентифицирует пользователя по идентификатору сессии.
Аутентификация на основе JWT
В подходе на основе JWT информация о сессии не хранится в хранилище сессий.
Вся информация доступна в токене.
Представьте себе, что вы получаете авиабилет вместе со всеми деталями, имеющимися на билете, но в закодированном виде.
Вот как это работает:
- Пользователь делает запрос на вход в систему, и он отправляется на внутренний сервер.
- Сервер проверяет учетные данные и выдает JWT. JWT подписывается с помощью закрытого ключа и не требует хранения сессии.
- JWT передается клиенту либо в виде cookie, либо в теле ответа. У обоих подходов есть свои плюсы и минусы.
- При каждом последующем запросе браузер отправляет cookie с JWT.
- Сервер проверяет JWT с помощью секретного закрытого ключа и извлекает информацию о пользователе.
#jwt #auth