Вопрос или проблема
У меня есть микросервисная система с провайдером идентификации OpenId Connect, реализованная с помощью IdentityServer4.
У меня есть одна специальная (очень общая) служба, которой необходимо взаимодействовать со всеми другими службами, даже с теми, которые будут разработаны в будущем. Это серверное взаимодействие без участия пользователя, поэтому моя специальная служба запрашивает токены через Client Credentials Flow. Я хотел бы предоставить этой службе “все области, зарегистрированные у этого провайдера идентификации”. Как разработчик, я не знаю, какие области будут существовать. Поэтому я не могу указать их в качестве AllowedScopes при регистрации клиента.
Мои вопросы:
- Согласно OIDC, можно ли зарегистрировать клиента, не указывая явно разрешенные области, а просто сказав “все существующие (и будущие) области”? Я проверил спецификацию OIDC, но не нашел правила, которое бы утверждало, что вы должны (или должны) указывать разрешенные области. Я нашел несколько постов, предлагающих, что области не так важны в Client Credentials Flow, например, здесь.
- Если это соответствует OIDC, предлагает ли IdentityServer4 такую возможность или точку расширения?
OIDC не определяет области или грант клиентских учетных данных. Оба определены в OAuth 2.0 в RFC 6749.
Предоставление областей в любом случае является необязательным:
Если клиент опускает параметр scope при запросе авторизации, сервер авторизации ДОЛЖЕН либо обработать запрос, используя предопределенное значение по умолчанию, либо отвергнуть запрос, указывая на недействительную область. Сервер авторизации ДОЛЖЕН документировать свои требования к областям и значение по умолчанию (если оно определено).
Кроме того, это также является необязательным в гранте клиентских учетных данных:
scope
НЕОБЯЗАТЕЛЬНО. Область запроса на доступ, как описано в Разделе 3.3.
Тестирование с демо-версией IdentityServer4, при опущении параметра scope приводит к получению токена с несколькими областями. Похоже, что IS4 использует значение по умолчанию в этом случае (возможно, все области, предоставленные приложению).
- Да, существует точка расширения. IdentityServer4 (а также другие версии) предоставляет возможность создания пользовательских грантов. https://identityserver4.readthedocs.io/en/latest/topics/extension_grants.html
Вы можете создать свой собственный пользовательский грант, который предоставит все существующие области в вашем приложении во время выполнения.
Ответ или решение
Ваш вопрос о том, можно ли настроить клиента в OpenID Connect (OIDC) с использованием потока Client Credentials без явного указания разрешенных областей, имеет несколько аспектов, которые стоит рассмотреть.
- Согласованность с OIDC и OAuth 2.0: В рамках спецификации OIDC и OAuth 2.0 действительно не требуется явно указывать разрешенные области (scopes) для клиента, который использует поток Client Credentials. Как указано в RFC 6749, Раздел 3.3, если клиент опускает параметр scope в запросе, сервер авторизации должен либо использовать заранее определенное значение по умолчанию, либо вернуть ошибку. При этом, как правило, документация сервера авторизации должна пояснять, какие есть требования к scope и какое значение по умолчанию используется.
Также в Разделе 4.4.2 указывается, что параметр scope является необязательным в потоке Client Credentials. Это означает, что вы можете запрашивать токен доступа без указания scope, и в большинстве случаев будет возвращаться токен, который включает все области, предоставленные вашему приложению по умолчанию.
Таким образом, в соответствии с приведенными спецификациями, теоретически не противоречит требованиям OIDC и OAuth 2.0 зарегистрировать клиента без явно указанных разрешенных областей. Однако следует отметить, что это поведение зависит от реализации конкретного сервера авторизации.
- Возможности IdentityServer4: IdentityServer4 позволяет расширять функциональность через создание пользовательских потоков аутентификации. Вы можете реализовать собственный кастомный поток, который будет предоставлять доступ ко всем существующим областям (scopes) вашего приложения во время выполнения.
Как указано в документации IdentityServer4, вы можете создать пользовательский грант, который в соответствии с требованиями вашей архитектуры будет возвращать все доступные области. Это позволяет избежать необходимости явно указывать их на этапе регистрации клиента, что особенно полезно в условиях постоянного изменения и добавления новых сервисов и областей.
Заключение:
Рекомендуется тщательно продумать архитектуру и безопасность вашего приложения. Если у вашей "специальной" службы есть доступ ко всем областям, существует риск, что при недостаточной защите новые сервисы также могут быть скомпрометированы. Поэтому, несмотря на возможность настроить клиента без явного указания областей, разумно вводить определенные ограничения и контролировать доступ в зависимости от конкретных нужд вашего приложения.