设置提示=同意后，Azure Active Directory需要管理员批准 [英] Azure Active Directory needs Admin Approval after setting prompt =consent

问题描述

在我的Azure Active Directory中的应用程序中，我向Graph API添加了管理员的一项必需同意权限，例如 Group.Read.All .我单击了 Grant Admin Consent for ... .如果我使用查询参数 prompt = consent 作为用户命中/authorize 端点，我将得到需要管理员批准的视图.如果我在没有任何 prompt 参数的情况下访问端点，则一切正常-我能够获得具有适当范围的令牌.在文档中，我读到了 prompt 参数仅确定同意的可见性.为什么这样工作?

In my application in Azure Active Directory I have added one of the Admin's consent required permission to the Graph API, let say Group.Read.All. I've clicked Grant Admin Consent for .... If I hit /authorize endpoint as a User with the query parameter prompt=consent, I'll get the view that I need admin approval. If I hit the endpoint without any prompt parameter, everything works fine - I'm able to get a token with a proper scope. In the documentation I've read that prompt parameter determines only the visibility of the consent. Why it works like that?

推荐答案

关于提示=同意，

授权服务器在向客户端返回信息之前应提示最终用户同意.如果无法获得同意，则必须返回错误，通常为 consent_required .

在Microsoft身份平台中，这意味着将要求最终用户提供同意，即使该用户先前已经同意或(对于工作或学校帐户，由管理员代表用户).

In the Microsoft Identity platform, this means that the end user will be required to provide consent, even if consent has been granted previously by the user or (in the case of work or school accounts, by an administrator on behalf of the user).

如果未授权用户同意所请求的权限(例如，由于禁用或限制了用户同意)，则使用 prompt = consent 始终会对用户造成困难.

If the user is not authorized to consent to the requested permissions (e.g. because user consent is disabled or restricted), using prompt=consent will always result in a hard block for the user.

在大多数情况下，不是是使用 prompt = consent 的最佳方法.通常考虑三种情况 prompt = consent :

In most cases, using prompt=consent is not the best approach. There are typically three scenarios prompt=consent is considered:

1. 您已更改所需的权限.所需的权限已更改(例如，已添加或删除了权限)，并且用户需要同意新的权限集.
2. 您想通知用户.应用程序开发人员希望确保通知用户该应用程序将被授权行使的权限(即使管理员已经代表相关用户同意).
3. 您需要征得用户本人(而不是管理员)的同意.应用开发人员希望确保最终用户自己提供同意，而与管理员先前可能授权的内容无关.

1. You've changed the required permissions. The required permissions have changed (e.g. permissions have been added or removed), and the user needs to consent to the new set of permissions.
2. You want to inform the user. The app developer wishes to ensure the user is informed of which permissions the app will be authorized to exercise (even if an administrator has already consented on behalf of the user in question).
3. You require consent from the user themselves, not an admin. The app developer wishes to ensure the end-user themselves provides consent, independent of what an administrator may have authorized previously.

如果您更改了所需的权限

动态定义请求的权限

在 v2.0端点上， scope 参数可用于

On the v2.0 endpoint, the scope parameter can be used to dynamically request a list of delegated permissions. For example, to request the read and export delegated permissions of the API identified by https://api.example.com:

scope=openid https://api.example.com/read

Azure AD将确保已授予所有请求的权限，并尝试提示同意尚未授予的任何权限(并且仅针对那些权限).如果所有请求的权限都已被授予，则颁发的令牌将包括所有授予的权限(即使未明确请求也是如此).

Azure AD will ensure that all the requested permissions have been granted, and attempt to prompt for consent for any permissions which have not yet been granted (and only for those). If the requested permissions have all been granted, the issued token will include all granted permissions (even if they were not specifically requested).

通常来说，在使用v2.0端点的增量同意功能时，应不使用 prompt = consent .如果需要，Azure AD将提示您进行增量同意.

Generally speaking, when making use of the incremental consent capability of the v2.0 endpoint, prompt=consent should not be used. Azure AD will take care of prompting for incremental consent if needed.

静态定义了所请求的权限

应用程序也只能识别其为其请求访问令牌的资源(即API)，具体权限是为该应用程序静态定义的.使用v2.0端点，这是在 scope 参数中完成的，并使用了

An app can also identify only the resource (i.e. the API) for which it is requesting an access token, the specific permissions being defined statically for the app. Using the v2.0 endpoint, this is done in the scope parameter, making use of the special .default permission value:

scope=openid https://api.example.com/.default

在 v1.0端点，这是通过 resource 参数实现的:

In the v1.0 endpoint, this was achieved using the resource parameter:

resource=https://api.example.com

所需权限的列表是在应用程序注册的静态列表中配置的.在Azure门户中，此列表位于Azure AD>应用程序注册> API权限中的配置的权限下.在Microsoft Graph的 Application 实体中(并且在应用清单中)，这是存储在 requiredResourceAccess 属性中.

The list of required permissions is configured in a static list on the app registration. In the Azure portal, this list is under Configured permissions in Azure AD > App registrations > API permissions. In the unerlying Application entity in Microsoft Graph (and in the app manifest), this is stoerd in the requiredResourceAccess property.

(在v1或v2终结点上)接收到此类请求后，Azure AD将检查已为请求的资源授予了哪些权限:

On receiving a request of this type (on either the v1 or v2 endpoint), Azure AD will check which permissions have been granted for the requested resource:

1. 如果已为请求的资源授予 no 委派权限或(如果使用了 prompt = consent ，则Azure AD将尝试提示输入静态定义列表中的所有必需权限.这将包括对其他API(如果已配置)的权限.
2. 如果已为请求的资源授予任何委派权限，则Azure AD将颁发具有所有授予的权限的令牌.响应的 scopes 参数 将包括访问令牌中包含的权限列表.

1. If no delegated permissions have been granted for the requested resource OR if prompt=consent is used, Azure AD will attempt to prompt for all the required permissions from the statically-defined list. This will include permissions for other APIs, if any are configured.
2. If any delegated permission has been granted for the requested resource, Azure AD will issue the token with all granted permissions. The scopes parameter of the response will include the list of permissions included in the access token.

依赖静态定义的必需权限(即v2上的/.default 或v1上的 resource )的应用程序应不使用对于每个登录请求，均会提示输入.相反，应用程序应:

Applications relying on statically-defined required permissions (i.e. /.default on v2 or resource on v1) should not use prompt=consent for every sign-in request. Instead, the application should:

1. 在没有 prompt =同意的情况下执行登录.
2. 检查响应的 scope 参数:
   • 如果列出了所需的权限，则无需采取进一步措施.
   • 如果没有(例如，如果在用户最初同意该应用后将新的权限添加到所需权限列表中)，则只有 才能再次将用户发回，这一次是 prompt =同意.

1. Perform a sign in without prompt=consent.
2. Check the scope parameter of the response:
   • If the desired permissions are listed, no further action is necessary.
   • If not (e.g. if a new permission was added to the list of required permissions after the user initially consented to the app), only then should the user be sent back again, this time with prompt=consent.

此策略可确保当管理员代表用户同意(例如，因为他们无权自己同意)时，用户可以登录应用，并且仅强制执行同意提示(或升级为管理员)配置新权限后，代表他们同意).

This strategy ensures that users can sign in to an app when an administrator has consented on their behalf (e.g. because they aren't authorized to consent on their own), and only forces the consent prompt (or an escalation to an admin to consent on their behalf) when a new permission has been configured.

使用 prompt = consent 并不是一个好方法以前，或由管理员代表用户).

Using prompt=consent is not a good approach if the goal is to only inform the user of which permissions the application has been authorized to exercise (either by the user previously, or by an administrator on the user's behalf).

相反，应用程序可以使用令牌响应的 scope 参数来构建所需的中断体验(例如，在将用户重定向回应用程序且已检索到令牌之后，但在此之前)继续)，通知用户已被授予了哪些权限.

Instead, an application can use the scope parameter of the token response to construct the desired interrupt experience (e.g. after the user has been redirected back to the app and the token has been retrieved, but before continuing), informing the user of which permissions it has been granted.

在某些特定情况下，应用程序需要用户同意才能获得所请求的权限，并希望不接受管理员代表用户授予的同意.

There may exist very specific cases when an application requires user consent for the requested permissions, and wishes to not accept consent granted on behalf of the user by an administrator.

在这种情况下，可以在所有登录中使用 prompt = consent ，但是要考虑以下重要警告:

In this case, using prompt=consent in all sign-ins could be used, but there are important caveats to consider:

• 在许多组织中，用户同意被禁用或受限制.如果用户无权同意为您的应用程序配置的权限，则他们将无法使用您的应用程序.
• 即使每次用户登录之前都已征得其同意，也会在每次登录时提示用户征求同意.
• 由于这是一个查询参数，因此，知识渊博的用户可以很轻松地在请求发出之前拦截该请求，并删除 prompt = consent (并且如果事先已经同意，则不会提示他们)征求同意).

• In many organizations, user consent is disabled or restricted. If users are not authorized to consent to the permissions configured for your app, they will not be able to use your application.
• The user will be prompted for consent every single sign-in, even if the user themselves already previously granted consent.
• Since this is a query parameter, a knowledgeable user could very easily intercept the request before it is made, and remove prompt=consent (and if consent was already previously granted, they will not be prompted for consent).

在这种情况下，最好在用户登录后 实施单独的授予同意的体验(类似于前面所述的通知"方案)，将应用的其他功能分开Microsoft身份平台提供的同意经验中的同意要求.

In this case, it may be better the app to implement a separate consent-granting experience after the user has signed in (similar to the "inform" scenario described earlier), separating the app's additional consent requirements from the consent experience provided by the Microsoft identity platform.

这篇关于设置提示=同意后，Azure Active Directory需要管理员批准的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！