Comments 10
А у вас в примере специально не проверяется заголовок и подпись JWT токена или это ошибка?
Добрый день, если вы про js, то в этом нет необходимости, так как это проверяет Keycloak при auth_request /auth
он каждый запрос к /data делает допольнительный запрос к keycloak? не кажется это расточительным, когда JWT используют именно для того что бы этого не делать.
Я понимаю, что это перевод. Но вопросики всегда могут быть к тому кто перевел, ведь он выбирает качество материала.
Это, например, для проверки, что токен не отозван на keycloak.
В статье это упоминается, что nginx free не поддерживает интеграцию с keycloak.
На самом деле ручная проверка токена в коде ( signature, exp, iss & etc ) даст мнимое улучшение производительности по сравнению с отправкой в keycloak, который сделает это сам. Плюс возможен кейс, когда токен пользователя отозван ( например, закрыли доступ, поменяли атрибуты или еще что-то). Тогда без проверки на уровне кейклока это не решить.
Либо же выпускать короткоживущие токены, например, на 1 мин, и забить на лаг в 1 мин в таких моментах. Но с точки зрения производительности - это самая большая нагрузка на auth service, так как именно генерация токена самая сложная операция.
На самом деле ручная проверка токена в коде ( signature, exp, iss & etc ) даст мнимое улучшение производительности по сравнению с отправкой в keycloak, который сделает это сам.
Это очень смело утверждать что посчитать SHA-1/SHA-256 хеш либо RSA подпись == по перфомансу с открытием соединения, отправкой данных, подсчетом того-же SHA хеша и парсингом ответа.
Я бы сказал что разница в порядок, а может и в порядки.
Отзыв JWT токенов скорее это неправильный дизайн чем кейс.
Генерация токена настолько дорогая, насколько и проверка - посчитать хеш и чуток JSON сериализации. Я реализовывал всё из списка, там ничего "тяжелого" по перформансу нет.
Очень сомневаюсь что KeyCloak переживет сколько нибудь существенную нагрузку в таком решении.
Для чего вообще руками ходить в KC и руками же парсить токен, если уже давно придумали решения вроде oauth2-proxy? Он и токен проверит без похода в KC и в заголовки положит содержимое из токена (имя, роли, почту) и пользователя отправит на страницу аутентификации если токен не верный. Плюс сам может сессию продлить через refresh токен.
В целом можно без nginx обойтись
https://github.com/oneconcern/keycloak-gatekeeper
Последний релиз в 2021 году. Похоже, что больше не поддерживается.
https://gogatekeeper.github.io/ (https://github.com/gogatekeeper/gatekeeper) стоит смотреть, он поддерживается.
Nginx и Keycloak: Идеальное сочетание для обеспечения безопасности приложений