Изучение разрешений и согласий

  • 3 мин

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

Платформа удостоверений Майкрософт реализует протокол авторизации OAuth 2.0. OAuth 2.0 — это метод, посредством которого стороннее приложение может обращаться к интернет-ресурсам от имени пользователя. Любой интернет-ресурс, интегрируемый с платформой удостоверений Майкрософт, имеет идентификатор ресурса или универсальный код ресурса (URI) идентификатора приложения.

Ниже приведен ряд примеров интернет-ресурсов Майкрософт.

  • Microsoft Graph: https://graph.microsoft.com
  • API почты Microsoft 365: https://outlook.office.com
  • Azure Key Vault: https://vault.azure.net

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

В OAuth 2.0 наборы разрешений такого типа называются областями. Также их часто называют просто разрешениями. На платформе удостоверений Майкрософт они представлены в виде строковых значений. Приложение запрашивает необходимые разрешения, указывая разрешение в параметре запроса scope. Платформа удостоверений поддерживает несколько четко определенных Подключение область OpenID и разрешений на основе ресурсов (каждое разрешение указывается путем добавления значения разрешения к идентификатору ресурса или URI идентификатора приложения). Например, строка разрешений https://graph.microsoft.com/Calendars.Read используется для запроса разрешения на чтение календарей пользователей в Microsoft Graph.

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

Примечание.

Если в запросах на проверку подлинности, маркер или конечные точки предоставления согласия для платформы удостоверений Майкрософт идентификатор ресурса будет опущен в параметре области, будет считаться, что ресурс — Microsoft Graph. Например, выражение scope=User.Read будет эквивалентно https://graph.microsoft.com/User.Read.

Типы разрешений

Платформа удостоверений Майкрософт поддерживает два типа разрешений: делегированные разрешения и доступ только для приложений.

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

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

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

Существует три типа согласия: статическое согласие пользователя, добавочное и динамическое согласие пользователя и согласие администратора.

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

Статические разрешения для приложения, заданные на портале Azure, позволяют упростить код, но при этом представляют определенные потенциальные сложности для разработчиков:

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

  • Приложению заранее должны быть известны все ресурсы, к которым оно когда-либо обратится. Трудно создать приложения, которые могут получить доступ к произвольному количеству ресурсов.

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

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

Важно!

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

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

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

В запросе авторизации OpenID Connect или OAuth 2.0 приложение может запросить необходимые разрешения с помощью параметра запроса области. Например, при входе пользователя в приложение оно отправит запрос следующего вида. Разрывы строк добавлены для удобочитаемости.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

Параметр scope — это запрашиваемый приложением список делегированных разрешений с разделителями-пробелами. Чтобы указать каждое разрешение, его значение добавляется к идентификатору ресурса (универсальному коду ресурса (URI) идентификатора приложения). В приведенном примере запроса приложению требуется разрешение на чтение календаря пользователя и отправку сообщений от его имени.

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