问题描述
我在 apps.dev.microsoft.com
并将其权限设置为:
我正在获得一个使用 Microsoft Graph API 的令牌，如下所示:
I am getting a token to use Microsoft Graph API like this:
https:///developer.microsoft.com/en-us/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 授权(又名App-Only Authentication")，它仅支持应用程序权限(其中 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)，那么您很可能一开始就不需要将其纳入您的应用程序.相反，请尝试使用 Graph Explorer 来创建它们.
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_credential 和 code 授权.如果您是销售商业解决方案的 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.
需要注意的是，您可以为两个 验证码、隐式和客户凭证 授予.根据您选择的授权，它将使用您定义的委托或应用程序权限.这使得上述场景非常简单.
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 的范围参数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！