[英]Azure Active Directory needs Admin Approval after setting prompt =consent
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
.在 Azure Active Directory 中的应用程序中,我向 Graph API 添加了管理员同意所需的权限之一,例如Group.Read.All
。 I've clicked Grant Admin Consent for ...
.我点击了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.如果我使用查询参数prompt=consent
作为用户点击/authorize
端点,我将获得需要管理员批准的视图。 If I hit the endpoint without any prompt
parameter, everything works fine - I'm able to get a token with a proper scope.如果我在没有任何prompt
参数的情况下点击端点,一切正常 - 我能够获得具有适当范围的令牌。 In the documentation I've read that prompt
parameter determines only the visibility of the consent.在我读过的文档中, prompt
参数仅确定同意的可见性。 Why it works like that?为什么它会这样?
Regarding prompt=consent
, OpenID Connect says :关于prompt=consent
, OpenID Connect 说:
The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client.授权服务器应该在将信息返回给客户端之前提示最终用户同意。 If it cannot obtain consent, it MUST return an error, typically
consent_required
.如果它不能获得同意,它必须返回一个错误,通常是consent_required
。
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).在 Microsoft Identity 平台中,这意味着最终用户将需要提供同意,即使用户之前已授予同意或(在工作或学校帐户的情况下,由管理员代表用户)。
If the user is not authorized to consent to the requested permissions (eg because user consent is disabled or restricted), using prompt=consent
will always result in a hard block for the user.如果用户未被授权同意所请求的权限(例如,因为用户同意被禁用或限制),使用prompt=consent
将始终导致用户的硬阻止。
In most cases, using prompt=consent
is not the best approach.在大多数情况下,使用prompt=consent
并不是最好的方法。 There are typically three scenarios prompt=consent
is considered:通常会考虑三种情况prompt=consent
:
When the requested permissions are defined dynamically动态定义请求的权限时
On the v2.0 endpoint , the scope
parameter can be used to dynamically request a list of delegated permissions.在v2.0 端点上, scope
参数可用于动态请求委托权限列表。 For example, to request the read
and export
delegated permissions of the API identified by https://api.example.com
:例如,请求https://api.example.com
标识的 API 的read
和export
委托权限:
scope=openid https://api.example.com/read
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). Azure AD 将确保已授予所有请求的权限,并尝试提示同意尚未授予的任何权限(并且仅授予这些权限)。 If the requested permissions have all been granted, the issued token will include all granted permissions (even if they were not specifically requested).如果请求的权限已全部授予,则颁发的令牌将包括所有授予的权限(即使它们没有被特别请求)。
Generally speaking, when making use of the incremental consent capability of the v2.0 endpoint, prompt=consent
should not be used.一般来说,利用2.0版端点的增量同意能力的时候, prompt=consent
不得使用。 Azure AD will take care of prompting for incremental consent if needed.如果需要,Azure AD 将负责提示增量同意。
When the requested permissions are defined statically当请求的权限被静态定义时
An app can also identify only the resource (ie the API) for which it is requesting an access token, the specific permissions being defined statically for the app.应用程序还可以仅识别其请求访问令牌的资源(即 API),应用程序静态定义特定权限。 Using the v2.0 endpoint, this is done in the scope
parameter, making use of the special .default
permission value :使用 v2.0 端点,这是在scope
参数中完成的,利用特殊的.default
权限值:
scope=openid https://api.example.com/.default
In the v1.0 endpoint , this was achieved using the resource
parameter:在v1.0 端点中,这是使用resource
参数实现的:
resource=https://api.example.com
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.在 Azure 门户中,此列表位于 Azure AD > 应用注册 > API 权限中的已配置权限下。 In the unerlying Application entity in Microsoft Graph (and in the app manifest ), this is stoerd in the requiredResourceAccess
property.在 Microsoft Graph(和应用程序清单)中的底层Application实体中,这在requiredResourceAccess
属性中。
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:收到此类请求后(在 v1 或 v2 终结点上),Azure AD 将检查已为请求的资源授予哪些权限:
prompt=consent
is used, Azure AD will attempt to prompt for all the required permissions from the statically-defined list.如果没有为请求的资源授予委派权限,或者使用prompt=consent
,Azure AD 将尝试从静态定义的列表中提示所有必需的权限。 This will include permissions for other APIs, if any are configured.这将包括其他 API 的权限(如果有)。scopes
parameter of the response will include the list of permissions included in the access token.响应的scopes
参数将包括访问令牌中包含的权限列表。 Applications relying on statically-defined required permissions (ie /.default
on v2 or resource
on v1) should not use prompt=consent
for every sign-in request.应用程序依赖于静态定义的权限(即/.default
在v2或resource
上的V1)不应该使用prompt=consent
为每个登录请求。 Instead, the application should:相反,应用程序应该:
prompt=consent
.在没有prompt=consent
执行登录。scope
parameter of the response :检查响应的scope
参数:
prompt=consent
.如果没有(例如,如果在用户最初同意应用程序后将新权限添加到所需权限列表中),则只有这样,用户才能再次被发送回,这次使用prompt=consent
。This strategy ensures that users can sign in to an app when an administrator has consented on their behalf (eg 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.此策略确保用户可以在管理员代表他们同意时登录应用程序(例如,因为他们无权自行同意),并且仅强制同意提示(或升级到管理员同意)代表他们)配置新权限时。
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).如果目标只是通知用户应用程序已被授权行使哪些权限(由用户先前授权,或由代表用户的管理员授权),则使用prompt=consent
不是一个好方法。
Instead, an application can use the scope
parameter of the token response to construct the desired interrupt experience (eg 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.相反,应用程序可以使用令牌响应的scope
参数来构建所需的中断体验(例如,在用户被重定向回应用程序并检索到令牌之后,但在继续之前),通知用户它的权限已被授予。
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.当应用程序要求用户同意所请求的权限,但不希望接受管理员代表用户授予的同意时,可能存在非常特殊的情况。
In this case, using prompt=consent
in all sign-ins could be used, but there are important caveats to consider:在这种情况下,可以在所有登录中使用prompt=consent
,但有一些重要的警告需要考虑:
prompt=consent
(and if consent was already previously granted, they will not be prompted for consent).由于这是一个查询参数,知识渊博的用户可以很容易地在请求发出之前拦截它,并删除prompt=consent
(如果之前已经授予同意,则不会提示他们同意)。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.在这种情况下,应用在用户登录后实现单独的同意授予体验可能更好(类似于前面描述的“通知”场景),将应用的附加同意要求与 Microsoft 提供的同意体验分开身份平台。
prompt=consent
triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.prompt=consent
在用户登录后触发 OAuth 同意对话框,要求用户授予应用程序权限。
Individuals accessing an app that requires at least one permission that is outside their scope of authority.访问至少需要一项超出其权限范围的权限的应用程序的个人。
Admins will see the same prompt show the permission and will see an additional control on the traditional consent prompt that will allow them consent on behalf of the entire tenant.管理员将看到显示权限的相同提示,并将看到对传统同意提示的额外控制,这将允许他们代表整个租户同意。
Users will be blocked from granting consent to the application, and they will be told to ask their admin for access to the app.用户将无法同意该应用程序,并且他们将被告知要求他们的管理员访问该应用程序。
For more details, you could refer to this article .更多细节,你可以参考这篇文章。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.