Как я могу определить политики для своего API для двух типов токенов доступа, один с идентификатором (sub) и один без?

Question

Я использую IdentityServer4 через ASPNET Core и хочу, чтобы пользователи обращались к моему API как через веб-браузер через свои идентификационные данные (неявные и гибридные), так и программными клиентами (клиентские учетные данные). Я понимаю, все, что мне нужно сделать, это добавить AddIdentityServerAuthentication, и все готово. Однако это решает только проблему аутентификации, а не авторизацию.

Авторизация:

В ASPNET Core вы можете использовать только аутентификацию на основе ролей (или аналогичные права доступа PolicyServer), но только если у вас есть удостоверение с утверждениями о роли, не работает для учетных данных клиента. Так что это приводит нас к необходимости обеспечения безопасности по ролям или политикам И по областям. Как я могу это сделать?

• У вас не может быть нескольких политик, если они есть, они оба должны пройти.
• У вас не может быть нескольких схем авторизации, потому что мой вызов AddIdentityServerAuthentication должен будет использовать одни и те же полномочия, поэтому как IdentityServer4.AccessTokenValidation / JwtBearer узнает, какая схема вы вызываете, которую вы пытаетесь передать?
• Могут работать несколько требований, но вам нужно добавить дополнительные требования при условии, что вы имеете дело с токеном без идентификации. Как определить тип токена, с которым вы имеете дело? Безопасно ли просто сказать: «Если нет подпрограммы, это кредиты клиента».
• Должен ли я отменить этот дизайн и заставить поток кода устройства на моих пользователей? Посмотрите на az cli, он волшебным образом открывает браузер, и тогда вы можете начать писать сценарии для вашего сердца. IS4 поддерживает это с легкостью, особенно с verficationUrlComplete

Я думаю, что у меня есть работающий POC, но я далек от этого. https://gist.github.com/VictorioBerra/8c333a228c55d86a7c15f7f300284634

Это включает в себя, в основном, повторную реализацию обработчика требований к заявкам на область действия по умолчанию и обработчика требований разрешений для серверов политики. Но это единственный способ условно применить обработчики требований на основе типа токена.

Answer 1

Существует по крайней мере несколько способов решения проблемы аутентификации на основе ролей:

• Возможно, вы неправильно поняли, что у клиента могут быть role претензии в потоке client_credentials.
• Вы могли бы даже получить заявку sub, если бы внедрили поток client_credentials_custom и по существу привязали клиента к определенной учетной записи пользователя (представьте, что это учетная запись службы)