设置Microsoft Graph的范围参数 [英] Set the scope parameter for Microsoft Graph

查看:102
本文介绍了设置Microsoft Graph的范围参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经在apps.dev.microsoft.com

并为此设置权限:

我正在获得使用Microsoft Graph API这样的令牌:

I am getting a token to use Microsoft Graph API like this:

https://developer.microsoft.com/zh-CN/graph/docs/concepts/auth_v2_service#4-get-an-access-token

我将范围设置为:scope=https://graph.microsoft.com/.default

我没有获得Directory.ReadWrite.All许可就获得了令牌.

I get back a token without Directory.ReadWrite.All permission.

如何修改请求以使用apps.dev.microsoft.com门户网站下指定的权限取回令牌?我应该更改范围参数吗?

How can I modify the request to get back the token with permission specified under apps.dev.microsoft.com portal? Should I change the scope parameter?

我尝试了graph.microsoft.com/directory.readwrite.all的在线建议,但没有任何运气.

I tried with graph.microsoft.com/directory.readwrite.all as suggest online, without any luck.

推荐答案

要使用schemaExtentions,您需要Directory.AccessAsUser.All范围.但是,这里的问题是您正在使用client_credentials授予(也称为仅应用程序身份验证"),该授予仅支持应用程序权限(Directory.AccessAsUser.All不是其中一个).

To use schemaExtentions you need the Directory.AccessAsUser.All scope. The problem you have here however is that you're using the client_credentials grant (aka "App-Only Authentication") which only supports Application Permissions (of which Directory.AccessAsUser.All isn't one).

为了使用任何委派的权限,您需要对用户进行身份验证,而不仅仅是对应用程序进行身份验证.委派权限就是用户在一段时间内委派(又称为转移/分配)给您的应用程序的权限.

In order to use any of the Delegated Permissions, you need to authenticate a user rather than just the application. Delegated permissions are just that, permissions a user has delegated (aka transferred/assigned) to you application for a period of time.

这里有两个选项.如果您遇到的唯一问题是schemaExtentions,并且您没有出售商业解决方案(ISV),则很可能不需要首先将其烘焙到您的应用程序中.而是尝试使用图形浏览器来创建它们.

There are a couple of options here. If the only issue you're running into is with schemaExtentions and you're not selling a commercial solution (an ISV), you most likely don't need to bake this into your application in the first place. Instead, try using Graph Explorer to create them.

请注意,您需要先执行Graph Explorer的管理同意书,然后才能与您的租户一起使用.

另一个选择是在应用程序中同时支持client_credentialcode授予.如果您是销售商业解决方案的ISV,这可能是最好的选择.执行此操作最干净的方法是拥有一个由管理员执行的设置"应用程序.管理员使用code授予对自己进行身份验证,然后创建所有需要的扩展名.此过程的好处是,它提供了一个干净而合乎逻辑的地方,可以启动您需要用于生产应用程序的client_credential补助金的管理员同意书.

Another option is to support both client_credential and code grants in the application. If you're an ISV selling a commercial solution, this is likely the best bet. The cleanest way to execute this is to have a "setup" app that is executed by an Administrator. The Admin authenticates themselves using a code grant and you create all of the needed extensions. The bonus of this process is that it provides a clean and logical place to kick off the Admin Consent for the client_credential grant you're going to need for the production application.

要注意的一件事是,您可以为 Auth使用相同的应用程序ID代码隐含

One thing to note is that you can use the same App ID for both Auth Code, Implicit, and Client Credential grants. Depending on the grant you select it will use either the Delegate or Application permissions you defined. This makes the above scenario pretty straightforward.

不幸的是,注册UX在显示委托和应用程序权限的应用方式方面做得并不出色,导致许多用户认为这两个集合始终都在使用.实际上,根据所使用的赠款类型,每一套都适用.一个例外是管理同意书",它同意所有请求的权限(即,您不需要单独的委托"和应用程序"同意流).

The registration UX unfortunately doesn't do a great job of surfacing how delegate vs application permission are applied, leading many users to assume both sets are always being used. In reality, only one set is every applicable depending on the grant type in use. The one exception to this is Admin Consent which consents to all of the permissions requested (i.e. you don't need separate Delegate and Application consent flows).

这篇关于设置Microsoft Graph的范围参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆