Azure AD B2C: протоколы проверки подлинности

Azure Active Directory B2C (Azure AD B2C) предоставляет удостоверение как услугу для ваших приложений, поддерживая два стандартных отраслевых протокола: OpenID Connect и OAuth 2.0. Сервис соответствует стандартам, но любые две реализации этих протоколов могут иметь незначительные различия.

Информация в этом руководстве будет полезна, если вы пишете код путем прямой отправки и обработки HTTP-запросов, а не с помощью библиотеки с открытым исходным кодом. Мы рекомендуем вам прочитать эту страницу, прежде чем углубляться в детали каждого конкретного протокола. Но если вы уже знакомы с Azure AD B2C, вы можете сразу перейти к справочным руководствам по протоколу.

Основные принципы

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

• Идентификатор приложения, который однозначно идентифицирует ваше приложение.

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

• Несколько других значений, специфичных для сценария. Для получения дополнительной информации узнайте, как зарегистрировать свое приложение.

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

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Если вы используете личный домен, замените {tenant}.b2clogin.com его на личный домен, например contoso.com, в конечных точках.

Почти во всех потоках OAuth и OpenID Connect в обмене участвуют четыре стороны:

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

• Владельцем ресурса обычно является конечный пользователь. Это сторона, которая владеет данными, и у нее есть право разрешить третьим лицам доступ к этим данным или ресурсу.

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

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

Политики и потоки пользователей

Azure AD B2C расширяет стандартные протоколы OAuth 2.0 и OpenID Connect, вводя политики. Это позволяет Azure AD B2C выполнять гораздо больше, чем просто проверку подлинности и авторизацию.

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

Политики и потоки пользователей не являются стандартными функциями OAuth 2.0 и OpenID Connect, поэтому вам следует потратить время, чтобы разобраться в них. Дополнительные сведения см. в справочном руководстве по потоку пользователя Azure AD B2C.

Токены

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

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

Некоторые токены безопасности имеют встроенные механизмы, которые предотвращают их использование неавторизованными сторонами, но предъявительские токены не имеют таких механизмов. Они должны транспортироваться по защищенному каналу, например по протоколу безопасности транспортного уровня (HTTPS).

Если токен носителя передается вне защищенного канала, злоумышленник может воспользоваться атакой «человек посередине», чтобы получить токен и использовать его для получения несанкционированного доступа к защищенному ресурсу. Те же принципы безопасности применяются при хранении или кэшировании токенов носителя для последующего использования. Всегда удостоверьтесь, что ваше приложение безопасно передает и хранит токены.

Дополнительные рекомендации по безопасности маркеров носителя см. в RFC 6750, раздел 5.

Дополнительные сведения о различных типах маркеров, используемых в Azure AD B2C, см. в справочнике по маркерам Azure AD B2C.

Протоколы

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

• Создание мобильных и нативных приложений с помощью OAuth 2.0
• Создание веб-приложений с помощью OpenID Connect