JWT с хранилищем токенов JDB C и идентификатором JSESSION - PullRequest
0 голосов
/ 04 апреля 2020

Я реализовал приложение весенней загрузки, которое выполняет аутентификацию и авторизацию с использованием Spring OAuth2.

Я использую хранилище токенов JDB C в качестве основного токена, выданного клиенту для выполнения пользовательской проверки претензий и некоторой другой проверки статуса пользователя во время выполнения приложения.

Вопрос в том, что, поскольку я использовал традиционный JSESSIONID с токеном CSRF, я не могу найти никаких преимуществ с новыми стандартами OAuth, потому что после входа в систему я буду хранить пользовательские данные в сеансе и извлекать их всякий раз, когда это необходимо для OAuth. я сохраняю данные пользователя в самом токене JWT и каждый раз декодирую токен, чтобы получить информацию о пользователе; кроме того, мне нужно в любом случае обратиться к базе данных для пользовательской проверки претензий, такой как проверка JTI.

Все говорят, что JWT предназначен для Приложение без сохранения состояния, но с хранилищем токенов JDB C я держу весь токен, который выдается каждому клиенту. Также есть дополнительные издержки на очистку токена с истекшим сроком, который будет сделан автоматически с Session. Также я использую токен refre sh в качестве способа реализации тайм-аута сессии.

Поэтому кто-нибудь может объяснить мне, когда мне следует использовать JSESSIONID и когда использовать JWT? Мое приложение работает на архитектуре AWS.

1 Ответ

0 голосов
/ 04 апреля 2020

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

...