Является ли аутентификация Basi c аутентификацией на основе сеанса и почему Jwt более рекомендуется? - PullRequest
0 голосов
/ 20 января 2020

Я узнаю об аутентификации Basi c и аутентификации Jwt с помощью Java и Spring, и я хочу спросить вас, является ли аутентификация basi c аутентификацией на основе сеанса?

Я знаю, что при аутентификации на основе сеанса, когда клиент входит в систему, идентификатор сессии сохраняется в cook ie в браузере клиента, и после этого, когда клиент делает другой запрос, сервер сравнивает идентификатор сеанса с данные хранятся в памяти сервера. А также я хочу спросить вас, как sessionId отправляется с клиентского браузера на сервер? Он отправляется в заголовке как токен или как?

И последний вопрос: как сервер проверяет токен Jwt? Я знаю, что в случае аутентификации сеанса идентификатор сеанса, отправленный клиентом, сравнивается с данными из памяти сервера. Но что происходит в случае аутентификации Jwt? Токен отправляется с заголовком, и я знаю, что сервер проверяет его, и в памяти сервера нет данных. Тогда как сервер сравнивает токен? Любые отзывы будут оценены! Спасибо!

1 Ответ

1 голос
/ 20 января 2020

, если базовая c аутентификация является сеансовой аутентификацией? Я знаю, что в сеансовой аутентификации

ну тогда почему вы спрашиваете?

На самом деле - базовая c аутентификация означает, что учетные данные пользователя (имя пользователя и пароль) отправляются в заголовке http авторизации

Authorization: Basic base64(username:password)

Сервер может использовать или не использовать готовку сеанса ie. Повар сеанса ie может использоваться с другими средствами аутентификации или даже без какой-либо аутентификации

как сеанс ID отправляется из клиентского браузера на сервер?

Как сеансовый повар ie сеансовый повар ie отправляется в виде заголовка http, который браузер рассматривает как постоянный сеанс

И последний вопрос: как сервер проверяет токен Jwt?

Токен JWT должен быть подписан. Обратите внимание, что токен обычно состоит из 3 частей

header.body.signature

, заголовок указывает тип подписи (ключ asymmetri c или общий секрет), а подпись является аутентифицированным (подписанный или hma c -ed) заголовком и содержание.

Итак - сервер должен проверить эмитента, срок действия и подпись.

Таким образом, серверу (поставщику услуг) не нужно заранее знать личность клиента. Поставщик услуг должен знать издатель (служба аутентификации, которая выдает токен jwt) publi c ключ или общий секретный ключ.

После проверки jwt служба может принять идентификатор вызывающего абонента на основе информации в токене jwt.

почему Jwt более рекомендуется?

Зависит от варианта использования. (у всего есть свои плюсы и минусы)

Я бы рекомендовал использовать jwt в распределенной и / или микросервисной архитектуре. Службе не требуется доступ к учетным данным или аутентификация пользователя.

...