Глоссарий: платформа удостоверений Майкрософт

Эти условия будут отображаться при использовании нашей документации, портала Azure, библиотек проверки подлинности и Microsoft API Graph. Некоторые термины относятся к корпорации Майкрософт, а другие связаны с протоколами, такими как OAuth или другими технологиями, используемыми с платформой удостоверений Майкрософт.

Маркер доступа

Тип маркера безопасности, выдаваемого сервером авторизации, который используется в клиентском приложении для доступа к серверу защищенных ресурсов. Этот маркер (как правило, в виде JSON Web Token (JWT)) реализует право на авторизацию, которое владелец ресурса предоставил клиенту, для запрошенного уровня доступа. Он содержит все применимые утверждения о субъекте, благодаря чему клиентское приложение может использовать его в качестве учетных данных при доступе к определенному ресурсу. Кроме того, владельцу ресурса не нужно предоставлять свои учетные данные клиенту.

Маркеры доступа допустимы только в течение короткого периода времени и не могут быть отменены. Сервер авторизации может также выдать маркер обновления при выдаче маркера доступа. Маркеры обновления обычно предоставляются только конфиденциальным клиентским приложениям.

Маркеры доступа иногда называют "Пользователь + приложение" или "Только приложение" в зависимости от представляемых учетных данных. Ниже описано, при каком типе предоставления авторизации в клиентском приложении используется тот или иной маркер.

  • Предоставление авторизации "Код авторизации"— сначала пользователь проходит аутентификацию как владелец ресурса, предоставляя клиенту права авторизации для доступа к ресурсу. Затем после получения маркера доступа проверку подлинности проходит клиент. Иногда этот маркер называют маркером "Пользователь + приложение", так как он представляет и пользователя, который авторизовал клиентское приложение, и само приложение.
  • Предоставление авторизации "Учетные данные клиента"— проверку подлинности проходит только клиент, а проверка подлинности и авторизация владельца ресурса не выполняются, поэтому маркер иногда называют маркером "Только приложение".

Дополнительные сведения см. в справочнике по маркерам доступа.

Субъект

Другой термин для клиентского приложения. Субъект является стороной, действующей от имени субъекта (владельца ресурса).

Идентификатор приложения (клиента)

Идентификатор приложения или идентификатор клиента — это значение, которое платформа удостоверений Майкрософт назначает приложению при его регистрации в Azure AD. Идентификатор приложения — это значение GUID, которое однозначно идентифицирует приложение и его конфигурацию на платформе удостоверений. Вы добавляете идентификатор приложения в код приложения, а библиотеки проверки подлинности включают значение в свои запросы к платформе удостоверений во время выполнения приложения. Идентификатор приложения (клиента) не является секретом. Не используйте его в качестве пароля или других учетных данных.

Манифест приложения

Возможность, предоставляемая на портале Azure. Он содержит представление JSON конфигурации удостоверения для приложения, которая используется как механизм обновления связанных сущностей приложения и субъекта-службы. Дополнительные сведения см. в статье Основные сведения о манифесте приложения Azure Active Directory.

Объект приложения

При регистрации или обновлении приложения на портале Azure создается или обновляется объект приложения и соответствующий объект субъекта-службы для этого клиента. Объект приложения глобально определяет конфигурацию удостоверения для приложения (для всех клиентов, где у него есть доступ) и предоставляет шаблон, на основе которого создаются соответствующие объекты субъектов-служб для локального использования во время выполнения (в конкретном клиенте).

Дополнительные сведения см. в статье Объекты приложения и субъекта-службы в Azure Active Directory (Azure AD).

Регистрация приложения

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

Дополнительные сведения см. в статье Интеграция приложений с Azure Active Directory.

Аутентификация

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

Авторизация

Предоставление разрешения на выполнение какого-либо действия субъекту безопасности, прошедшему проверку подлинности. Модель программирования Azure AD предусматривает два основных варианта:

Код авторизации

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

Конечная точка авторизации

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

Дополнительные сведения см. в разделах спецификации OAuth 2.0 по типам предоставления авторизации и конечной точки авторизации, а также в спецификации OpenIDConnect.

Предоставление авторизации

Объект, предоставляющий авторизациювладельца ресурса для клиентского приложения, что позволяет ему получать доступ к защищенным ресурсам этого владельца. Клиентское приложение может использовать один из четырех типов предоставления, определенных OAuth 2.0 Authorization Framework, в зависимости от требований или типа клиента: "предоставление кода авторизации", "предоставление учетных данных клиента", "неявное предоставление" и "предоставление учетных данных владельца ресурса". Клиенту возвращается маркер доступа или код авторизации (который позже меняется на маркер доступа) в зависимости от используемого типа предоставления авторизации.

Сервер авторизации

Как определено в OAuth 2.0 Authorization Framework, это сервер, ответственный за выдачу маркеров доступа для клиента после успешной проверки подлинности владельца ресурса и получения его авторизации. Клиентское приложение взаимодействует с сервером авторизации во время выполнения с использованием конечных точек авторизации и маркеров в соответствии с предоставлениями авторизации, определенными OAuth 2.0.

В случае интеграции приложений платформы удостоверений Майкрософт платформа реализует роль сервера авторизации для приложений Azure AD и API-интерфейсов службы Майкрософт, например API-интерфейсов Microsoft Graph.

Утверждение

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

Дополнительные сведения см. в справочнике по маркерам платформы удостоверений Майкрософт.

Клиентское приложение

Также называется актором. Как определено в OAuth 2.0 Authorization Framework, это приложение, которое выполняет запросы к защищенному ресурсу от имени владельца ресурса. Оно получает разрешения (в виде областей) от владельца ресурса. Термин "клиент" не подразумевает какие-либо конкретные характеристики реализации оборудования (например, место выполнения приложения: на сервере, настольном компьютере или на других устройствах).

Клиентское приложение запрашивает авторизацию от владельца ресурса для участия в потоке предоставления авторизации OAuth 2.0 и может получать доступ к API и данным от имени владельца ресурса. OAuth 2.0 Authorization Framework определяет два типа клиентов, "конфиденциальные" и "открытые", в зависимости от их возможности сохранять конфиденциальность учетных данных. Приложения могут реализовать веб-клиент (конфиденциальный), выполняемый на веб-сервере, клиент Native Client (открытый), установленный на устройстве, и клиент на основе агента пользователя (открытый), выполняемый в браузере устройства.

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

См. дополнительные сведения о платформе предоставления согласия.

Маркер идентификации

Маркер безопасностиOpenID Connect, предоставляемый конечной точкой авторизациисервера авторизации, который содержит утверждения, относящиеся к аутентификации владельца ресурса. Подобно маркеру доступа, маркеры идентификации также представлены в виде маркеров JSON Web Token (JWT) с цифровой подписью. Тем не менее в отличие от маркера доступа утверждения маркера идентификации не используются для целей, связанных с доступом к ресурсам и контролем доступа.

Дополнительные сведения см. в справочнике по идентификаторам маркеров.

Управляемые удостоверения

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

Платформа удостоверений Майкрософт

Платформа удостоверений Майкрософт — это решение на основе платформы для разработчиков и службы идентификации Azure Active Directory (Azure AD). С ее помощью разработчики могут создавать приложения, которые обеспечивают вход с помощью любых удостоверений Майкрософт, получают маркеры для вызова Microsoft Graph, других программных интерфейсов Майкрософт или API, созданных разработчиками. Это полнофункциональная платформа, включающая в себя службу аутентификации, библиотеки, службу регистрации приложений и конфигурацию, полную документацию по разработке, примеры кода и другое содержимое, предназначенное для разработчиков. Платформа удостоверений Майкрософт поддерживает стандартные отраслевые протоколы, такие как OAuth 2.0 и OpenID Connect.

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

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

Дополнительные сведения см. в статье Как реализовать вход любого пользователя Azure Active Directory (AD) с помощью шаблона мультитенантного приложения.

Native Client

Тип клиентского приложения, которое изначально установлено на устройстве. Так как весь код выполняется на устройстве, этот клиент считается «общедоступным» из-за неспособности хранить учетные данные в частном порядке, т. е. конфиденциально. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.

Разрешения

Клиентское приложение получает доступ к серверу ресурсов путем объявления запросов на разрешения. Доступно два типа таких разрешений:

В процессе получения согласия можно использовать оба типа разрешений. Они предоставляют администратору или владельцу ресурса возможность разрешить или запретить клиентскому приложению доступ к ресурсам в их клиенте.

Запросы на разрешения можно настроить на странице разрешений API приложения на вкладках на портале Azure, выбрав нужные делегированные разрешения и разрешения приложений (последние может выбрать только участник роли глобального администратора). Так как общедоступный клиент не может обеспечить безопасное хранение учетных данных, он может запросить только делегированные разрешения, в то время как конфиденциальный клиент может запросить и делегированные разрешения, и разрешения приложения. Объект приложения клиента сохраняет объявленные разрешения в свойстве requiredResourceAccess.

Маркер обновления

Тип маркера безопасности, выданного сервером авторизации. До истечения срока действия маркера доступа клиентское приложение включает связанный маркер обновления при запросе нового маркера доступа с сервера авторизации. Маркеры обновления обычно форматируются как веб-маркер JSON (JWT).

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

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

Владелец ресурса

Как определено в OAuth 2.0 Authorization Framework, это сущность, которая может предоставить доступ к защищенному ресурсу. Если владелец ресурса — человек, он называется пользователем. Например, если клиентскому приложению требуется получить доступ к почтовому ящику пользователя через API Microsoft Graph, ему необходимо получить разрешение у владельца ресурса почтового ящика. Владелец ресурса иногда также называется субъектом.

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

Сервер ресурсов

Как определено в OAuth 2.0 Authorization Framework, это сервер, на котором размещены защищенные ресурсы и который может принимать запросы на ресурсы, поступающие из клиентских приложений, которые предоставляют маркер доступа, и отвечать на них. Он также называется сервером защищенных ресурсов или приложением ресурсов.

Сервер ресурсов предоставляет API-интерфейсы и обеспечивает доступ к размещенным на нем защищенным ресурсам на основе областей и ролей, используя OAuth 2.0 Authorization Framework. Например, интерфейс API Microsoft Graph, который предоставляет доступ к данным клиента Azure AD, и API-интерфейсы Microsoft 365, которые предоставляют доступ к таким данным, как почта и календарь.

Как и в клиентском приложении, конфигурация удостоверения приложения ресурсов устанавливается путем регистрации в клиенте Azure AD, при этом предоставляется и объект приложения, и объект субъекта-службы. Некоторые API, предоставляемые корпорацией Майкрософт, например API Microsoft Graph, содержат заранее зарегистрированные субъекты-служб, доступные во всех клиентах во время подготовки.

Роли

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

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

Роли — это определяемые ресурсом строки (например, "Утверждающий затраты", "Только чтение" или Directory.ReadWrite.All), которыми можно управлять на портале Azure, используя манифест приложения ресурса. Эти строки хранятся в свойстве appRoles ресурса. С помощью портала Azure также можно назначать пользователям роли пользователей и настраивать разрешения приложений клиента для запроса ролей приложений.

Подробное описание ролей приложения, предоставляемых API Microsoft Graph, см. в статье Справочник по разрешениям Microsoft Graph. Дополнительные сведения см. в статье о добавлении и удалении назначений ролей Azure с помощью портала Azure.

Области действия

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

Области — это определяемые ресурсом строки (например, Mail.Read, Directory.ReadWrite.All), которыми можно управлять на портале Azure, используя манифест приложения ресурса. Эти строки хранятся в свойстве oauth2Permissions ресурса. Портал Azure также используется для настройки делегированных разрешений клиентского приложения для доступа к области.

Рекомендуется использовать такой формат именования: resource.operation.constraint. Подробное описание областей доступа, предоставляемых API Microsoft Graph, см. в статье Справочник по разрешениям Microsoft Graph. Сведения об областях, предоставляемых службами Microsoft 365, см. в справочнике по разрешениям API Microsoft 365.

Маркер безопасности

Подписанный документ, содержащий утверждения, такие как маркер OAuth 2.0 или утверждение SAML 2.0. При использовании предоставления авторизации n OAuth 2.0 маркер доступа (OAuth2), маркер обновления и маркер идентификации — это типы маркеров безопасности, реализованные в виде маркера JSON Web Token (JWT).

Объект субъекта-службы

При регистрации или обновлении приложения на портале Azure создается или обновляется объект приложения и соответствующий объект субъекта-службы для этого клиента. Объект приложения глобально определяет конфигурацию удостоверения для приложения (для всех клиентов, где связанному приложению предоставлен доступ) и шаблон, на основе которого создаются соответствующие объекты субъектов-служб для локального использования во время выполнения (в конкретном клиенте).

Дополнительные сведения см. в статье Объекты приложения и субъекта-службы в Azure Active Directory (Azure AD).

Вход

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

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

Функция выхода

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

Субъект

Также называется владельцем ресурса.

Клиент

Экземпляр каталога Azure AD, который называют клиентом Azure AD. Он обеспечивает несколько функций, включая следующие:

Создание арендаторов Azure AD и их привязка к подпискам Azure и Microsoft 365 выполняется во время регистрации, что обеспечивает возможности системы управления идентификацией и доступом для подписки. Администраторы подписок Azure могут также создать дополнительные клиенты Azure AD с помощью портала Azure. Подробные сведения о различных способах получения доступа к клиенту см. в статье Как получить клиент Azure Active Directory. Сведения о связи между подписками и клиентом Azure AD, а также инструкции по связыванию или добавлению подписки в клиент Azure AD см. в этой статье.

Конечная точка маркера

Одна из конечных точек, реализуемых сервером авторизации для поддержки предоставлений авторизации OAuth 2.0. В зависимости от разрешений она может использоваться для получения маркера доступа (и связанного маркера обновления) для клиента или маркера идентификации при использовании с протоколом OpenID Connect.

Клиент на основе агента пользователя

Тип клиентского приложения, которое скачивает код с веб-сервера и выполняется в агенте пользователя (к примеру, в браузере), например одностраничное приложение (SPA). Так как весь код выполняется на устройстве, этот клиент считается общедоступным из-за неспособности хранить учетные данные в частном порядке, т. е. конфиденциально. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.

Субъект-пользователь

Аналогично объекту субъекта-службы, который представляет экземпляр приложения, объект субъекта-пользователя является другим типом субъекта безопасности, который представляет пользователя. Тип пользовательского ресурса Microsoft Graph определяет схему для объекта пользователя, включая свойства, связанные с пользователем, такие как имя и фамилия, имя участника-пользователя, членство в роли каталога и т. д. Это обеспечивает настройку удостоверения пользователя в Azure AD для установки субъекта-пользователя во время выполнения. Субъект-пользователь представляет прошедшего проверку подлинности пользователя при едином входе, записи делегирования права согласия, принятии решений по контролю доступа и т. п.

Веб-клиент

Тип клиентского приложения, которое выполняет весь код на веб-сервере и может выступать в роли конфиденциального клиента, обеспечивая безопасное хранение учетных данных на сервере. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.

Удостоверения рабочих нагрузок

Удостоверение, используемое рабочей нагрузкой программного обеспечения (например, приложение, служба, скрипт или контейнер) для проверки подлинности и доступа к другим службам и ресурсам. В Azure AD удостоверения рабочей нагрузки — это приложения, субъекты-службы и управляемые удостоверения. Дополнительные сведения см. в обзоре удостоверения рабочей нагрузки.

Федерация удостоверений рабочей нагрузки

Позволяет безопасно получать доступ к защищенным ресурсам Azure AD из внешних приложений и служб без необходимости управлять секретами (для поддерживаемых сценариев). Дополнительные сведения см. в разделе о федерации удостоверения рабочей нагрузки.

Дальнейшие действия

Многие термины в этом глоссарии связаны с протоколами OAuth 2.0 и OpenID Connect. Хотя вам не нужно знать, как протоколы работают "по сети" для использования платформы удостоверений, знание некоторых основ протокола может помочь вам упростить сборку и отладку проверки подлинности и авторизации в приложениях: