Относительно prompt=consent, OpenID Connect говорит :
Сервер авторизации ДОЛЖЕН запросить у конечного пользователя согласие, прежде чем возвращать информацию Клиенту. Если он не может получить согласие, он ДОЛЖЕН вернуть ошибку, обычно consent_required.
. На платформе Microsoft Identity это означает, что конечный пользователь будет обязан предоставить согласие. , даже если согласие было ранее предоставлено пользователем или (в случае рабочих или школьных учетных записей администратором от имени пользователя).
Если пользователь не авторизован для согласия на запрошенные разрешения (например, поскольку пользовательское согласие отключено или ограничено), использование prompt=consent всегда приведет к жесткому блокированию для пользователя.
В большинстве случаев использование prompt=consent является , а не лучшим подходить. Обычно существует три сценария ios prompt=consent:
- Вы изменили необходимые разрешения . Необходимые разрешения были изменены (например, разрешения были добавлены или удалены), и пользователь должен дать согласие на новый набор разрешений.
- Вы хотите сообщить пользователю . Разработчик приложения хочет, чтобы пользователь был проинформирован о том, какие разрешения приложению будет разрешено использовать (даже если администратор уже дал согласие от имени данного пользователя).
- Требуется согласие от пользователь, а не администратор . Разработчик приложения хочет, чтобы конечный пользователь сам давал согласие, независимо от того, что администратор, возможно, разрешил ранее.
Если вы изменили, какие разрешения требуются
Когда запрашиваемые разрешения определены динамически
Вкл. конечная точка v2.0 , параметр scope может использоваться для динамически запроса списка делегированные разрешения. Например, для запроса делегированных разрешений read и export API, обозначенных https://api.example.com:
scope=openid https://api.example.com/read
Azure AD, убедитесь, что все запрошенные разрешения были предоставлены, и попытайтесь запрашивать согласие на любые разрешения, которые еще не были предоставлены (и только для тех). Если все запрошенные разрешения были предоставлены, выданный токен будет включать все предоставленные разрешения (даже если они не были запрошены специально).
Вообще говоря, при использовании возможности добавочного согласия конечной точки v2.0 , prompt=consent следует использовать , а не . Azure AD позаботится о том, чтобы при необходимости запрашивать добавочное согласие.
Когда запрашиваемые разрешения определены статически
Приложение также может идентифицировать только ресурс (т. Е. API), для которого он запрашивает токен доступа, указанные c разрешения статически определяются для приложения. Используя конечную точку v2.0, это делается в параметре scope, используя специальное .default значение разрешения :
scope=openid https://api.example.com/.default
В v1. 0 конечная точка , это было достигнуто с помощью параметра resource:
resource=https://api.example.com
Список необходимых разрешений настраивается в списке stati c при регистрации приложения. На портале Azure этот список находится под Настроенные разрешения в Azure AD> Регистрация приложений> Разрешения API. В подчиненном объекте Application в Microsoft Graph (и в манифесте app ) это хранится в свойстве requiredResourceAccess.
При получении запроса этого тип (в конечной точке v1 или v2), Azure AD проверит, какие разрешения были предоставлены для запрошенного ресурса:
- Если нет делегированные разрешения были предоставлены для запрошенный ресурс ИЛИ , если используется
prompt=consent, Azure AD попытается запросить все необходимые разрешения из статически определенного списка. Это будет включать разрешения для других API, если они настроены. - Если было предоставлено какое-либо делегированное разрешение для запрошенного ресурса, Azure AD выдаст токен со всеми предоставленными разрешениями. Параметр
scopes ответа будет включать список разрешений, включенных в токен доступа.
Приложения, использующие статически определенные требуемые разрешения (т. Е. /.default для v2 или resource на v1) следует , а не использовать prompt=consent для каждого запроса на вход. Вместо этого приложение должно:
- Выполнить вход в систему без
prompt=consent. - Проверить параметр
scope ответа : - Если в списке указаны нужные разрешения, дальнейшие действия не требуются.
- Если нет (например, если новое разрешение было добавлено в список требуемых разрешений после того, как пользователь первоначально дал согласие на app), только тогда в случае повторной отправки пользователя, на этот раз с
prompt=consent.
Эта стратегия гарантирует, что пользователи могут войти в приложение, если администратор дал согласие от его имени (например, из-за того, что он не уполномочен давать свое согласие самостоятельно) и заставляет запросить согласие (или эскалацию к администратору, чтобы дать согласие от их имени), когда новое разрешение было получено сконфигурирован.
Если вы хотите сообщить пользователю
Использование prompt=consent не очень хороший подход, если целью является только информирование пользователя, для которого разрешено приложение был авторизован может использоваться (ранее пользователем или администратором от имени пользователя).
Вместо этого приложение может использовать параметр scope ответа токена, чтобы создать желаемое взаимодействие с прерываниями (например, после пользователь был перенаправлен обратно в приложение и токен был получен, но перед продолжением), информируя пользователя о том, какие разрешения ему предоставлены.
Если вам требуется согласие пользователя, а не администратора
Могут существовать очень конкретные c случаи, когда приложение требует пользователя согласия на запрошенные разрешения и желает не принять согласие, предоставленное от имени пользователя администратор.
В этом случае можно использовать prompt=consent во всех входах в систему, но при этом необходимо учитывать следующие важные замечания:
- Во многих организациях согласие пользователя отключено или ограничено. Если пользователи не авторизованы для согласия на разрешения, настроенные для вашего приложения, они не смогут использовать ваше приложение.
- Пользователю будет предложено дать согласие при каждом входе в систему, даже если сам пользователь уже ранее предоставленное согласие.
- Поскольку это параметр запроса, осведомленный пользователь может очень легко перехватить запрос до того, как он будет выполнен, и удалить
prompt=consent (и, если согласие уже было получено ранее, он не будет запрашиваться для согласия).
В этом случае может быть лучше, чтобы приложение внедрило отдельную возможность предоставления согласия после входа пользователя (аналогично «информировать»). сценарий, описанный ранее), отделяющий дополнительные требования согласия приложения от опыта согласия, предоставляемого платформой идентификации Microsoft.