设置Microsoft Graph的范围参数 [英] Set the scope parameter for 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_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.
要注意的一件事是,您可以为 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屋!