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 Active Directory B2C: регистрация приложения.
После регистрации приложение взаимодействует с 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 также запрашивает маркеры у сервера авторизации. Владелец ресурса должен предоставить клиенту разрешение на доступ к ресурсу.
Сервер ресурсов — это расположение для ресурса или данных. Он доверяет серверу авторизации безопасную проверку подлинности и авторизацию клиента 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 0.2 и OpenID Connect в Azure AD B2C широко используются токены носителя, включая токены носителя в виде веб-токенов JSON (JWT). Токен носителя — это упрощенный маркер безопасности, предоставляющий его носителю доступ к защищенному ресурсу.
В этом смысле носителем является любая сторона, которая может предъявить маркер. Прежде чем получить токен носителя, сторона должна пройти проверку подлинности в Azure AD В2С. Но если не выполняются действия, необходимые для защиты маркера во время его передачи и хранения, его может перехватить и использовать неавторизованная сторона.
У некоторых маркеров безопасности есть встроенный механизм, который предотвращает их использование несанкционированными сторонами, но токены носителя не имеют такого механизма. Они должны передаваться по защищенному каналу, например по протоколу TLS (HTTPS).
Если токен носителя передается вне зашифрованного канала, злоумышленник может использовать атаку "злоумышленник в середине", чтобы получить токен и использовать его для несанкционированного доступа к защищенному ресурсу. Те же принципы безопасности применяются при сохранении или кэшировании токенов носителя для последующего использования. Необходимо всегда проверять, что приложение передает и сохраняет токены носителя безопасным образом.
Дополнительные сведения о безопасности при применении токенов носителя см. в документе RFC 6750 (раздел 5).
Дополнительные сведения о различных типах маркеров, используемых в Azure AD B2C, см. в справочнике по маркерам Azure AD B2C.
Протоколы
Если вы хотите ознакомиться с некоторыми примерами запросов, можете начать с одного из следующих учебников. Каждый из них соответствует определенному сценарию проверки подлинности. Сведения о том, как выбрать правильный поток, см. в статье о типах приложений, которые можно создать с помощью Azure AD B2C.