3
votes

I have registered an app with apps.dev.microsoft.com

And set its permissions to this: Screen shot from apps.dev.microsoft.com panel

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

I set the scope to: scope=https://graph.microsoft.com/.default

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

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?

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

1
Couple of questions: 1) Have you gone through the Admin Consent process? 2) Can you provide the full URL you're using (minus your actual client id) 3) Can you provide the response you're getting during authentication? - Marc LaFleur
@MarcLaFleur-MSFT: 1. There is no need for admin consent process, since my user is the owner of the application. Or am I mistaken? 2.) I am calling login.microsoftonline.com/#{tenant}/oauth2/v2.0/token with headers: 'Content-type' => 'application/x-www-form-urlencoded' and body: client_id: XYZ, scope: 'https://graph.microsoft.com/.default', client_secret: XZYY, grant_type: 'client_credentials' 3) for the call above I get no errors, but the JWT token does not contain permissions for Directory.ReadWrite.All. - Miha J
@MarcLaFleur-MSFT If I try with a scope of mentioned above I get: Message: 400, Bad Request, {\"error\":\"invalid_scope\",\"error_description\":\"AADSTS70011: The provided value for the input parameter 'scope' is not valid. The scope https://graph.microsoft.com/Directory.ReadWrite.All is not valid.... - Miha J
@MarcLaFleur-MSFT, I've re-consent the admin and now JWT has roles of: "roles": [ "User.ReadWrite.All", "People.Read.All", "Directory.ReadWrite.All", "User.Invite.All", "User.Read.All" ] but I still get back Authorization_RequestDenied. I tried to call POST to endpoint /schemaExtensions - Miha J
I also found this post here. Does the graph explorer currently supports the ability to add schemaExtensions to the User entity? I agree, that this is one time deal and no need to implement it to the application. - Miha J

1 Answers

6
votes

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.

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.

Please note that you will need to execute Admin Consent for Graph Explorer before this will work with your tenant first.

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.

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).