Токены доступа на платформе идентификации Microsoft

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

Маркеры доступа позволяют клиентам безопасно вызывать защищенные веб-API. Хотя клиентские приложения могут получать и использовать маркеры доступа, они должны рассматривать их как непрозрачные строки. Клиентское приложение не должно пытаться проверить маркеры доступа. Сервер ресурсов должен проверить маркер доступа, прежде чем принимать его в качестве подтверждения авторизации. Содержимое маркера предназначено только для API, что означает, что маркеры доступа должны рассматриваться как непрозрачные строки. Только для проверки и отладки разработчики могут декодировать JWT через jwt.ms или другой аналогичный сайт. Токены, которые получает API Microsoft, не всегда могут быть декодируемыми JWT.

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

Форматы токенов

На платформе удостоверений Майкрософт доступны две версии маркеров доступа: 1.0 и 2.0. Эти версии определяют утверждения, которые находятся в маркере, и гарантируют, что веб-API может управлять содержимым маркера.

Веб-API имеют одну из следующих версий, выбранных по умолчанию во время регистрации:

• версия 1.0 для приложений, доступных только для Microsoft Entra. В следующем примере показан маркер версии 1.0 (ключи изменяются и личные данные удаляются, что предотвращает проверку маркера):

  eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd
  

• 2.0 для приложений, поддерживающих учетные записи потребителей. В следующем примере показан маркер версии 2.0 (ключи изменяются и личные данные удаляются, что предотвращает проверку маркера):

  eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
  

Задайте версию для приложений, предоставив соответствующее значение requestedAccessTokenVersion параметру в манифесте приложения. Значения null и 1 соответствуют маркерам версии 1.0, а значение 2 — маркерам версии 2.0.

Владение токеном

Запрос маркера доступа включает в себя две стороны: клиент, который запрашивает маркер и ресурс (веб-API), принимающий маркер. Ресурс, для которого предназначен токен (его аудитория), определяется в утверждении aud токена. Клиенты используют маркер, но не должны распознавать его или пытаться проанализировать. Ресурсы принимают токен.

Платформа удостоверений Майкрософт поддерживает выдачу любой версии токена из любой конечной точки версии. Например, если значение requestedAccessTokenVersion равно 2, клиент, вызывающий конечную точку версии 1.0, чтобы получить маркер для этого ресурса, получает маркер доступа версии 2.0.

Ресурсы всегда владеют своими маркерами, использующими утверждение aud, и являются единственными приложениями, которые могут изменять данные этих маркеров.

Время существования маркера

Время существования маркера доступа по умолчанию — переменное. При выдаче платформа удостоверений Майкрософт назначает случайное значение от 60 до 90 минут (в среднем 75 минут) в качестве времени существования маркера доступа по умолчанию. Этот подход повышает отказоустойчивость службы за счёт распределения запросов на токены доступа во времени, что предотвращает ежечасные всплески трафика в Microsoft Entra ID.

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

Настройте время существования маркера доступа, чтобы управлять тем, как часто клиентское приложение завершает сеанс приложения по истечении срока действия, и как часто пользователю требуется проходить повторную аутентификацию (в автоматическом или интерактивном режиме). Чтобы переопределить вариант времени существования маркера доступа по умолчанию, используйте настраиваемое время существования маркера (CTL).

Примените вариацию времени существования токена по умолчанию к организациям с включённой функцией непрерывной оценки доступа (CAE). Примените вариант времени существования маркера по умолчанию, даже если организации используют политики CTL. Срок действия маркера по умолчанию для маркеров с длительным сроком действия составляет от 20 до 28 часов. Когда срок действия маркера доступа истекает, клиент должен использовать маркер обновления, чтобы автоматически получить новый маркер обновления и маркер доступа.

Организации, которые используют частоту входа с условным доступом (SIF) для определения частоты входа, не могут отменить вариацию времени существования маркера доступа по умолчанию. Когда организации используют SIF, время между запросами учетных данных для клиента может варьироваться от интервала частоты входа до времени существования токена, которое составляет от 60 до 90 минут, плюс интервал частоты входа.

Вот пример того, как изменение срока действия токена по умолчанию работает вместе с частотой входа в систему. Предположим, что организация устанавливает частоту входа в систему каждый час. Если из-за вариативности срока действия токена токен действует от 60 до 90 минут, фактический интервал между входами может составлять от 1 часа до 2,5 часов.

Если пользователь с токеном со сроком действия один час выполняет интерактивный вход в систему через 59 минут, запрос учетных данных не появляется, так как вход выполняется до достижения порогового значения SIF. Если новый токен имеет срок действия 90 минут, пользователь не увидит запрос на ввод учетных данных в течение следующих полутора часов. Во время попытки тихого обновления Microsoft Entra ID требуется запрос учетных данных, поскольку общая длительность сеанса превысила заданную частоту входа в систему, равную 1 часу. В этом примере разница во времени между запросами учетных данных из-за временного интервала SIF и вариации времени существования маркера составит 2,5 часов.

Проверить токены

Не все приложения должны проверять токены. Только в определённых сценариях приложения должны проверять токен:

• Веб-API должны проверять маркеры доступа, отправленные клиентом. Они должны принимать только те токены, которые содержат один из своих URI AppId в утверждении aud.
• Веб-приложения должны проверять маркеры идентификаторов, отправленные им с помощью браузера пользователя в гибридном потоке, прежде чем разрешать доступ к данным пользователя или устанавливать сеанс.

Если ни один из описанных выше сценариев не применяется, не требуется проверять маркер. Публичные клиенты, такие как нативные, настольные или одностраничные приложения, не получают преимуществ от проверки ID-токенов, поскольку приложение взаимодействует напрямую с поставщиком удостоверений (IDP), при котором защита SSL гарантирует действительность ID-токенов. Они не должны проверять маркеры доступа, так как они предназначены для проверки веб-API, а не клиента.

API-интерфейсы и веб-приложения должны проверять только маркеры c утверждением aud, соответствующим приложению. Другие ресурсы могут иметь собственные правила проверки токенов. Например, вы не можете проверить маркеры для Microsoft Graph в соответствии с этими правилами из-за их закрытого формата. Проверка и принятие токенов, предназначенных для другого ресурса, — это пример проблемы confused deputy.

Если приложению требуется проверить ID-токен или токен доступа, оно должно сначала проверить подпись токена и значение issuer на соответствие значениям в документе обнаружения OpenID.

Промежуточное ПО Microsoft Entra имеет встроенные возможности для проверки токенов доступа. Ознакомьтесь с примерами , чтобы найти его на соответствующем языке. Кроме того, доступно также несколько сторонних библиотек с открытым кодом для проверки JWT. Дополнительные сведения о библиотеках проверки подлинности и примерах кода см. в библиотеках проверки подлинности. Если веб-приложение или веб-API находится на ASP.NET или ASP.NET Core, используйте Microsoft.Identity.Web, который обрабатывает проверку.

Маркеры версии 1.0 и версии 2.0

• Когда ваше веб-приложение или API проверяет токен v1.0 (ver claim ="1.0"), ему необходимо считывать документ метаданных OpenID Connect из конечной точки v1.0 (https://login.microsoftonline.com/{example-tenant-id}/.well-known/openid-configuration), даже если для вашего веб-API настроен центр авторизации v2.0.
• Когда веб-приложение или API проверяет токен версии 2.0 (ver утверждение ="2.0"), необходимо считывать документ метаданных OpenID Connect из конечной точки версии 2.0 (https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration), даже если центр, настроенный для веб-API, является центром 1.0.

В следующих примерах предполагается, что приложение проверяет маркер доступа версии 2.0 (и поэтому ссылается на версии 2.0 документов и ключей метаданных OIDC). Просто удалите "/v2.0" в URL-адресе, если вы проверяете токены версии 1.0.

Проверка издателя

OpenID Connect Core гласит: «Идентификатор эмитента [...] ДОЛЖЕН в точности соответствовать значению утверждения iss (issuer).» Для приложений, использующих конечную точку метаданных для конкретного арендатора (например, https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/.well-known/openid-configuration или https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration), этого достаточно.

У Microsoft Entra ID есть версия документа, не зависящая от арендатора, доступная по адресу https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Эта конечная точка возвращает значение издателя https://login.microsoftonline.com/{tenantid}/v2.0. Приложения могут использовать эту конечную точку, не зависящую от арендатора, для проверки токенов от всех арендаторов со следующими изменениями:

1. Вместо того чтобы ожидать, что утверждение издателя в токене точно соответствует значению издателя из метаданных, приложение должно заменить {tenantid} значение в метаданных издателя идентификатором клиента, который является целевым объектом текущего запроса, а затем проверить точное соответствие.

2. Приложение должно использовать issuer свойство, возвращаемое из конечной точки ключей, чтобы ограничить область ключей.

   • Ключи, имеющие значение эмитента, например https://login.microsoftonline.com/{tenantid}/v2.0, могут использоваться с любым соответствующим эмитентом маркера.
   • Ключи со значением Issuer, например https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0, должны использоваться только с точным соответствием.

   Конечная точка ключа Microsoft Entra, не зависящая от арендатора (https://login.microsoftonline.com/common/discovery/v2.0/keys), возвращает документ следующего вида:

   {
     "keys":[
       {"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
       {"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
       {"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
     ]
   }
   

3. Приложения, использующие идентификатор клиента Microsoft Entra (tid) в качестве границы доверия вместо стандартного утверждения издателя, должны убедиться, что утверждение идентификатора клиента является идентификатором guid и совпадает с идентификатором издателя и клиента.

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

проверяют его подпись

JWT содержит три сегмента, разделенные символом . . Первый сегмент — это заголовок, второй — текст, а третий — подпись. Используйте сегмент подписи для проверки подлинности токена.

Идентификатор Microsoft Entra выдает маркеры, подписанные с помощью стандартных алгоритмов асимметричного шифрования, таких как RS256. Заголовок JWT содержит информацию о ключе и методе шифрования, используемых для подписания токена.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a",
  "kid": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a"
}

Утверждение alg указывает алгоритм, используемый для подписи маркера, а kid утверждение указывает конкретный открытый ключ, который использовался для проверки маркера.

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

Данные ключа подписи, необходимые для проверки подписи, см. в документе метаданных OpenID Connect по ссылке:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Ниже приведено описание документа метаданных.

• Это объект в формате JSON, который содержит несколько полезных блоков информации, таких как расположение различных конечных точек, необходимых для проверки подлинности OpenID Connect.
• Содержит jwks_uri, который указывает местоположение набора открытых ключей, соответствующих закрытым ключам, используемым для подписи токенов. Документ веб-ключа JSON (JWK), который находится в jwks_uri, содержит все сведения об открытых ключах, используемые в конкретный момент времени. RFC 7517 описывает формат JWK. Приложение может использовать утверждение kid в заголовке JWT, чтобы выбрать из этого документа открытый ключ, соответствующий закрытому ключу, который использовался для подписи конкретного токена. Затем оно может выполнить проверку подписи с использованием правильного общедоступного ключа и указанного алгоритма.

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

Если в приложении есть пользовательские ключи подписывания в результате использования функции сопоставления утверждений, добавьте appid параметр запроса, содержащий идентификатор приложения. Для проверки используйте jwks_uri этот параметр, указывающий на сведения о ключе подписывания приложения. Например: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=00001111-aaaa-2222-bbbb-3333cccc4444 содержит jwks_uri из https://login.microsoftonline.com/{tenant}/discovery/keys?appid=00001111-aaaa-2222-bbbb-3333cccc4444.

Проверка издателя

Веб-приложения, проверяющие маркеры идентификатора, и веб-API, проверяющие маркеры доступа, должны проверять издателя токена (iss утверждение) на:

1. издатель, доступный в документе метаданных OpenID Connect, связанном с конфигурацией приложения (authority). Документ метаданных для проверки зависит от:
   • версия токена
   • учетные записи, поддерживаемые приложением.
2. идентификатор арендатора (tid утверждение) в токене,
3. издатель ключа подписывания.

Однотенантные приложения

OpenID Connect Core гласит: "Идентификатор эмитента [...] ДОЛЖЕН в точности совпадать со значением утверждения iss (issuer)." Это относится к приложениям, использующим конечную точку метаданных для конкретного арендатора, например https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration или https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration.

Однотенантные приложения — это приложения, которые поддерживают:

• Учетные записи в одном каталоге организации (example-tenant-id только): https://login.microsoftonline.com/{example-tenant-id}
• Только личные учетные записи Microsoft: https://login.microsoftonline.com/consumers (consumers — это псевдоним арендатора 9188040d-6c67-4c5b-b112-36a304b66dad)

Мультитенантные приложения

Идентификатор Microsoft Entra также поддерживает мультитенантные приложения. Поддержка этих приложений:

• Учетные записи в любом каталоге организации (любой каталог Microsoft Entra): https://login.microsoftonline.com/organizations
• Учетные записи в любом каталоге организации (любой каталог Microsoft Entra) и личных учетных записей Майкрософт (например, Skype, XBox): https://login.microsoftonline.com/common

Для этих приложений Microsoft Entra ID предоставляет не зависящие от клиента версии документа OIDC по адресам https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration и https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration соответственно. Эти эндпоинты возвращают значение issuer, которое представляет собой шаблон, параметризованный значением tenantid: https://login.microsoftonline.com/{tenantid}/v2.0. Приложения могут использовать эти конечные точки, не зависящие от арендатора, для проверки токенов из любого арендатора при соблюдении следующих условий:

• Проверка издателя ключа подписи
• Вместо того чтобы ожидать, что утверждение об издателе в токене будет в точности соответствовать значению издателя из метаданных, приложение должно заменить значение {tenantid} в метаданных издателя идентификатором клиента, на который направлен текущий запрос, а затем проверить точное совпадение значения утверждения tid в токене.
• Убедитесь, что утверждение tid является GUID, а утверждение iss имеет вид https://login.microsoftonline.com/{tid}/v2.0, где {tid} — это в точности утверждение tid. Эта проверка связывает арендатора с эмитентом, а также с областью действия ключа подписи, тем самым формируя цепочку доверия.
• Используйте tid запрос, когда находят данные, связанные с субъектом запроса. Другими словами, tid утверждение должно быть частью ключа, используемого для доступа к данным пользователя.

Проверка издателя ключа подписи

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

Документ с ключами и издатель ключа подписи

Как уже обсуждалось, из документа OpenID Connect ваше приложение получает доступ к ключам, используемым для подписи токенов. Он получает соответствующий документ ключей путем доступа к URL-адресу, предоставленному в свойстве jwks_uri документа OpenIdConnect.

 "jwks_uri": "https://login.microsoftonline.com/{example-tenant-id}/discovery/v2.0/keys",

Значение {example-tenant-id} может быть заменено GUID, доменным именем или общим, **организациями и потребителями.

Документы keys, предоставляемые Azure AD v2.0, содержат для каждого ключа сведения об издателе, использующем этот ключ подписи. Например, конечная точка ключа https://login.microsoftonline.com/common/discovery/v2.0/keys, не зависящая от арендатора, возвращает документ следующего вида:

{
  "keys":[
    {"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
  ]
}

Проверка издателя ключа подписывания

Приложение должно использовать свойство issuer документа с ключами, связанное с ключом, используемым для подписи токена, чтобы ограничить область действия ключей:

• Ключи, имеющие значение issuer с GUID, например https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0, должны использоваться только в том случае, если утверждение iss в токене точно соответствует этому значению.
• Ключи, имеющие шаблонное значение издателя, например https://login.microsoftonline.com/{tenantid}/v2.0, следует использовать только в том случае, если утверждение iss в токене соответствует этому значению после подстановки утверждения tid из токена вместо заполнителя {tenantid}.

Использование метаданных, не зависящих от арендатора, более эффективно для приложений, которые принимают токены от множества арендаторов.

Кратко

Ниже приведен пример псевдокода, который в общих чертах показывает, как проверить эмитента и эмитента ключа подписи:

1. Получение ключей из настроенного URL-адреса метаданных
2. Проверьте, подписан ли токен одним из опубликованных ключей; в противном случае проверка должна завершиться ошибкой.
3. Определите ключ в метаданных на основе параметра заголовка `kid`. Проверьте свойство "издатель", присоединенное к ключу в документе метаданных:

   var issuer = metadata["kid"].issuer;
   if (issuer.contains("{tenantId}", CaseInvariant)) issuer = issuer.Replace("{tenantid}", token["tid"], CaseInvariant);
   if (issuer != token["iss"]) throw validationException;
   if (configuration.allowedIssuer != "*" && configuration.allowedIssuer != issuer) throw validationException;
   var issUri = new Uri(token["iss"]);
   if (issUri.Segments.Count < 1) throw validationException;
   if (issUri.Segments[1] != token["tid"]) throw validationException;
   

Связанный контент

• Справочник по утверждениям токена доступа
• Защита приложений и API путем проверки утверждений