В статье рассказывается, как объединить Spring Security с Jwt для достижения входа в систему без сохранения состояния.

Существует множество стратегий входа в систему в проектах разделения внешнего и внутреннего интерфейса, но JWT в настоящее время является популярным решением. В этой статье вы узнаете, как использовать Spring Security и JWT вместе для достижения разделения внешнего и внутреннего интерфейса. Решение для входа в систему времени.

1. Вход без сохранения состояния

1. Что такое состояние?

Служба с отслеживанием состояния, то есть сервер должен записывать информацию о клиенте для каждого сеанса, чтобы идентифицировать личность клиента и обрабатывать запрос в соответствии с идентификатором пользователя. Типичным дизайном является сеанс в Tomcat

Например, вход в систему: после того, как пользователь входит в систему, мы сохраняем информацию о пользователе в сеансе сервера и даем пользователю значение cookie, записываем соответствующий сеанс, а затем при следующем запросе пользователь несет значение cookie (этот шаг автоматически завершается браузером) , Мы можем идентифицировать соответствующий сеанс, чтобы найти информацию о пользователе.
На данный момент этот метод является наиболее удобным, но у него есть и следующие недостатки:

(1) Сервер сохраняет большой объем данных, что увеличивает нагрузку на сервер
(2) Сервер сохраняет состояние пользователя и не поддерживает кластерное развертывание.

2. Что такое апатрид?

Каждая служба в кластере микросервисов использует интерфейс в стиле RESTful для внешнего предоставления.
И одна из важнейших характеристик стиля RESTful - это отсутствие состояния сервисов, а именно:

Сервер не хранит никакой информации о запросе клиента
. Каждый запрос клиента должен содержать информативную информацию, и с помощью этой информации можно идентифицировать личность клиента.

Итак, каковы преимущества этого безгражданства?

Клиентские запросы не зависят от информации сервера, и для нескольких запросов не требуется доступ к одному и тому же серверу
. Кластер и состояние сервера прозрачны для
клиента. Сервер можно перемещать и масштабировать произвольно (развертывание кластера удобно), чтобы
уменьшить размер сервера Давление хранения

3. Как добиться безгражданства?

Процесс входа в систему без сохранения состояния:

Сначала клиент отправляет имя учетной записи / пароль на сервер для аутентификации. После прохождения
аутентификации сервер шифрует и кодирует информацию о пользователе в токен, который возвращается клиенту.
После того, как клиент отправляет запрос, он должен нести
пару токенов аутентификации сервера. Токен, отправленный клиентом, расшифровывается, проверяется, действителен ли он, и получается информация для входа в систему.

二 、 JWT

1. Введение в JWT

JWT, полное имя - Json Web Token, представляет собой упрощенную спецификацию авторизации и аутентификации в стиле JSON, которая может реализовать распределенную авторизацию веб-приложений без сохранения состояния:

Вставьте описание изображения сюда
В качестве спецификации JWT не привязан к определенному языку. Обычно используемая реализация Java - это проект с открытым исходным кодом jjwt на GitHub. Адрес следующий:https://github.com/jwtk/jjwt

2. Формат данных JWT

JWT содержит три части данных:

  1. Заголовок: Заголовок, обычно заголовок содержит две части информации:

Тип объявления, вот
алгоритм шифрования JWT , настраиваемый

Мы будем кодировать Base64Url (декодировать) в заголовке, чтобы получить первую часть данных.

  1. Полезная нагрузка: полезная нагрузка - это действительные данные. В официальном документе (RFC7519) приведены 7 примеров информации:

iss (эмитент):
срок действия эмитента (время истечения): время истечения срока действия токена
sub (тема): субъект
aud (аудитория): аудитория
nbf (не раньше): время действия
iat (дата выдачи): время выпуска
jti (идентификатор JWT ): Нумерация

Эта часть также будет использовать кодировку Base64Url для получения второй части данных.

  1. Подпись: Подпись - это аутентификационная информация для всех данных. Как правило, на основе данных первых двух шагов плюс секретный ключ службы (секретный ключ хранится на сервере и не может быть передан клиенту) он генерируется алгоритмом шифрования, настроенным в заголовке. Используется для проверки целостности и надежности всех данных.
    Сгенерированный формат данных выглядит следующим образом:

Вставьте описание изображения сюда
Обратите внимание, что если данные .разделены на три части, соответственно, соответствующие трем вышеупомянутым частям, кроме того, где данные не переносятся, изображения переноса отображаются только для удобства.

3. Процесс взаимодействия с JWT

Блок-схема:
Вставьте описание изображения сюда
пошаговый перевод:

Приложение или клиент запрашивает авторизацию у сервера авторизации. После
получения авторизации сервер авторизации возвращает токен доступа
приложению. Приложение использует токен доступа для доступа к защищенным ресурсам (например, API).

Поскольку токен, выпущенный JWT, уже содержит идентификационную информацию пользователя, и он будет передаваться в каждом запросе, поэтому службе не нужно сохранять информацию о пользователе или даже запрашивать базу данных, которая соответствует спецификации без сохранения состояния RESTful.

4. Проблемы с JWT

Сказав это, JWT не является бесшовным. Некоторые проблемы, вызванные тем, что клиент поддерживает статус входа в систему, все еще существуют. Вот примеры:

(1) Проблема с продлением, это одна из проблем, критикуемых многими людьми. Традиционное решение cookie + сессия, естественно, поддерживает продление, но, поскольку сервер не сохраняет статус пользователя, трудно полностью решить проблему продления. Если вводится redis , Хоть и может решить проблему, но jwt стал невзрачным.
(2) Проблема с выходом из системы. Поскольку сервер больше не сохраняет информацию о пользователях, обычно можно выйти из системы, изменив секрет. После изменения секрета сервера выданные неистекшие токены не пройдут аутентификацию, а затем выйдут из системы, но в конце концов, нет Традиционный выход удобен.
(3) Пароль сброшен. После сброса пароля исходный токен все еще может получить доступ к системе. В это время необходимо принудительно изменить секрет.
(4) Основываясь на втором и третьем пунктах, обычно рекомендуется, чтобы разные пользователи использовали разные секреты.

Три, актуальная интеграция SpringBoot JWT

(1) Добавить зависимость:

Вставьте описание изображения сюда
Затем добавьте зависимость jwt:

		<dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>

Необходимо добавить

рекомендация

отblog.csdn.net/nanhuaibeian/article/details/108578893