Поделиться через

Начало работы с API управления Office 365

  • Статья

При создании приложения, которое нуждается в доступе к таким защищенным службам, как интерфейсы API управления Office 365, вам необходимо обеспечить возможность сообщать службе о наличии у приложения права на доступ к ней. API управления Office 365 используют Microsoft Entra ID для предоставления служб проверки подлинности, которые можно использовать для предоставления приложению прав на доступ к ним.

Этот процесс делится на четыре основных этапа.

  1. Зарегистрируйте приложение в Microsoft Entra ID. Чтобы разрешить приложению доступ к API управления Office 365, необходимо зарегистрировать приложение в Microsoft Entra ID. Это позволяет создать удостоверение для приложения b задать уровни разрешений, необходимые ему для доступа к API.

  2. Получение согласия администратора клиента Office 365. Администратор клиента Office 365 должен явно дать согласие, чтобы приложение могло получать доступ к данным клиента при помощи API управления Office 365. Процесс предоставления согласия — это браузерный интерфейс, который требует от администратора клиента войти в пользовательский интерфейс Microsoft Entra согласия и просмотреть запрашиваемые приложением разрешения на доступ, а затем предоставить или отклонить запрос. После предоставления согласия пользовательский интерфейс перенаправляет пользователя обратно в приложение с помощью кода авторизации в URL-адресе. Приложение выполняет вызов между службами Microsoft Entra ID для обмена этим кодом авторизации на маркер доступа, который содержит сведения об администраторе клиента и приложении. ИД клиента необходимо извлечь из маркера доступа и сохранить для последующего использования.

  3. Запрос маркеров доступа из Microsoft Entra ID. Используя учетные данные приложения, настроенные в Microsoft Entra ID, приложение на постоянной основе запрашивает дополнительные маркеры доступа для клиента с согласием без необходимости дальнейшего взаимодействия с администратором клиента. Эти маркеры доступа называются маркерами только для приложений, потому что они не содержат сведения об администраторе клиента.

  4. Вызов API управления Office 365. Маркеры доступа только для приложений передаются интерфейсам API управления Office 365, чтобы выполнить проверку подлинности и авторизацию приложения.

На приведенной ниже схеме показана последовательность предоставления согласия и запросов маркеров доступа.

Поток автоматизации запуска API-интерфейсов управления

Важно!

Чтобы получить доступ к данным с помощью API действий управления Office 365, требуется включить ведение единого журнала аудита для организации Office 365. Это выполняется путем включения журнала аудита Office 365. Инструкции см. в статье Включение и отключение поиска в журнале аудита Office 365.

Включение ведения единого журнала аудита не требуется, если вы используете только API служебных сообщений Office 365.

Регистрация приложения в Microsoft Entra ID

API управления Office 365 используют Microsoft Entra ID для обеспечения безопасной проверки подлинности для Office 365 данных клиента. Чтобы получить доступ к API управления Office 365, необходимо зарегистрировать приложение в Microsoft Entra ID и в рамках конфигурации указать уровни разрешений, необходимые приложению для доступа к API.

Предварительные требования

Чтобы зарегистрировать приложение в Microsoft Entra ID, вам потребуется подписка на Office 365 и подписка на Azure, связанная с вашей Office 365 подпиской. Для начала вы можете использовать пробные подписки на Office 365 и Azure. Дополнительные сведения см. в статье Вопросы и ответы о программе для разработчиков Office 365.

Используйте портал Azure для регистрации приложения в Microsoft Entra ID

После создания клиента Майкрософт с соответствующими подписками вы можете зарегистрировать приложение в Microsoft Entra ID.

  1. Войдите на портал Azure, используя учетные данные клиента Майкрософт, у которого есть нужная вам подписка на Office 365. Вы также можете получить доступ к порталу Azure по ссылке в левой области навигации в Центре администрирования Microsoft 365.

  2. В области навигации слева выберите Microsoft Entra ID (1).

    Главная страница портала Azure

  3. На странице Microsoft Entra ID выберите Регистрация приложений (2), а затем — Новая регистрация (3).

    страница Регистрация приложений в Microsoft Entra ID

  4. На странице Регистрация приложений выберите Новая регистрация.

    Для начала регистрации приложения появится новая страница.

  5. На странице Регистрация приложения выполните следующие действия.

    Процесс регистрации приложения

    1. Присвойте имя приложению.

    2. Выберите, кто может использовать приложение и получать доступ к API.

    3. При необходимости укажите URL-адрес для перенаправления пользователей после проверки подлинности.

  6. Нажмите Зарегистрировать, чтобы зарегистрировать новое приложение.

Настройка свойств приложения в Microsoft Entra ID

Теперь, когда приложение зарегистрировано, необходимо указать несколько важных свойств, которые определяют, как приложение работает в Microsoft Entra ID и как администраторы клиента будут предоставлять согласие на предоставление приложению доступа к данным с помощью API управления Office 365.

Дополнительные сведения о Microsoft Entra конфигурации приложений в целом см. в разделе Свойства объекта приложения.

  1. Идентификатор клиента. Это значение автоматически создается Microsoft Entra ID. Приложение будет использовать это значение при запросе согласия у администраторов клиента и при запросе маркеров только для приложений у Microsoft Entra ID.

  2. Приложение является мультитенантным. Для этого свойства необходимо задать значение Да, чтобы администраторы клиентов могли разрешать приложению доступ к своим данным с помощью API управления Office 365. Если для этого свойства выбрано значение Нет, то приложение сможет получать доступ только к данным вашего клиента.

  3. URL-адрес ответа. Это URL-адрес, на который перенаправляется администратор клиента, после того как приложению дается согласие на доступ к данным с помощью API управления Office 365. При необходимости можно задать несколько URL-адресов ответа. Azure автоматически задает первый в соответствии с URL-адресом для входа, указанным при создании приложения, но при необходимости это значение можно изменить.

Не забывайте нажимать кнопку Сохранить после внесения каких-либо изменений в эти свойства.

Создание нового ключа для приложения

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

  1. На странице Microsoft Entra ID в портал Azure выберите Регистрация приложений, а затем выберите свое приложение.

    Выбор только что зарегистрированного приложения

  2. После отображения страницы приложения нажмите Сертификаты и секреты (1) в левой области. На этой странице можно отправить сертификаты и создать секреты клиента (2).

    Страница

  3. На странице Сертификаты и секреты (1) нажмите Новый секрет клиента (2), введите описание и выберите срок действия для ключа (3), а затем щелкните Добавить (4).

    Создание секрета клиента

  4. После создания секрета клиента значение отображается в разделе Секреты клиента (2). Щелкните значок буфера обмена (3), чтобы скопировать значение секрета клиента.

    Копирование значения секрета клиента в буфер обмена и сохранение его для дальнейшего использования

    Важно!

    Azure показывает значение секрета клиента только в момент его создания. Вернуться на эту страницу и получить значение секрета клиента позже будет невозможно. Не забудьте скопировать его и сохранить в безопасном расположении, чтобы использовать его позже.

Настройка сертификата X.509 для поддержки вызовов между службами

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

Дополнительные сведения см. в статье Вызовы между службами с использованием учетных данных клиентов.

Необходимо настроить сертификат X.509 с приложением, чтобы он использовался в качестве учетных данных клиента при запросе маркеров доступа только для приложений из Microsoft Entra ID. Этот процесс состоит из двух этапов:

  • Получение сертификата X.509. Вы можете использовать сертификат, выданный доверенным центром сертификации, или самозаверяющий сертификат.

  • Измените манифест приложения, включающий отпечаток и открытый ключ сертификата.

В приведенных ниже инструкциях показано, как использовать Visual Studio или средство makecert из пакета Windows SDK, чтобы создать самозаверяющий сертификат и экспортировать открытый ключ в файл с кодировкой base64.

  1. В командной строке выполните указанную ниже команду.

     makecert -r -pe -n "CN=MyCompanyName MyAppName Cert" -b 03/15/2015 -e 03/15/2017 -ss my -len 2048

    Примечание.

    Создавая сертификат X.509, убедитесь, что длина ключа составляет как минимум 2048. Ключи с меньшей длиной не принимаются как допустимые.

  2. Откройте оснастку MMC для сертификатов и подключитесь к своей учетной записи пользователя.

  3. Найдите новый сертификат в папке "Личные" и экспортируйте открытый ключ в файл с кодировкой base64 (например, mycompanyname.cer). Приложение будет использовать этот сертификат для взаимодействия с Microsoft Entra ID, поэтому убедитесь, что вы также сохраните доступ к закрытому ключу.

    Примечание.

    Вы можете использовать Windows PowerShell, чтобы извлечь отпечаток и открытый ключ с кодировкой base64. Другие платформы предоставляют подобные средства для получения свойств сертификатов.

  4. В командной строке Windows PowerShell введите и выполните следующую команду:

     $cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
 $cer.Import("mycer.cer")
 $bin = $cer.GetRawCertData()
 $base64Value = [System.Convert]::ToBase64String($bin)
 $bin = $cer.GetCertHash()
 $base64Thumbprint = [System.Convert]::ToBase64String($bin)
 $keyid = [System.Guid]::NewGuid().ToString()

  5. Сохраните значения $base64Thumbprint, $base64Value и $keyid для использования при обновлении манифеста приложения на последующих этапах.

    Используя значения, извлеченные из сертификата, и созданный идентификатор ключа, необходимо обновить манифест приложения в Microsoft Entra ID.

  6. На портале Azure перейдите в раздел Регистрация приложений>Все приложения, выберите свое приложение и нажмите Манифест в левой области.

  7. В верхней панели навигации на странице Манифест (1) нажмите Скачать (2).

    Скачивание манифеста для его изменения

  8. Откройте скачанный манифест в редакторе и замените пустое свойство keyCredentials на следующий код JSON.

       "keyCredentials": [
     {
         "customKeyIdentifier" : "$base64Thumbprint_from_above",
         "keyId": "$keyid_from_above",
         "type": "AsymmetricX509Cert",
         "usage": "Verify",
         "value": "$base64Value_from_above"
     }
 ],

    Примечание.

    Свойство KeyCredentials представляет собой коллекцию, что позволяет отправлять несколько сертификатов X.509 для сценариев переключения или удалять сертификаты с целью компромисса.

  9. Сохраните изменения и отправьте обновленный манифест, выбрав элемент Управление манифестом на панели команд, нажав Отправить манифест и выбрав обновленный файл манифеста.

Указание разрешений, необходимых приложению для доступа к API управления Office 365

Наконец, вам нужно точно указать, какие разрешения требует ваше приложение от API управления Office 365. Для этого следует предоставить приложению доступ к API управления Office 365, а затем задать нужные разрешения.

  1. На портале Azure перейдите в раздел Регистрация приложений>Все приложения, выберите свое приложение и нажмите Разрешения API (1) в левой области. Щелкните Добавить разрешение (2) для отображения всплывающей страницы Запрос разрешений API (3).

    Добавление разрешений API

  2. На вкладке Интерфейсы API Майкрософт выберите API управления Office 365 (4).

    Выбор API управления Office 365 на вкладке

  3. На всплывающей странице выберите следующие типы разрешений (3), требующиеся вашему приложению, и нажмите Добавить разрешения

    Выбор типов разрешений для приложения

    1. Делегированные разрешения. Позволяет клиентскому приложению выполнять операции от имени вошедшего пользователя, например чтение писем или изменение профиля пользователя.

    2. Разрешения приложений. Разрешения, позволяющие клиентскому приложению самостоятельно выполнять проверку подлинности без взаимодействия с пользователем или его согласия, например для приложения, используемого фоновой службой или управляющими программами.

  4. Теперь API управления Office отображаются в списке приложений, для которых вашему приложению требуются разрешения. В разделах Разрешения приложений и Делегированные разрешения при необходимости выберите разрешения, требующиеся приложению. Дополнительные сведения о каждом разрешении представлены в справочнике по определенному API.

    Разрешения API для приложения

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

Теперь, когда для приложения настроены разрешения, необходимые для использования API управления Office 365, администратор клиента должен явно предоставить приложению эти разрешения, чтобы получать доступ к данным клиента с помощью интерфейсов API. Чтобы предоставить согласие, администратор клиента должен войти в Microsoft Entra ID с помощью следующего специально созданного URL-адреса, чтобы просмотреть запрошенные разрешения приложения. Это действие не требуется при использовании API для доступа к данным из собственного клиента.

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id={your_client_id}&redirect_uri={your_redirect_url }

URL-адрес перенаправления должен соответствовать или быть вложенным путем в одном из URL-адресов ответа, настроенных для приложения в Microsoft Entra ID.

Пример:

https://login.windows.net/common/oauth2/authorize?response_type=code&resource=https%3A%2F%2Fmanage.office.com&client_id=2d4d11a2-f814-46a7-890a-274a72a7309e&redirect_uri=http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F

Вы можете тестировать URL-адрес согласия, вставив его в браузере и выполнив вход с использованием учетных данных администратора Office 365 для того клиента, который использовался при регистрации приложения. Вы увидите запрос на предоставление приложению разрешения на использование API управления Office.

Страница согласия на предоставление разрешений

Нажав кнопку Принять, вы перейдете на указанную страницу, а в строке запроса будет указан код.

Пример:

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

Приложение использует этот код авторизации для получения маркера доступа от Microsoft Entra ID, из которого можно извлечь идентификатор клиента. Когда вы получите и сохраните идентификатор клиента, администратору клиента больше не потребуется входить для получения последующих маркеров доступа.

Запрос маркеров доступа из Microsoft Entra ID

Существует два метода запроса маркеров доступа из Microsoft Entra ID:

  • Поток предоставления кода авторизации включает предоставление явного согласия администратором клиента, в результате чего приложению возвращается код авторизации. Затем приложение обменивает код авторизации на маркер доступа. Этот способ необходим, чтобы получить первоначальное согласие, нужное приложению для доступа к данным клиента с помощью API, а этот первый маркер доступа необходим для получения и хранения идентификатора клиента.

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

Запрос маркера доступа с помощью кода авторизации

Когда администратор клиента предоставит согласие, приложение получает код авторизации в качестве параметра строки запроса, когда Microsoft Entra ID перенаправляет администратора клиента на указанный URL-адрес.

http://www.mycompany.com/myapp/?code=AAABAAAAvPM1KaPlrEqdFSB...

Приложение создает HTTP REST POST для Microsoft Entra ID для обмена кодом авторизации на маркер доступа. Так как идентификатор клиента пока не известен, запрос POST будет адресован "общей" конечной точке, идентификатор клиента для которой не включен в URL-адрес:

https://login.windows.net/common/oauth2/token

Текст запроса POST содержит следующие данные:

resource=https%3A%2F%2Fmanage.office.com&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&code= AAABAAAAvPM1KaPlrEqdFSB...

Пример запроса

POST https://login.windows.net/common/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 944

resource=https%3A%2F%2Fmanage.office.com&client_id=a6099727-6b7b-482c-b509-1df309acc563 &redirect_uri= http%3A%2F%2Fwww.mycompany.com%2Fmyapp%2F &client_secret={your_client_key}&grant_type=authorization_code&code=AAABAAAAvPM1KaPlrEqdFSB...

Текст отклика будет включать ряд свойств, в том числе маркер доступа.

Пример отклика

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 3265

{"expires_in":"3599","token_type":"Bearer","scope":"ActivityFeed.Read ActivityReports.Read ServiceHealth.Read","expires_on":"1438290275","not_before":"1438286375","resource":"https://manage.office.com","access_token":"eyJ0eX...","refresh_token":"AAABAAA...","id_token":"eyJ0eXAi..."}

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

Пример маркера

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1427246416,
  "nbf": 1427246416,
  "exp": 1427250316,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "amr": [
    "pwd"
  ],
  "oid": "1cef1fdb-ff52-48c4-8e4e-dfb5ea83d357",
  "upn": "admin@contoso.onmicrosoft.com",
  "puid": "1003BFFD8EC47CA6",
  "sub": "7XpD5OWAXM1OWmKiVKh1FOkKXV4N3OSRol6mz1pxxhU",
  "given_name": "John",
  "family_name": "Doe",
  "name": "Contoso, Inc.",
  "unique_name": "admin@contoso.onmicrosoft.com",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1",
  "scp": "ActivityFeed.Read ServiceHealth.Read",
  "acr": "1"
}

Запрос маркера доступа с помощью учетных данных клиента

После того как идентификатор клиента будет известен, приложение может выполнять вызовы службы к Microsoft Entra ID для запроса дополнительных маркеров доступа по истечении срока их действия. Эти маркеры содержат сведения только о запрашивающем приложении. В них нет данных об администраторе, который изначально дал согласие. Для вызовов между службами требуется, чтобы приложение использовало сертификат X.509 для создания клиентского утверждения в виде токена носителя JWT с кодировкой base64 и подписью SHA256.

При разработке приложения в .NET можно использовать библиотеку проверки подлинности Microsoft (MSAL) для создания утверждений клиента. На других платформах разработки должны быть доступны похожие библиотеки.

Незакодированный токен JWT состоит из заголовка и полезных данных с указанными ниже свойствами.

HEADER:

{
  "alg": "RS256",
  "x5t": "{thumbprint of your X.509 certificate used to sign the token",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/{tenantid}/oauth2/token",
  "iss": "{your app client ID}",
  "sub": "{your app client ID}",
  "jti": "{random GUID}",
  "nbf": "{epoch time, before which the token is not valid}",
  "exp": "{epoch time, after which the token is not valid}"
}

Пример токена JWT

HEADER:

{
  "alg": "RS256",
  "x5t": "YyfshJC3rPQ-kpGo5dUaiY5t3iU",
}

PAYLOAD:

{
  "aud": "https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token",
  "iss": "a6099727-6b7b-482c-b509-1df309acc563",
  "sub": "a6099727-6b7b-482c-b509-1df309acc563",
  "jti": "0ce254c4-81b1-4a2e-8436-9a8c3b49dfb9",
  "nbf": 1427248048,
  "exp": 1427248648,
}

Затем утверждение клиента передается Microsoft Entra ID в рамках вызова между службами для запроса маркера доступа. Запрашивая маркер доступа с помощью учетных данных клиента, используйте запрос HTTP POST к конечной точке определенного клиента, где ранее извлеченный и сохраненный идентификатор клиента внедряется в URL-адрес.

https://login.windows.net/{tenantid}/oauth2/token

Текст запроса POST содержит следующие данные:

resource=https%3A%2F%2Fmanage.office.com&client_id={your_app_client_id}&grant_type=client_credentials&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion={encoded_signed_JWT_token}

Пример запроса

POST https://login.windows.net/41463f53-8812-40f4-890f-865bf6e35190/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.windows.net
Content-Length: 994

resource=https%3A%2F%2Fmanage.office.com&client_id= a6099727-6b7b-482c-b509-1df309acc563&grant_type=client_credentials &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Ill5ZnNoSkMzclBRLWtwR281ZFVhaVk1dDNpVSJ9.eyJhdWQiOiJodHRwczpcL1wvbG9naW4ud2luZG93cy5uZXRcLzQxNDYzZjUzLTg4MTItNDBmNC04OTBmLTg2NWJmNmUzNTE5MFwvb2F1dGgyXC90b2tlbiIsImV4cCI6MTQyNzI0ODY0OCwiaXNzIjoiYTYwOTk3MjctNmI3Yi00ODJjLWI1MDktMWRmMzA5YWNjNTYzIiwianRpIjoiMGNlMjU0YzQtODFiMS00YTJlLTg0MzYtOWE4YzNiNDlkZmI5IiwibmJmIjoxNDI3MjQ4MDQ4LCJzdWIiOiJhNjA5OTcyNy02YjdiLTQ4MmMtYjUwOS0xZGYzMDlhY2M1NjMifQ.vfDrmCjiXgoj2JrTkwyOpr-NOeQTzlXQcGlKGNpLLe0oh4Zvjdcim5C7E0UbI3Z2yb9uKQdx9G7GeqS-gVc9kNV_XSSNP4wEQj3iYNKpf_JD2ikUVIWBkOg41BiTuknRJAYOMjiuBE2a6Wyk-vPCs_JMd7Sr-N3LiNZ-TjluuVzWHfok_HWz_wH8AzdoMF3S0HtrjNd9Ld5eI7MVMt4OTpRfh-Syofi7Ow0HN07nKT5FYeC_ThBpGiIoODnMQQtDA2tM7D3D6OlLQRgLfI8ir73PVXWL7V7Zj2RcOiooIeXx38dvuSwYreJYtdphmrDBZ2ehqtduzUZhaHL1iDvLlw

Отклик будет таким же, как раньше, но свойства токена будут другими, так он не содержит свойства администратора, давшего согласие.

Пример отклика

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 1276

{"token_type":"Bearer","expires_in":"3599","expires_on":"1431659094","not_before":"1431655194","resource":"https://manage.office.com","access_token":"eyJ0eXAiOiJKV1QiL..."}

Пример маркера доступа

{
  "aud": "https://manage.office.com",
  "iss": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "iat": 1431655194,
  "nbf": 1431655194,
  "exp": 1431659094,
  "ver": "1.0",
  "tid": "41463f53-8812-40f4-890f-865bf6e35190",
  "roles": [
    "ServiceHealth.Read",
    "ActivityFeed.Read"
  ],
  "oid": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "sub": "67cb0334-e242-4783-8028-0f39132fb5ad",
  "idp": "https://sts.windows.net/41463f53-8812-40f4-890f-865bf6e35190/",
  "appid": "a6099727-6b7b-482c-b509-1df309acc563",
  "appidacr": "1"
}

Создание приложения

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

  • Предоставление согласия. Чтобы получить согласие от клиентов, необходимо направить их в браузере на веб-сайт Microsoft Entra, используя специально созданный URL-адрес, описанный ранее, и у вас должен быть веб-сайт, на который Microsoft Entra ID будет перенаправлять администратора после предоставления согласия. Этот сайт должен извлекать код авторизации из URL-адреса и запрашивать с его помощью маркер доступа, из которого можно получить идентификатор клиента.

  • Сохранение идентификатора клиента в системе. Это потребуется при запросе маркеров доступа из Microsoft Entra ID и при вызове API управления Office.

  • Управление маркерами доступа. Вам потребуется компонент, который по мере необходимости запрашивает маркеры доступа и управляет ими. Если приложение периодически вызывает интерфейсы API, оно может получать маркеры по требованию, а если оно непрерывно вызывает API для получения данных, можно запрашивать маркеры с определенным интервалом (например, каждые 45 минут).

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

  • Извлечение и хранение данных. Вам потребуется компонент, который получает данные для каждого клиента либо путем постоянного опроса, либо в ответ на уведомления веб-перехватчиков в зависимости от конкретного API.