Azure AD - мультитенант с потоком предоставления кода службы 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).

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

Answer 1

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

1. Принципал службы создан для этого в своем арендаторе
2. Разрешения, запрошенные приложением, предоставляются в этом арендаторе

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

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

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

Answer 2

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

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

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