Это своего рода компромисс, который вы делаете, когда используете непрозрачные токены (которые требуют самоанализа).
С непрозрачными токенами:
- OAuth 2.0 Клиенты не могут видеть содержание
- Серверы авторизации могут отозвать токен в любое время
Компромисс заключается в том, что при каждом запросе необходимо проверять сервер авторизации, чтобы убедиться, что токен не был признан недействительным. .
С JWT:
- OAuth 2.0 Клиенты могут проверять содержимое токена
- JWT несет собственную информацию об истечении срока действия
В обмен на повышение производительности JWT вы получаете то, что он не может быть признан недействительным, только истек срок его действия.
Итак, это был не ваш вопрос, а вопрос о производительности, а JWT Очень распространенный способ устранения проблемы непрозрачных токенов.
Вы также можете спросить себя, нужны ли вам дополнительные преимущества безопасности непрозрачных токенов для каждого пути в вашем приложении. Не могли бы вы использовать JWT для некоторых путей и проверить на сервере авторизации пути с более высоким уровнем безопасности?
В любом случае, вы спрашивали о кэшировании. Да, Spring Boot публикует для вас экземпляр OpaqueTokenIntrospector
, который можно переопределить с помощью кэша:
@Component
public class CachingOpaqueTokenIntrospector
implements OpaqueTokenIntrospector {
private final NimbusOpaqueTokenIntrospector introspector =
// ... construct
@Override
public OAuth2AuthenticatedPrincipal introspect(String token) {
// call delegate introspector and cache
}
}
Вы можете использовать аннотацию @Cacheable
в методе introspect
, например.