Аутентификация с использованием Spring Security и JWT-токенов

[kafeman]

Хотел применить JWT на одном из проектов. Остановило то, что отдельно взятый токен очень сложно отозвать.

Из известных мне решений — хранение «черного списка» в базе данных. Но тогда возникает вопрос — почему бы не хранить в этой базе сами сессии?

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

[grossws]

Другой распространенный вариант — короткоживущий access_token (например, минута) плюс refresh_token, и его регулярное обновление через сервис авторизации. А в нём уже для конкретного клиента может храниться условное значение not before, признающее все refresh токены, выданные ранее этого момента недействительными.

[4ertovo4ka]

Или невнимательно смотрела, или не увидела refresh токена после окончания срока действия.

[nKognito]

В соответствии со спецификацией, определенные grant_type не должны вертать refresh токены вовсе. Например, client_credentials не подразумевает никакого refresh токена, т.к. у клиентского приложения и так есть все данные для получения нового токена

[grossws]

А не проще было взять не самодельный JWT, а что-нибудь типа OpenId Connect (он построен поверх OAuth2). Там уже есть нормальные токены (в формате JWT), access_token обычно короткоживущий, что снимает проблему с отзывом, есть стабильные способы использования (типа заголовка Authentication: Bearer <token>)?

Ну и по реализации: TokenAuthenticationFilter бессмысленно переопределяет doFilter.

[guestfromEarth]

Написал здесь

По поводу doFilter — это так, для наглядности

[nKognito]

Вообще смысл статьи не особо понятен… Показать что вместо готовых решений можно построить свой собственный велосипед? Я конечно за, что каждый программист должен уметь реализовать все с нуля, но раз уж в заголовке прозвучало нечто вроде "с помощью Spring Security", то давайте его и использовать. Например, Spring Security Oauth, отличная реализация как серверной так и клиентской части. Поддерживает оба версии стандарта, отлично интегрируется с Spring Security, благодаря DI, позволяет переопределить практически все реализации пол умолчанию своими собственными.

[guestfromEarth]

Была мысль использовать и OAuth, и OpenID, просто у нас не было в этом необходимости, поэтому быстренько собрал такую аутентификцию

[nKognito]

Всмысле не было необходимости? Эти библиотеки как раз и сделаны для того, чтобы "быстренько собрать аутентификцию" )))

[guestfromEarth]

Что-нибудь попроще нужно было, просто аналог Login Form со своей спецификой. Для серьёзной реализации аутентификации, конечно, лучше с библиотеками, через OAuth и т. п.
Насчёт велосипедов. Если необходима малая часть возможностей библиотеки, если велосипед не требует больших трудовых и временных затрат и позволяет добиться желаемого, то почему бы и нет. Есть Angular.js, но иногда хочется взять и написать всё просто на JS )))

[shuron]

Я так понимаю OAuth не о том…
Представим что после успешной аутентикации мы отдаем клиенту JWT токем в котором уж есть все что нужно для последующей авторизации…
например браузерному приложению которое общается с бекэндом
при этом бэкэнд состоит из 5 микросервисев. В случае с JWT микросервицы сами смогут проверить даныные из JWT больше никуда не обращаясь в свою очередь…
Это очень очень круто.