Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
На платформе удостоверений Майкрософт понимание разрешений и согласия имеет решающее значение для разработки безопасных приложений, требующих доступа к защищенным ресурсам. В этой статье представлен обзор основных концепций и сценариев, связанных с разрешениями и согласием, помогая разработчикам приложений запрашивать необходимые разрешения от пользователей и администраторов. Понимая эти понятия, вы можете гарантировать, что приложения запрашивают только необходимый доступ, обеспечивая доверие и безопасность.
Чтобы получить доступ к защищенному ресурсу, например данным электронной почты или календаря, приложению требуется авторизация владельца ресурса. Владелец ресурса может предоставить согласие или отклонить запрос приложения. Понимание этих базовых концепций помогает создавать более безопасные и надежные приложения, которые запрашивают только необходимый доступ, когда им нужны пользователи и администраторы.
Сценарии доступа
Разработчик приложений должен определить, как приложение обращается к данным. Приложение может использовать делегированный доступ, выступая от имени пользователя, вошедшего в систему, или доступ только для приложений, выступая только в качестве собственного удостоверения приложения.
Делегированный доступ (доступ от имени пользователя)
В этом сценарии доступа пользователь вошел в клиентское приложение. Клиентское приложение обращается к ресурсу от имени пользователя. Для делегированного доступа требуются делегированные разрешения. Клиент и пользователь должны быть авторизованы отдельно для выполнения запроса. Дополнительные сведения о сценарии делегированного доступа см . в сценарии делегированного доступа.
Для клиентского приложения необходимо предоставить правильные делегированные разрешения. Делегированные разрешения также могут называться областями. Области — это разрешения для заданного ресурса, представляющего, к чему может обращаться клиентское приложение от имени пользователя. Дополнительные сведения об областях см. в разделе области и разрешения.
Для пользователя авторизация зависит от привилегий, предоставленных пользователю для доступа к ресурсу. Например, пользователь может быть авторизован для доступа к ресурсам каталога с помощью управления доступом на основе ролей Microsoft Entra (RBAC) или доступа к ресурсам почты и календаря с помощью Exchange Online RBAC. Дополнительные сведения о RBAC для приложений см. в разделе RBAC для приложений.
Доступ только для приложений (доступ без пользователя)
В этом сценарии доступа приложение действует самостоятельно без входа пользователя. Доступ к приложениям используется в таких сценариях, как автоматизация и резервное копирование. Этот сценарий также включает приложения, которые работают как фоновые службы или управляющие программы. Это целесообразно, если нежелательно входить в систему через учетную запись определенного пользователя или когда необходимые данные не могут быть ограничены одним пользователем. Дополнительные сведения о сценарии доступа только для приложений см. в разделе "Доступ только для приложений".
Доступ только для приложений использует роли приложения вместо делегированных областей. При предоставлении согласия роли приложений также могут называться разрешениями приложений. Клиентское приложение должно быть предоставлено соответствующим разрешениям приложения для вызываемого приложения ресурсов. После предоставления клиентское приложение может получить доступ к запрошенным данным. Дополнительные сведения о назначении ролей приложений клиентским приложениям см. в разделе "Назначение ролей приложения приложения".
Типы разрешений
Делегированные разрешения используются в сценарии делегированного доступа. Это разрешения, позволяющие приложению действовать от имени пользователя. Приложение не может получить доступ к тому, к чему не имеет доступа вошедший в систему пользователь.
Например, рассмотрите приложение, которому предоставлено Files.Read.All
делегированное разрешение от имени пользователя. Приложение может считывать только файлы, к которым пользователь может получить личный доступ.
Разрешения приложения, также называемые ролями приложений, используются в сценарии доступа только для приложений без вошедшего пользователя. Приложение может получить доступ к любым данным, с которым связано разрешение.
Например, приложение, которому предоставлено разрешение на использование API приложений Microsoft GraphFiles.Read.All
, может читать любой файл в тенанте с помощью Microsoft Graph. Как правило, только администратор или владелец субъекта-службы API может предоставить разрешения приложений, предоставляемые этим API.
Сравнение делегированных и разрешений приложений
Типы разрешений | Делегированные разрешения | Разрешения приложения |
---|---|---|
Типы приложений | Веб- или мобильное приложение / одностраничные приложения (SPA) | Веб-приложение или управляющая программа |
Контекст доступа | Получение доступа от имени пользователя | Получение доступа без пользователя |
Кто может давать согласие | — пользователи могут предоставить согласие на получение данных — администраторы могут предоставить согласие для всех пользователей |
Предоставить согласие может только администратор |
Методы согласия | — Статический: настроенный список при регистрации приложения — Dynamic: запрос отдельных разрешений при входе |
— Статический ТОЛЬКО: настроенный список при регистрации приложения |
Другие названия | -Области — области разрешений OAuth2 |
— роли приложения — Разрешения только для приложений |
Результат согласия (специфичный для Microsoft Graph) | OAuth2PermissionGrant | appRoleAssignment |
Согласие
Одним из способов предоставления приложениям разрешений является согласие. Согласие — это процесс, в котором пользователи или администраторы могут предоставить приложению разрешение на доступ к защищенному ресурсу. Например, когда пользователь пытается войти в приложение в первый раз, приложение может запросить разрешение на просмотр профиля пользователя и чтение содержимого почтового ящика пользователя. Пользователь видит список разрешений, запрашиваемых приложением с помощью запроса согласия. Другие сценарии, в которых пользователи могут видеть запрос на согласие, включают:
- При отмене ранее предоставленного согласия.
- Если приложение закодировано специально для запроса на согласие во время входа.
- Когда приложение использует динамическое согласие, чтобы запрашивать новые разрешения при необходимости во время выполнения.
Основные сведения о запросе согласия — это список разрешений, необходимых приложению, и сведения о издателе. Дополнительные сведения о запросе на согласие и интерфейсе предоставления согласия для администраторов и конечных пользователей см. в статье о согласии приложений.
предоставление согласия пользователем.
Согласие пользователя происходит, когда пользователь пытается войти в приложение. Пользователь предоставляет свои учетные данные входа, которые проверяются, чтобы определить, предоставлено ли согласие. Если предыдущая запись о согласии пользователя или администратора для необходимых разрешений не существует, отображается запрос на согласие и запрашивается предоставить приложению запрошенные разрешения. Администратору может потребоваться предоставить согласие от имени пользователя.
Согласие администратора
В зависимости от того, какие разрешения необходимы, некоторым приложениям может потребоваться, чтобы администратор предоставлял согласие. Например, разрешения приложений и многие делегированные разрешения с высоким уровнем привилегий могут быть разрешены только администратором.
Администраторы могут предоставить согласие для себя или всей организации. Дополнительные сведения о согласии пользователей и администраторов см . в обзоре согласия пользователя и администратора.
Запросы проверки подлинности запрашиваются для согласия администратора, если согласие не было предоставлено, и если запрашивается одно из этих разрешений с высоким уровнем привилегий.
Запросы разрешений, содержащие пользовательские области приложений, не считаются высокими привилегиями, поэтому они не требуют согласия администратора.
Предварительная авторизация
Предварительная авторизация позволяет владельцу приложения ресурсов предоставлять разрешения, не требуя от пользователей согласования для того же набора разрешений, которые предварительно авторизованы. Таким образом, предварительно несанкционированное приложение не просит пользователей согласиться на разрешения. Владельцы ресурсов могут предварительно выполнять проверку подлинности клиентских приложений на портале Azure или с помощью PowerShell и API, таких как Microsoft Graph.
Другие системы авторизации
Платформа согласия — это только один из способов, которые могут быть разрешены приложению или пользователю для доступа к защищенным ресурсам. Администраторы должны знать о других системах авторизации, которые могут предоставлять доступ к конфиденциальной информации. Примерами различных систем авторизации в Корпорации Майкрософт являются встроенные роли Microsoft Entra, azure RBAC, Exchange RBAC и согласие на использование ресурсов Teams.
См. также
- сценарий делегированного доступа платформа удостоверений Майкрософт
- Согласие пользователя и администратора в идентификаторе Microsoft Entra
- Области и разрешения в платформа удостоверений Майкрософт
- Преобразование однотенантного приложения в мультитенантный идентификатор Microsoft Entra
- Microsoft Entra Microsoft Q&A