Comments 11
Хотел применить JWT на одном из проектов. Остановило то, что отдельно взятый токен очень сложно отозвать.
Из известных мне решений — хранение «черного списка» в базе данных. Но тогда возникает вопрос — почему бы не хранить в этой базе сами сессии?
Также где-то видел исследование (к сожалению, не могу найти ссылку) о том, что незначительное увеличение размера запроса (которое тут неизбежно) значительно влияет на скорость загрузки страницы.
Из известных мне решений — хранение «черного списка» в базе данных. Но тогда возникает вопрос — почему бы не хранить в этой базе сами сессии?
Также где-то видел исследование (к сожалению, не могу найти ссылку) о том, что незначительное увеличение размера запроса (которое тут неизбежно) значительно влияет на скорость загрузки страницы.
+1
Другой распространенный вариант — короткоживущий access_token (например, минута) плюс refresh_token, и его регулярное обновление через сервис авторизации. А в нём уже для конкретного клиента может храниться условное значение not before, признающее все refresh токены, выданные ранее этого момента недействительными.
0
Или невнимательно смотрела, или не увидела refresh токена после окончания срока действия.
+1
А не проще было взять не самодельный JWT, а что-нибудь типа OpenId Connect (он построен поверх OAuth2). Там уже есть нормальные токены (в формате JWT), access_token обычно короткоживущий, что снимает проблему с отзывом, есть стабильные способы использования (типа заголовка
Ну и по реализации:
Authentication: Bearer <token>
)?Ну и по реализации:
TokenAuthenticationFilter
бессмысленно переопределяет doFilter
.+2
Вообще смысл статьи не особо понятен… Показать что вместо готовых решений можно построить свой собственный велосипед? Я конечно за, что каждый программист должен уметь реализовать все с нуля, но раз уж в заголовке прозвучало нечто вроде "с помощью Spring Security", то давайте его и использовать. Например, Spring Security Oauth, отличная реализация как серверной так и клиентской части. Поддерживает оба версии стандарта, отлично интегрируется с Spring Security, благодаря DI, позволяет переопределить практически все реализации пол умолчанию своими собственными.
+1
Была мысль использовать и OAuth, и OpenID, просто у нас не было в этом необходимости, поэтому быстренько собрал такую аутентификцию
0
Всмысле не было необходимости? Эти библиотеки как раз и сделаны для того, чтобы "быстренько собрать аутентификцию" )))
0
Что-нибудь попроще нужно было, просто аналог Login Form со своей спецификой. Для серьёзной реализации аутентификации, конечно, лучше с библиотеками, через OAuth и т. п.
Насчёт велосипедов. Если необходима малая часть возможностей библиотеки, если велосипед не требует больших трудовых и временных затрат и позволяет добиться желаемого, то почему бы и нет. Есть Angular.js, но иногда хочется взять и написать всё просто на JS )))
Насчёт велосипедов. Если необходима малая часть возможностей библиотеки, если велосипед не требует больших трудовых и временных затрат и позволяет добиться желаемого, то почему бы и нет. Есть Angular.js, но иногда хочется взять и написать всё просто на JS )))
0
Я так понимаю OAuth не о том…
Представим что после успешной аутентикации мы отдаем клиенту JWT токем в котором уж есть все что нужно для последующей авторизации…
например браузерному приложению которое общается с бекэндом
при этом бэкэнд состоит из 5 микросервисев. В случае с JWT микросервицы сами смогут проверить даныные из JWT больше никуда не обращаясь в свою очередь…
Это очень очень круто.
Представим что после успешной аутентикации мы отдаем клиенту JWT токем в котором уж есть все что нужно для последующей авторизации…
например браузерному приложению которое общается с бекэндом
при этом бэкэнд состоит из 5 микросервисев. В случае с JWT микросервицы сами смогут проверить даныные из JWT больше никуда не обращаясь в свою очередь…
Это очень очень круто.
+1
Sign up to leave a comment.
Аутентификация с использованием Spring Security и JWT-токенов