Azure AD - Multi-Tenant с сервисом Daemon и кодом авторизации Предоставление потока, может ли целевой арендатор генерировать client_secret?

Question

Я работаю с Azure AD через протокол OAuth 2.0, а также создаю приложение Service/Dameon для обработки процесса аутентификации для Microsoft Graph SDK. Для службы/демона я делаю HttpWebRequest и прохожу по client_id и client_secret, чтобы сгенерировать access_token, где я тогда могу предоставить Microsoft Graph SDK.

Я также успешно создал соответствующие службы основного к целевому арендатору, в котором администратор предоставившего разрешение приложения, используя код по Гранту авторизации потока. Затем приложение отображается в Overview -> Quick tasks -> Find an enterprise app, в пределах (portal.azure.com).

Мой вопрос заключается в том, что я могу использовать подход службы/демона, а также разрешать администратору из целевого арендатора разрешать приложение, которое позволит целевому арендатору создавать client_secret для передачи, который был бы уникальным для это арендатор?

Answer 1

Короткий ответ нет. Когда администратор соглашается ваше многопользовательское приложение:

1. участника-службы создается для него в их жильце
2. Разрешений запрошенных приложений предоставляется в том, что арендатор

Это означает, что ваше приложение может теперь аутентифицируются с его учетными данными клиента (id + secret) против их арендатора. Таким образом, те же самые ключи работают у всех утвержденных арендаторов.

Что это значит, ваше приложение может бесплатно получить токен доступа для любого из них в любой момент времени, независимо от того, кто входит в систему. Таким образом, он несет определенную ответственность за ваше приложение, чтобы данные были разделены.

Если вы получаете токен доступа от https://login.microsoftonline.com/company.com/oauth2/token, итоговый токен будет содержать идентификатор арендатора. И API-интерфейсы, такие как API-интерфейс Microsoft Graph, предоставят вам данные для этого арендатора с этим токеном. Поэтому ваше приложение должно обязательно использовать токен, у которого есть идентификатор арендатора, равный заявке на идентификатор арендатора пользователя.

Answer 2

Я бы сказал, что ответ juunas на 99% правильный. Короткий ответ в основном нет, и соображения, которые он упоминает, также прочны.

Но я считаю, что это было бы технически возможно при определенных соображениях. Когда администратор соглашается с вашей службой демон, в клиенте вашего клиента создается директор службы. Принципы обслуживания позволяют добавлять учетные данные, которые могут использоваться в качестве секретов клиента для каждого арендатора. Дело в том, что на самом деле нет способа добавить учетные данные для директора услуг программно из вашего приложения. Вам нужно будет заставить администратора запустить какой-нибудь скрипт, чтобы добавить новые учетные данные в службу поддержки арендатора.

Даже если вы прошли через все это, вам необходимо убедиться, что ваше обслуживание также изолировано на основе клиента/арендатора. С точки зрения безопасности, бессмысленно создавать секреты клиента для каждого арендатора, если у вашего уникального демона есть доступ ко всем секретам.