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