Вопрос или проблема
Это может быть всего лишь академический вопрос, но я задавался одним вопросом, хорошо, для этой цели нас интересует только AuthN, а не AuthZ. Также пользователей нет вообще, только коммуникации между демонами.
Конечно, мы все привыкли к схеме, где клиент, которому была назначена личность на IDP, сначала использует свой client_id и секрет, чтобы получить токен личности (это может быть простой непрозрачный токен, не подписанный JWT с любыми утверждениями) от IDP. Затем этот клиент запрашивает доступ к какому-то ресурсу и включает этот токен в запрос. Ресурс сначала проверяет токен с помощью собственного вызова к IDP, используя конечную точку token_introspection, и если это проходит, то ресурс выполняет какую-то функцию AuthZ, которая не входит в область того, о чем я хочу здесь говорить, прежде чем позволить клиенту получить доступ к запрашиваемому ресурсу.
Итак, то, о чем я только что говорил, является общим механизмом, который используют системы взаимодействия между демонами, и это работало хорошо, но что насчет этого, где вместо:
-
Клиент использует свой id и секрет, чтобы запросить у IDP подписанный JWT, конкретно “access_token”, содержащий утверждения о клиентском ID и ID арендатора IDP.
-
Клиент запрашивает доступ к ресурсу и включает этот JWT в качестве токена-переносчика.
-
Ресурсу не нужно делать внешний вызов к IDP, так как ресурс был предоставлен данными JWKS IDP и может сразу же прочитать JWT и увидеть его как легитимный, так как он содержит client_id и tenant ID (при условии, что другие обычные утверждения о времени и т. д. тоже соблюдены), и ресурс может подтвердить, что подпись на JWT принадлежит IDP, настроенному как его сервер JWKS. В этот момент ресурс может доверять, что запрашивающий является клиентским ID в утверждении JWT.
Вот и все, я еще не встречал такой тип развертывания, кажется, он безопасен и надежен так же, как и другой, с одним исключением, что отзыва не возможны, что можно было бы смягчить короткими сроками действия. Есть ли у того, что я описал, собственное название? Или это используется где-то?
Да, вы уже использовали это название! То, о чем вы говорите, это валидация JWKS, и это альтернатива интроспекции.
Большинство библиотек OAuth поддерживают этот метод из коробки. Например, вот статья Baeldung, демонстрирующая валидацию JWKS с использованием Spring Security.
Ответ или решение
Аутентификация идентификационного токена OIDC с использованием JWKS вместо introspection токена
Введение
В современном цифровом мире, где обмен данными между сервисами происходит на бесчисленном количестве уровней, эффективность и безопасность аутентификации играют ключевую роль. Часто организации сталкиваются с необходимостью реализовать протоколы аутентификации, при этом одним из распространенных подходов является использование OpenID Connect (OIDC) в сочетании с ресурсами, предоставляющими доступ на основе токенов. В этом контексте заслуживает внимания метод аутентификации с использованием JWKS (JSON Web Key Set), который предоставляет альтернативу традиционному подходу с использованием токен introspection.
Описание проблемы
Вами было описано распространенное взаимодействие между клиентом и ресурсом, где клиент запрашивает токен доступа у IDP (Identity Provider), а затем направляет этот токен в запросах к ресурсам, которые, в свою очередь, проводят валидацию токена, используя механизм token introspection. Однако данный подход требует от ресурса выполнения дополнительных внешних вызовов, что может стать узким местом в производительности и повысить зависимость от доступности IDP.
Вы предложили альтернативный подход, в рамках которого ресурс может валидировать токен непосредственно, без обращения к IDP, используя предоставленный набор JWKS. Это, безусловно, интересная и эффективная схема, особенно в рамках межсервисного общения в режиме "демон-к-действию".
Основные этапы использования JWKS
Ваши шаги по процессу аутентификации с использованием JWT и JWKS мною полностью поддерживаются. Давайте рассмотрим их подробнее:
-
Запрос токена у IDP: Клиент, представляющий собой "демон", использует свои идентификационные данные (client_id и secret) для запроса токена доступа от IDP. Запрашиваемый токен – это подписанный JWT, в который могут входить такие сведения, как client_id и tenant_id.
-
Использование токена для доступа к ресурсам: Клиент делает запрос к ресурсу, присоединяя полученный JWT в виде bearer-токена.
-
Валидация токена на ресурсе: Ресурс, в свою очередь, уже имеет доступ к JWKS. Он может проверить подпись JWT с использованием публичного ключа, представленного в JWKS, что позволяет удостовериться, что JWT был сгенерирован именно доверенным IDP. При этом ресурс также проверяет срок действия токена и его формат.
Таким образом, ресурс избавляется от необходимости внешних вызовов для валидации токена и сразу же может доверять содержимому JWT, что делает взаимодействие более быстрым и эффективным.
Преимущества и недостатки
Основные преимущества использования JWKS:
- Повышение производительности: Исключение внешних вызовов к IDP снижает задержку и нагрузку на системы.
- Меньшая сложность архитектуры: Упрощает процесс аутентификации, так как исключает этап валидирования токена через идентификационный поставщик.
- Устойчивость к недоступности IDP: В случае проблем IDP запросы к ресурсам все равно могут обрабатываться.
Однако, как вы правильно отметили, присутствуют и недостатки:
- Нет механизма отзыва: Если токен скомпрометирован или нужно отозвать доступ клиента, у вас не будет возможности сделать это в реальном времени, поэтому важно установить короткий срок действия токена.
Заключение
Предложенная вами схема действительно является проверенным подходом, известным как валидация JWKS. Этот метод, особенно в контексте «демон-к-действию», нашел применение в рядах сервисов, где минимизация зависимостей и повышение производительности являются критически важными аспектами.
В заключение, важно помнить, что валидация JWKS обычно предпочитается в сценариях, где отсутствует необходимость в функционале отзыва (revocation) токенов и когда скорость обработки запросов имеет наивысший приоритет. Рекомендуется всегда учитывать контекст применения и возможные риски.