Каков наиболее масштабируемый / безопасный способ обработки маркеров refre sh в настройке аутентификации JWT?

Question

Я создаю свой собственный микросервис аутентификации и, хотя у меня есть основные настройки (генерирование токенов доступа и c.), Я немного растерялся, когда дело доходит до рефреков sh токенов.

Я чувствую, что есть много разных способов справиться с этим.

• Вы можете сохранить их в Redis или в базе данных.
• Вы можете использовать белый или черный список

В настоящее время моя идея состоит в том, чтобы добавить еще одну таблицу базы данных, которая связывает действительный токен refre sh с пользовательской сущностью. Когда пользователь достигает конечной точки выхода из системы, токен refre sh уничтожается.

Мне было интересно, было ли это хорошим решением, и в противном случае, есть ли другие возможные решения для рассмотрения. Я видел несколько статей, когда гуглил, но они берут начало где-то между 2015 и 2019 годами, и у всех них разные подходы.

Answer 1

Проблема с refre sh токенами заключается не столько в том, где и как вы храните их на стороне сервера, сколько в том, как и как вы храните их на стороне клиента.

Все зависит от того, Вы можете доверять своему клиенту (программному обеспечению, использующему токен), чтобы хранить секреты. Вы хотите выдать только refre sh токены клиенту, которому доверяете, чтобы обеспечить безопасность этих токенов. Как правило, это означает, что выдается только refre sh токенов для конфиденциальных клиентов , то есть веб-приложений, работающих на веб-сервере. Эти клиенты могут также иметь свои собственные (клиентские) учетные данные для аутентификации при использовании токена refre sh.

Для публичных c (неконфиденциальных) клиентов, таких как одностраничные приложения, некоторые библиотеки OAuth2 используйте скрытый IFRAME и сеанс cook ie с сервером авторизации для выдачи новых токенов доступа.

Итак, ответ на ваш вопрос зависит от того, какого типа клиентов вы будете использовать.