Поток аутентификации Сервис к сервису Microsoft Graph и бронирования API

Question

Я создаю пользовательское мобильное приложение, которое имеет клиент, пользовательский бэкэнд-сервер (я создаю) и взаимодействует с множеством других API. Один из этих API-интерфейсов - это заказы Microsoft.

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

Я могу получить сервер access_token на сервер с этими разрешениями. (Я уже предоставил «все разрешения» для этого приложения в Azure AD).

"roles": [
"Calls.JoinGroupCall.All",
"OnlineMeetings.Read.All",
"OnlineMeetings.ReadWrite.All",
"Application.ReadWrite.OwnedBy",
"Calendars.Read",
"People.Read.All",
"Application.ReadWrite.All",
"Calls.InitiateGroupCall.All",
"Directory.ReadWrite.All",
"Calls.JoinGroupCallAsGuest.All",
"Sites.Read.All",
"Sites.ReadWrite.All",
"Sites.Manage.All",
"Files.ReadWrite.All",
"Directory.Read.All",
"User.Read.All",
"Calendars.ReadWrite",
"Mail.Send",
"ProgramControl.Read.All",
"ProgramControl.ReadWrite.All",
"Calls.Initiate.All"

]

Это разрешения от декодированного токена. Когда я иду звонить в API бронирования, я получаю 401.

Однако я могу использовать этот токен для доступа к различным конечным точкам графа без проблем.

Отмечу, что я могу совершать успешные звонки в API бронирования через Graph Explorer с моей учетной записью, не связанной с этим «Приложением в Azure AD».

Требуется ли для этого ресурса в Azure AD лицензия на бронирование? Это вообще возможно S2S?

Есть ли другие способы обойти это без учетных данных пользователя?

Спасибо.

Answer 1

Так что я потратил больше недели, пытаясь решить эту проблему из-за кошмара MS Doc. Я только отправляю сообщения, чтобы помочь другим!

Бронирования пока не поддерживают сервис. Так что, если вы не хотите реализовывать это без физического входа пользователя, IE. Если у вас есть специальные учетные данные администратора бронирования, вы должны жестко закодировать учетные данные клиентов.

Я нашел свой ответ здесь https://stackoverflow.com/a/49814924/9105626

Answer 2

Microsoft Bookings API пока не поддерживает «Разрешения приложений».

Только доступные разрешения - это «Делегированные разрешения», что означает, что ваш токен должен быть получен в контексте зарегистрированного пользователя.

Вот два источника документации Microsoft, с которыми я столкнулся:

• Справочник по разрешениям для Microsoft Graph - см. Раздел «Разрешения на бронирование».

  

• Образцы заказов Microsoft

Я знаю, что вы упоминаете аутентификацию между серверами, используя секрет клиента.AFAIK, этот случай НЕ будет работать напрямую, потому что clientId и clientSecret предоставляют только идентификатор приложения (которому не могут быть назначены какие-либо разрешения, потому что для этого API нет соответствующих разрешений приложения).

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

var authenticationContext = new AuthenticationContext("https://login.microsoftonline.com/common/");

var authenticationResult = await authenticationContext.AcquireTokenAsync(
  "https://graph.microsoft.com/",
  clientApplication_ClientId,
  clientApplication_RedirectUri,
  new PlatformParameters(PromptBehavior.RefreshSession));

// The results of this call are sent as the Authorization header of each HTTPS request to Graph.
var authorizationHeader = authenticationResult.CreateAuthorizationHeader();

Предложения по созданию этого сценария

1. от имени потока

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

   Вот пример кода, который показывает именно это с собственным приложением (WPF) и SPA.В вашем случае просто замените приложение WPF на мобильное клиентское приложение для понимания целей, а остальная часть сценария станет очень похожей.

   Вызов нижестоящего веб-API из веб-API с помощью Azure AD

   

2. Грант ROPC (не рекомендуется)

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

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

   Во всех практических целях следует избегать ROPC как можно дольше.Вы можете найти ту же рекомендацию в самой документации ADAL и нескольких других документациях от Microsoft или даже вообще об OAuth 2.0.