Устранение неполадок проверки подлинности для единого входа в Teams

Дополнительные сведения см. в статье Использование Postman с API Microsoft Graph.

Дополнительные сведения см. в статье Песочница Graph.

Код должен сообщить клиенту (например, в тексте ответа 403 Forbidden), как обработать ошибку:

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

Чтобы обработать эту ошибку, серверный код должен отправить клиенту ответ 403 Forbidden. Следует записать ошибку в консоли или журнале.

1. Личный домен не добавляется в идентификатор Microsoft Entra. Чтобы добавить личный домен в Идентификатор Microsoft Entra и зарегистрировать его, выполните процедуру добавления личного доменного имени в идентификатор Microsoft Entra ID. Затем снова выполните действия, описанные в разделе Настройка области для маркера доступа .
2. Вы не вошли в систему с учетными данными администратора в клиенте Microsoft 365. Войдите в Microsoft 365 в качестве администратора.

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

Дополнительные сведения об URI идентификатора приложения см. в разделе Предоставление API.

На следующем рисунке показан пример сведений о приложении, настроенных в идентификаторе Microsoft Entra.

Убедитесь, что следующие значения совпадают между идентификатором Microsoft Entra, клиентским кодом и манифестом приложения:

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

• Секрет приложения. Секрет приложения, настроенный во внутренней части приложения, должен соответствовать учетным данным клиента в идентификаторе Microsoft Entra. Также проверьте, истек ли срок действия секрета клиента.

• URI идентификатора приложения. URI идентификатора приложения в коде и в файле манифеста приложения должен соответствовать URI идентификатора приложения в Microsoft Entra ID.

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

• Согласие администратора: если для какой-либо области требуется согласие администратора, проверьте, предоставлено ли пользователю согласие для конкретной области.

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

• Аудитория (aud): проверьте, правильно ли указан идентификатор приложения в маркере, как указано в идентификаторе Microsoft Entra.
• Идентификатор клиента (tid): проверьте правильность клиента, указанного в маркере.
• Удостоверение пользователя (preferred_username): проверьте, соответствует ли удостоверение пользователя имени пользователя в запросе маркера доступа области, к которому текущий пользователь хочет получить доступ.
• Scopes (scp): проверьте правильность области, для которой запрашивается маркер доступа, и как определено в идентификаторе Microsoft Entra.
• Microsoft Entra версии 1.0 или 2.0 (ver): проверьте правильность версии Microsoft Entra.

Для проверки маркера вы можете использовать JWT.

{​​ 
    "status": "<response code>", 
    "body": 
    {​​ 
        "id":"<unique Id>", 
        "connectionName": "<connection Name on the bot (from the OAuth card)>", 
        "failureDetail": "<failure reason if status code is not 200, null otherwise>" 
    }​​ 
}​​

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

1. Клиент начинает беседу с ботом, запуская сценарий OAuth.

2. Бот в ответ отправляет клиенту карточку OAuth.

3. Клиент перехватывает карточку OAuth перед отображением ее пользователю приложения. Он проверяет, содержит TokenExchangeResource ли он свойство.

4. Если свойство существует, клиент отправляет боту TokenExchangeInvokeRequest. Клиент должен иметь обменный токен для пользователя. Этот маркер должен быть маркером Azure AD версии 2, аудитория которого должна совпадать с свойством TokenExchangeResource.Uri .

5. Клиент отправляет боту действие вызова со следующим кодом:

   {
       "type": "Invoke",
       "name": "signin/tokenExchange",
       "value": 
       {
           "id": "<any unique Id>",
           "connectionName": "<connection Name on the skill bot (from the OAuth card)>",
           "token": "<exchangeable token>"
       }
   }
   

6. Бот обрабатывает TokenExchangeInvokeRequest и возвращает TokenExchangeInvokeResponse клиенту. Клиент должен подождать, пока не получит TokenExchangeInvokeResponse.

   {
       "status": "<response code>",
       "body": 
       {
           "id":"<unique Id>",
           "connectionName": "<connection Name on the skill bot (from the OAuth card)>",
           "failureDetail": "<failure reason if status code is not 200, null otherwise>"
       }
   }
   

7. Если у TokenExchangeInvokeResponse есть status со значением 200, то клиент не показывает карточку OAuth. См. схему нормального потока. Для любого другого status или если объект TokenExchangeInvokeResponse не получен, клиент показывает пользователю карточку OAuth. См схему потока при отработке сбоя. Если возникли ошибки или какие-либо зависимости, такие как согласие пользователя, отсутствуют, это действие гарантирует, что поток единого входа переключится на обычный поток OAuthCard.

   Примечание.

   В веб-клиенте Teams запрос пароля не отображается, так как в браузере есть активный сеанс Microsoft Entra, который используется для проверки подлинности и получения маркера. В классическом клиенте Teams появится запрос пароля, так как в классическом клиенте нет сеанса Microsoft Entra для общего доступа, и ему предлагается войти в систему.