Бұл браузерге бұдан былай қолдау көрсетілмейді.
Соңғы мүмкіндіктерді, қауіпсіздік жаңартуларын және техникалық қолдауды пайдалану үшін Microsoft Edge браузеріне жаңартыңыз.
Вы увидите эти условия при использовании нашей документации, Центра администрирования Microsoft Entra, наших библиотек проверки подлинности и API Microsoft Graph. Некоторые термины относятся к корпорации Майкрософт, а другие связаны с протоколами, такими как OAuth или другими технологиями, используемыми с платформой удостоверений Майкрософт.
Тип маркера безопасности, выдаваемого сервером авторизации, который используется в клиентском приложении для доступа к серверу защищенных ресурсов. Этот маркер (как правило, в виде JSON Web Token (JWT)) реализует право на авторизацию, которое владелец ресурса предоставил клиенту, для запрошенного уровня доступа. Он содержит все применимые утверждения о субъекте, благодаря чему клиентское приложение может использовать его в качестве учетных данных при доступе к определенному ресурсу. Кроме того, владельцу ресурса не нужно предоставлять свои учетные данные клиенту.
Маркеры доступа допустимы только в течение короткого периода времени и не могут быть отменены. Сервер авторизации может также выдать токен обновления при выдаче токена доступа. Маркеры обновления обычно предоставляются только конфиденциальным клиентским приложениям.
Маркеры доступа иногда называют "Пользователь + приложение" или "Только приложение" в зависимости от представляемых учетных данных. Например, когда клиентское приложение использует:
Дополнительные сведения см. в справочнике по маркерам доступа.
Другой термин для клиентского приложения. Актор является стороной, действующей от имени субъекта (владельца ресурса).
Идентификатор приложения или идентификатор клиента — это значение, которое платформа удостоверений Майкрософт назначает приложению при регистрации его в идентификаторе Microsoft Entra. Идентификатор приложения — это значение GUID, которое однозначно идентифицирует само приложение и его конфигурацию в рамках платформы удостоверений. Вы добавляете идентификатор приложения в код приложения, а библиотеки проверки подлинности включают значение в свои запросы к платформе удостоверений во время выполнения приложения. Идентификатор приложения (клиента) не является секретом. Не используйте его в качестве пароля или других учетных данных.
Манифест приложения — это функция, которая создает JSON-представление конфигурации удостоверения приложения и используется как механизм для обновления связанных сущностей Application и ServicePrincipal. Дополнительные сведения см. в разделе Понимание манифеста приложения Microsoft Entra.
При регистрации и обновлении приложения создается или обновляется объект приложения и соответствующий объект субъекта-службы для этого клиента. Объект приложения глобально определяет конфигурацию удостоверения для приложения (для всех клиентов, где у него есть доступ) и предоставляет шаблон, на основе которого создаются соответствующие объекты субъектов-служб для локального использования во время выполнения (в конкретном клиенте).
Дополнительные сведения см. в статье Объекты приложения и субъекта-службы в Azure Active Directory (Azure AD).
Чтобы разрешить приложению интегрироваться с функциями управления удостоверениями и доступом к идентификатору Microsoft Entra, его необходимо зарегистрировать в клиенте Microsoft Entra. При регистрации приложения с помощью идентификатора Microsoft Entra вы предоставляете конфигурацию удостоверения для приложения, позволяя ему интегрироваться с идентификатором Microsoft Entra и использовать такие функции, как:
Дополнительные сведения см. в статье об интеграции приложений с идентификатором Microsoft Entra.
Запрос у стороны легитимных учетных данных, являющийся основой для создания субъекта безопасности, который будет использоваться для управления удостоверением личности и доступом. К примеру, во время предоставления авторизации OAuth 2.0 сторона, выполняющая проверку подлинности, в зависимости от используемых разрешений выполняет роль владельца ресурса или клиентского приложения.
Предоставление разрешения на выполнение какого-либо действия субъекту безопасности, прошедшему проверку подлинности. Существует два основных варианта использования в модели программирования Microsoft Entra:
Кратковременное значение, предоставляемое конечной точкой авторизацииклиентскому приложению во время потока предоставления кода авторизации OAuth 2.0, одного из четырех грантов авторизации OAuth 2.0. Также называется кодом проверки подлинности, код авторизации возвращается клиентскому приложению в ответ на проверку подлинности владельца ресурса. Код проверки подлинности указывает, что владелец ресурса делегировал авторизацию клиентскому приложению для доступа к своим ресурсам. В рамках потока код авторизации впоследствии обменивается на маркер доступа.
Одна из конечных точек, реализуемых сервером авторизации, используется для взаимодействия с владельцем ресурса, чтобы предоставить разрешение на авторизацию в ходе предоставления разрешения на авторизацию в потоке OAuth 2.0. Фактическое предоставление, в том числе код авторизации и маркер безопасности, может отличаться в зависимости от используемого потока предоставления авторизации.
Дополнительные сведения см. в разделах спецификации OAuth 2.0 по типам предоставления авторизации и конечной точки авторизации, а также в спецификации OpenIDConnect.
Полномочие, представляющее разрешение владельца ресурса на доступ к его защищённым ресурсам, предоставленное клиентскому приложению. Клиентское приложение может использовать один из четырех типов предоставления, определенных OAuth 2.0 Authorization Framework, в зависимости от требований или типа клиента: "предоставление кода авторизации", "предоставление учетных данных клиента", "неявное предоставление" и "предоставление учетных данных владельца ресурса". Клиенту возвращается маркер доступа или код авторизации (который позже меняется на маркер доступа) в зависимости от используемого типа предоставления авторизации.
Предоставление учетных данных владельца ресурса не должно использоваться , за исключением сценариев, когда другие потоки не могут использоваться. Если вы создаете SPA, используйте поток кода авторизации с PKCE вместо неявного разрешения.
Как определено в OAuth 2.0 Authorization Framework, это сервер, ответственный за выдачу маркеров доступа для клиента после успешной проверки подлинности владельца ресурса и получения его авторизации. Клиентское приложение взаимодействует с сервером авторизации во время выполнения с использованием конечных точек авторизации и маркеров в соответствии с предоставлениями авторизации, определенными OAuth 2.0.
В случае интеграции приложения с платформой удостоверений Microsoft, эта платформа выполняет роль сервера авторизации для приложений Microsoft Entra и API сервисов Microsoft, например API Microsoft Graph.
Утверждения — это пары имен и значений в маркере безопасности, которые предоставляют утверждения, сделанные одной сущностью в другой. Обычно эти сущности являются клиентским приложением или владельцем ресурса, предоставляющим утверждения серверу ресурсов. Утверждения передают факты о предмете токена, такие как, например, идентификатор субъекта безопасности, прошедшего аутентификацию с помощью сервера авторизации. Утверждения, присутствующие в маркере, могут различаться и зависеть от нескольких факторов, таких как тип маркера, тип учетных данных, используемых для проверки подлинности субъекта, конфигурации приложения и других.
Дополнительные сведения см. в справочнике по токенам платформы Microsoft Identity.
Также называется актером. Как определено в OAuth 2.0 Authorization Framework, это приложение, которое выполняет запросы к защищенному ресурсу от имени владельца ресурса. Оно получает разрешения (в виде областей) от владельца ресурса. Термин "клиент" не подразумевает какие-либо конкретные характеристики реализации оборудования (например, место выполнения приложения: на сервере, настольном компьютере или на других устройствах).
Клиентское приложение запрашивает авторизацию от владельца ресурса для участия в потоке предоставления авторизации OAuth 2.0 и может получать доступ к API и данным от имени владельца ресурса. OAuth 2.0 Authorization Framework определяет два типа клиентов, "конфиденциальные" и "открытые", в зависимости от их возможности сохранять конфиденциальность учетных данных. Приложения могут реализовать веб-клиент (конфиденциальный), выполняемый на веб-сервере, клиент Native Client (открытый), установленный на устройстве, и клиент на основе агента пользователя (открытый), выполняемый в браузере устройства.
Процесс предоставления владельцем ресурсаклиентскому приложению доступа к ресурсам, защищенным конкретными разрешениями, от своего имени. В зависимости от разрешений, запрошенных клиентом, администратору или пользователю будет отправлен запрос на разрешение доступа к рабочим или личным данным. Обратите внимание, в многопользовательском сценарии основной объект службы приложения также записывается в клиенте того пользователя, который дал согласие.
См. дополнительные сведения о платформе предоставления согласия.
Маркер безопасностиOpenID Connect , предоставляемый конечной точкой авторизациисервера авторизации, который содержит утверждения, относящиеся к аутентификации владельца ресурса. Подобно маркеру доступа, маркеры идентификации также представлены в виде маркеров JSON Web Token (JWT) с цифровой подписью. Тем не менее в отличие от маркера доступа утверждения маркера идентификации не используются для целей, связанных с доступом к ресурсам и контролем доступа.
Дополнительные сведения см. в справочнике по идентификаторам токенов.
Устраняют необходимость в управлении учетными данными для разработчиков. Управляемые удостоверения предоставляют удостоверение для приложений, используемых при подключении к ресурсам, поддерживающим проверку подлинности Microsoft Entra. Приложения могут использовать управляемое удостоверение для получения токенов платформы удостоверений Microsoft. Например, приложение может использовать управляемое удостоверение для доступа к ресурсам, таким как Azure Key Vault , где разработчики могут хранить учетные данные безопасным образом или для доступа к учетным записям хранения. Дополнительные сведения см. в обзоре управляемых удостоверений.
Платформа удостоверений Microsoft является развитием службы удостоверений Microsoft Entra и платформы для разработчиков. С ее помощью разработчики могут создавать приложения, которые обеспечивают вход с любыми удостоверениями Майкрософт и получают токены для вызова Microsoft Graph, других API Майкрософт или API, созданных разработчиками. Это полнофункциональная платформа, включающая в себя службу аутентификации, библиотеки, службу регистрации приложений и конфигурацию, полную документацию по разработке, примеры кода и другое содержимое, предназначенное для разработчиков. Платформа удостоверений Майкрософт поддерживает стандартные отраслевые протоколы, такие как OAuth 2.0 и OpenID Connect.
Класс приложения, который включает вход и согласие пользователей, подготовленных в любом клиенте Microsoft Entra, включая клиентов, отличных от того, где зарегистрирован клиент. Приложения собственного клиента являются мультитенантными по умолчанию, тогда как приложения веб-клиента и веб-ресурса или веб-API предусматривают возможность выбора отдельного клиента или нескольких клиентов. Веб-приложение, зарегистрированное как одноклиентское, напротив, предоставляет разрешение на вход только из учетных записей пользователей, подготовленных в том же клиенте, где было зарегистрировано приложение.
Дополнительные сведения см. в разделе «Вход любого пользователя Microsoft Entra с использованием шаблона мультитенантного приложения».
Тип клиентского приложения, которое изначально установлено на устройстве. Так как весь код выполняется на устройстве, этот клиент считается «общедоступным» из-за неспособности хранить учетные данные в частном порядке, т. е. конфиденциально. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.
Клиентское приложение получает доступ к серверу ресурсов путем объявления запросов на разрешения. Доступны два типа:
Во время процесса согласия они также становятся актуальными, предоставляя администратору или владельцу ресурса возможность разрешить или запретить клиенту доступ к ресурсам в их аренде.
Запросы разрешений настраиваются на странице разрешений API для приложения, выбрав нужные "Делегированные разрешения" и "Разрешения приложения" (последний требует членства в роли глобального администратора). Так как общедоступный клиент не может обеспечить безопасное хранение учетных данных, он может запросить только делегированные разрешения, в то время как конфиденциальный клиент может запросить и делегированные разрешения, и разрешения приложения. Объект приложения клиента сохраняет объявленные разрешения в свойстве requiredResourceAccess.
Тип маркера безопасности, выданного сервером авторизации. До истечения срока действия маркера доступа клиентское приложение включает связанный маркер обновления при запросе нового маркера доступа с сервера авторизации. Маркеры обновления обычно форматируются как веб-маркер JSON (JWT).
В отличие от токенов доступа, токены обновления могут быть отозваны. Сервер авторизации отклоняет любой запрос от клиентского приложения, включающего отозванный маркер обновления. Когда сервер авторизации отклоняет запрос, включающий отозванный маркер обновления, клиентское приложение теряет разрешение на доступ к серверу ресурсов от имени владельца ресурса.
Дополнительные сведения см. в разделе о маркерах обновления.
Как определено в OAuth 2.0 Authorization Framework, это сущность, которая может предоставить доступ к защищенному ресурсу. Если владелец ресурса — человек, он называется конечным пользователем. Например, если клиентскому приложению требуется получить доступ к почтовому ящику пользователя через API Microsoft Graph, ему необходимо получить разрешение у владельца ресурса почтового ящика. Владелец ресурса иногда также называется субъектом.
Этот маркер безопасности представляет владельца ресурса. Владелец ресурса — это то, что представляют собой утверждение субъекта, утверждение идентификатора объекта и персональные данные в токене. Владельцы ресурсов — это сторона, предоставляющая делегированные разрешения (в виде областей) клиентскому приложению. Владельцы ресурсов также являются получателями ролей, которые обозначают расширенные разрешения в пределах арендатора или приложения.
Как определено в OAuth 2.0 Authorization Framework, это сервер, на котором размещены защищенные ресурсы и который может принимать запросы на ресурсы, поступающие из клиентских приложений, которые предоставляют маркер доступа, и отвечать на них. Он также называется сервером защищенных ресурсов или приложением ресурсов.
Сервер ресурсов предоставляет API и обеспечивает доступ к защищенным ресурсам с помощью областей и ролей, используя систему авторизации OAuth 2.0. Примерами являются API Microsoft Graph, который предоставляет доступ к данным клиента Microsoft Entra и API Microsoft 365, которые предоставляют доступ к данным, таким как почта и календарь.
Подобно клиентскому приложению, конфигурация удостоверения приложения ресурсов устанавливается через регистрацию в арендаторе Microsoft Entra, предоставляя как объекты приложения, так и главный объект службы. Некоторые API, предоставляемые корпорацией Майкрософт, например API Microsoft Graph, содержат заранее зарегистрированные служебные субъекты, доступные во всех клиентах на этапе развертывания.
Как и области, роли приложения предоставляют возможность контролировать доступ к защищенным ресурсам для сервера ресурсов. В отличие от областей, роли представляют разрешения, предоставленные субъекту за пределами базового уровня: это значит, что чтение собственного электронного сообщения является областью, а администратор электронной почты, способный читать сообщения других пользователей, представляет собой роль.
Роли приложений поддерживают два типа назначений: назначение типа "пользователь" реализует управление доступом на основе ролей для пользователей или групп, которым требуется доступ к ресурсу, а назначение типа "приложение" реализует то же самое для клиентских приложений, которым нужен доступ. Роль приложения может быть определена как назначаемая пользователем, назначаемая приложением или оба.
Роли — это определяемые ресурсом строки (например, "Утверждающий расходы", "Только для чтения", "Directory.ReadWrite.All"), которые управляются с помощью манифеста приложения ресурса и хранятся в свойстве appRoles ресурса. Пользователи могут быть назначены на назначаемые роли "пользователь", а разрешения клиентского приложения могут быть сконфигурированы для запроса на назначаемые роли "приложение".
Подробное описание ролей приложения, предоставляемых API Microsoft Graph, см. в статье Справочник по разрешениям Microsoft Graph. Пошаговый пример реализации см. в статье "Добавление или удаление назначений ролей Azure".
Как и роли, области позволяют серверу ресурсов контролировать доступ к своим защищенным ресурсам. Области используются для реализацииконтроля доступа на основе областей для клиентского приложения, которому предоставлен делегированный доступ к ресурсу его владельцем.
Области — это строки, определяемые ресурсом (например, "Mail.Read", "Directory.ReadWrite.All"), управляемые через манифест приложения ресурса и хранящиеся в свойстве oauth2Permissions ресурса. Делегированные разрешения клиентского приложения можно настроить для доступа к области.
Рекомендуется использовать такой формат именования: resource.operation.constraint. Подробное описание областей доступа, предоставляемых API Microsoft Graph, см. в статье Справочник по разрешениям Microsoft Graph. Сведения об областях, предоставляемых службами Microsoft 365, см. в справочнике по разрешениям API Microsoft 365.
Подписанный документ, содержащий утверждения, такие как маркер OAuth 2.0 или утверждение SAML 2.0. При использовании предоставления авторизации в OAuth 2.0, токен доступа (OAuth2), токен обновления и токен идентификации — это типы токенов безопасности, реализованные в виде JSON Web Token (JWT).
При регистрации и обновлении приложения создается или обновляется объект приложения и соответствующий объект субъекта-службы для этого клиента. Объект приложения глобально определяет конфигурацию удостоверения для приложения (для всех клиентов, где связанному приложению предоставлен доступ) и шаблон, на основе которого создаются соответствующие объекты субъектов-служб для локального использования во время выполнения (в конкретном клиенте).
Дополнительные сведения см. в статье Объекты приложения и субъекта-службы в Azure Active Directory (Azure AD).
Процесс, в ходе которого клиентское приложение инициирует проверку подлинности конечного пользователя и фиксирует соответствующее состояние, чтобы получить маркер безопасности и использовать это состояние для сеанса приложения. Состояние может включать такие элементы, как сведения о профиле пользователя и информация, извлеченная из утверждений токена.
Функция входа в приложение обычно используется для реализации единого входа (SSO). Ей может также предшествовать функция регистрации как точка входа для пользователя, с помощью которой предоставляется доступ к приложению (после первого входа в систему). Функция регистрации используется для сбора и сохранения дополнительного состояния конкретного пользователя и может требовать согласия пользователя.
Процесс деаутентификации конечного пользователя, при котором отсоединяется состояние пользователя, связанное с сеансом клиентского приложения во время входа.
Также называется владельцем ресурса.
Экземпляр каталога Microsoft Entra называется клиентом Microsoft Entra. Он обеспечивает несколько функций, включая следующие:
Клиенты Microsoft Entra создаются и связаны с подписками Azure и Microsoft 365 во время регистрации, предоставляя функции управления удостоверениями и доступом для подписки. Администраторы подписок Azure также могут создавать дополнительные клиенты Microsoft Entra. Смотрите к разделу 'Как получить арендатора Microsoft Entra' для подробностей о различных способах получения доступа. Сведения о связи между подписками и клиентом Microsoft Entra см. в статье "Связывание или добавление подписки Azure в клиент Microsoft Entra" и инструкции по связыванию или добавлению подписки в клиент Microsoft Entra.
Одна из конечных точек, реализуемых сервером авторизации для поддержки предоставлений авторизации OAuth 2.0. В зависимости от разрешений она может использоваться для получения маркера доступа (и связанного маркера обновления) для клиента или маркера идентификации при использовании с протоколом OpenID Connect.
Тип клиентского приложения, которое скачивает код с веб-сервера и выполняется в агенте пользователя (к примеру, в браузере), например одностраничное приложение (SPA). Так как весь код выполняется на устройстве, этот клиент считается «общедоступным» из-за неспособности хранить учетные данные в частном порядке, т. е. конфиденциально. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.
Аналогично объекту субъекта-службы, который представляет экземпляр приложения, объект субъекта-пользователя является другим типом субъекта безопасности, который представляет пользователя. Тип User ресурса Microsoft Graph определяет схему для объекта пользователя, включая свойства, связанные с пользователем, такие как имя и фамилия, основное имя пользователя, членство в роли каталога и т. д. Это предоставляет конфигурацию удостоверения пользователя для Microsoft Entra ID для создания пользовательского субъекта во время выполнения. Пользовательский объект используется для представления прошедшего проверку подлинности пользователя для единого входа в систему, записи делегирования согласия, принятия решений по контролю доступа и т. д.
Тип клиентского приложения, которое выполняет весь код на веб-сервере и может выступать в роли конфиденциального клиента, обеспечивая безопасное хранение учетных данных на сервере. Дополнительные сведения см. в разделе о типах и профилях клиента OAuth 2.0.
Удостоверение, используемое рабочей нагрузкой программного обеспечения (например, приложение, служба, скрипт или контейнер) для проверки подлинности и доступа к другим службам и ресурсам. В Microsoft Entra ID рабочие удостоверения — это приложения, служебные принципы и управляемые удостоверения. Дополнительные сведения см. в обзоре идентификации рабочей нагрузки.
Позволяет безопасно получать доступ к защищенным ресурсам Microsoft Entra из внешних приложений и служб без необходимости управлять секретами (для поддерживаемых сценариев). Дополнительные сведения см. в разделе федерация удостоверений рабочей нагрузки.
Многие термины в этом глоссарии связаны с протоколами OAuth 2.0 и OpenID Connect. Хотя вам не нужно знать, как протоколы работают "по сети" для использования платформы удостоверений, знание некоторых основ протокола может помочь вам упростить сборку и отладку проверки подлинности и авторизации в приложениях:
Оқыту
Модуль
Узнайте, как создавать, управлять и предоставлять разрешения удостоверениям рабочей нагрузки, которые позволяют рабочим процессам развертывания безопасно проходить проверку подлинности в Azure.
Сертификаттау
Microsoft Certified: Identity and Access Administrator Associate - Certifications
Продемонстрировать функции идентификатора Microsoft Entra для модернизации решений удостоверений, реализации гибридных решений и реализации управления удостоверениями.