Общие сведения о токенах в Azure Active Directory B2C

Azure Active Directory B2C (Azure AD B2C) выдает различные типы маркеров безопасности при обработке каждого потока проверки подлинности. В этой статье описываются формат, характеристики безопасности и содержимое каждого типа токена.

Типы токенов

Azure AD B2C поддерживает протоколы OAuth 2.0 и OpenID Connect, которые используют маркеры для проверки подлинности и безопасного доступа к ресурсам. Все маркеры, используемые в Azure AD B2C, — это веб-токены JSON (JWTs), содержащие утверждения информации о носителе и субъекте маркера.

Следующие маркеры используются в взаимодействии с Azure AD B2C:

• Маркер идентификатора — JWT, содержащий утверждения, которые можно использовать для идентификации пользователей в приложении. Этот маркер безопасно отправляется в HTTP-запросах для обмена данными между двумя компонентами одного приложения или службы. Вы можете использовать утверждения в маркере идентификатора по своему усмотрению. Они часто используются для отображения сведений об учетной записи или принятия решений по управлению доступом в приложении. Идентификационные токены, выданные Azure AD B2C, подписаны, но не зашифрованы. Когда приложение или API получает маркер идентификатора, он должен проверить подпись, чтобы подтвердить подлинность маркера. Ваше приложение или API также должны проверить несколько требований в токене, чтобы доказать, что он действителен. В зависимости от требований сценария утверждения, проверенные приложением, могут отличаться, но приложение должно выполнять некоторые распространенные проверки утверждений в каждом сценарии.

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

• Маркер обновления . Маркеры обновления используются для получения новых маркеров идентификатора и маркеров доступа в потоке OAuth 2.0. Они предоставляют приложению долгосрочный доступ к ресурсам от имени пользователей, не требуя взаимодействия с этими пользователями. Маркеры обновления непрозрачны для приложения. Они выдаются Azure AD B2C и могут быть проверены и интерпретированы только Azure AD B2C. Они живут долго, но приложение не следует писать с ожиданием того, что маркер обновления прослужит определенный период времени. Токены обновления могут быть аннулированы в любой момент по различным причинам. Единственный способ для вашего приложения узнать, является ли токен обновления допустимым, — это попытаться проверить его, выполнив запрос токена в Azure AD B2C. При обмене токена обновления на новый токен вы получаете новый токен обновления в ответе на запрос токена. Сохраните новый маркер обновления. Он заменяет маркер обновления, который вы ранее использовали в запросе. Это действие помогает гарантировать, что маркеры обновления остаются действительными до тех пор, пока это возможно. Одностраничные приложения, использующие поток кода авторизации с PKCE, всегда имеют срок действия токена обновления 24 часа. Дополнительные сведения о последствиях безопасности маркеров обновления в браузере.

Конечные точки

Зарегистрированное приложение получает маркеры и взаимодействует с Azure AD B2C, отправляя запросы в следующие конечные точки:

• https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
• https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Токены безопасности, которые ваше приложение получает из Azure AD B2C, могут быть получены с /authorize или /token конечных точек. При получении токенов идентификатора из:

• /authorize конечная точка выполняется с помощью неявного потока, который часто используется для входа пользователей в веб-приложения на основе JavaScript. Однако если приложение использует MSAL.js 2.0 или более поздней версии, не включите неявное предоставление потока в регистрации приложения, так как MSAL.js 2.0+ поддерживает поток кода авторизации с PKCE.
• /token точка подключения осуществляется с помощью потока кода авторизации, который сохраняет токен скрытым от браузера.

Претензии

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

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

В следующей таблице перечислены утверждения, которые можно ожидать в токенах идентификаторов и токенах доступа, выданных Azure AD B2C.

Конфигурация

Следующие свойства используются для управления сроком действия маркеров безопасности, выпускаемых Azure AD B2C:

• Время существования маркера доступа и идентификатора (минуты) — время существования маркера носителя OAuth 2.0, используемого для получения доступа к защищенному ресурсу. Значение по умолчанию — 60 минут. Минимальное (включительно) — 5 минут. Максимальное значение (включительно) составляет 1440 минут.

• Время существования маркера обновления (дни) — максимальный период времени, до которого маркер обновления можно использовать для получения нового маркера доступа или идентификатора. Период времени также охватывает получение нового refresh token, если приложению была предоставлена offline_access список разрешений. Значение по умолчанию — 14 дней. Минимальное (включительно) — один день. Максимальное (включительно) — 90 дней.

• Время существования скользящего окна обновления (дней) — после этого периода времени пользователь вынужден повторно пройти проверку подлинности независимо от срока действия последнего маркера обновления, полученного приложением. Его можно предоставить только в том случае, если переключатель установлен в положение Bounded. Оно должно быть больше или равно значению времени существования маркера обновления (дней). Если для параметра задано значение "Нет срока действия", вы не можете указать определенное значение. Значение по умолчанию — 90 дней. Минимальное (включительно) — один день. Максимальное (включительно) — 365 дней.

Следующие варианты использования включены с помощью следующих свойств:

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

Эти параметры недоступны для сценариев сброса пароля пользователем.

Совместимость

Для управления совместимостью маркеров используются следующие свойства:

• Утверждение издателя (iss) — это свойство определяет тенант Azure AD B2C, который выдал токен. Значение по умолчанию — https://<domain>/{B2C tenant GUID}/v2.0/. Значение https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ содержит идентификаторы как для клиента Azure AD B2C, так и для пользовательского потока, которые были использованы в запросе маркера. Если приложению или библиотеке требуется соответствие Azure AD B2C спецификации OpenID Connect Discovery 1.0, используйте это значение.

• Утверждение субъекта (sub) — это свойство, определяющее сущность, для которой токен утверждает информацию. Значением по умолчанию является ObjectID, который заполняет sub запрос в токене идентификатором объекта пользователя. Значение Не поддерживается предоставляется только для обеспечения обратной совместимости. Рекомендуется переключиться на ObjectID сразу после того, как вы сможете.

• Утверждение, представляющее идентификатор политики - Этот параметр определяет тип утверждения, в которое помещается имя политики, используемое в запросе токена. Значение по умолчанию — tfp. Значение acr предоставляется только для обратной совместимости.

Сквозной режим

При запуске пользовательского процесса Azure AD B2C получает токен доступа от поставщика удостоверений. Azure AD B2C использует этот маркер для получения сведений о пользователе. Вы можете включить утверждение в потоке пользователя для передачи токена приложениям, которые вы регистрируете в Azure AD B2C. Приложение должно использовать рекомендуемый поток пользователя , чтобы воспользоваться преимуществами передачи маркера в качестве утверждения.

Azure AD B2C на данный момент поддерживает только передачу маркеров доступа поставщиков удостоверений OAuth 2.0, таких как Facebook и Google. Для всех других поставщиков удостоверений заявка возвращается пустой.

Ратификация

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

Проверка подписи

JWT содержит три сегмента, заголовок, текст и подпись. Сегмент подписи можно использовать для подтверждения подлинности токена, чтобы он мог быть доверен вашим приложением. Токены Azure AD B2C подписаны с помощью стандартных алгоритмов асимметричного шифрования, таких как RSA 256.

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

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Значение утверждения alg — это алгоритм, который использовался для подписи токена. Значение утверждения kid — это открытый ключ, который использовался для подписи токена. В любое время Azure AD B2C может подписать токен с помощью любого из наборов пар открытого закрытого ключа. Azure AD B2C периодически поворачивает возможный набор ключей. Приложение должно быть записано для автоматического обработки этих изменений ключей. Разумной частотой проверки обновлений открытых ключей, используемых Azure AD B2C, является каждые 24 часа. Чтобы справиться с непредвиденными изменениями ключа, приложение должно быть разработано так, чтобы повторно извлечь открытые ключи в случае получения неожиданного значения kid.

Azure AD B2C имеет конечную точку метаданных OpenID Connect. С помощью этой конечной точки приложения могут запрашивать сведения о Azure AD B2C во время выполнения. Эта информация включает точки подключения, содержимое токенов и ключи подписи токенов. Клиент Azure AD B2C содержит документ метаданных JSON для каждой политики. Документ метаданных — это объект JSON, содержащий несколько полезных элементов информации. Метаданные содержат jwks_uri, что дает расположение набора открытых ключей, используемых для подписывания токенов. Это расположение предоставляется здесь, но лучше всего динамически получить расположение с помощью документа метаданных и синтаксического анализа jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Документ JSON, расположенный по этому URL-адресу, содержит все сведения открытого ключа, используемые в определенный момент. Приложение может использовать kid утверждение в заголовке JWT, чтобы выбрать открытый ключ в документе JSON, который используется для подписи определенного токена. Затем он может выполнить проверку подписи с помощью правильного открытого ключа и указанного алгоритма.

Документ метаданных для B2C_1_signupsignin1 политики в клиенте contoso.onmicrosoft.com находится по адресу:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Чтобы определить, какая политика использовалась для подписи токена (и куда обращаться за метаданными), у вас есть два варианта. Во-первых, имя политики включается в токен tfp (по умолчанию) или клайм acr (как настроено). Вы можете проанализировать утверждения из содержимого JWT, декодировав это содержимое в кодировке base-64 и десериализовав полученную строку JSON. tfp или acr утверждение — это имя политики, которая использовалась для выдачи токена. Другой вариант — кодировать политику в значении state параметра при выполнении запроса, а затем декодировать его, чтобы определить, какая политика использовалась. Любой метод является допустимым.

Azure AD B2C использует алгоритм RS256, основанный на спецификации RFC 3447 . Открытый ключ состоит из двух компонентов: модуля RSA (n) и общедоступной экспоненты RSA (e). Вы можете программно преобразовать значения n и e в формат сертификата для проверки маркеров.

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

Проверка утверждений

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

• аудитория — проверяет, что токен идентификации предназначен для вашего приложения.
• не до истечения срока действия . Проверяет, не истек ли маркер идентификатора.
• издатель — подтверждает, что токен был выдан вашему приложению службой Azure AD B2C.
• nonce — стратегия усиления защиты от атак воспроизведения токенов.

Полный список проверок, которые должно выполнять приложение, см. в спецификации OpenID Connect.

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

Узнайте больше об использовании маркеров доступа.