0
votes

I'm trying to develop an app in my enterprise and I've followed this tutorial to get access to the AD users information. Meaning:

  1. I created an app in https://apps.dev.microsoft.com/
  2. I set User.Read.All in Application Permissions and User.Read in Delegated Permissions

With this done I'm able to successfully login (Azure AD OAuth2 with https://graph.microsoft.com/ as resource and User.Read as scope) and get a correct response from https://graph.microsoft.com/v1.0/me.

  1. Ask the Admin for the Delegated Permissions

With this, my admin can see in the azure portal that my App has both permissions consented by himself.

This is working because I asked a coworker to log in and I could get a correct response from https://graph.microsoft.com/v1.0/me even though he wasn't even prompted to consent this (Before the admin consenting the permissions the user was prompted)

  1. Request a token from https://login.microsoftonline.com/common/oauth2/token with client_credentials as a response_type

  2. Receive the token!

  3. Do a GET request to https://graph.microsoft.com/v1.0/users and receive:

    {
        "error": {
            "code": "Authorization_IdentityNotFound",
            "message": "The identity of the calling application could not be established.",
            "innerError": {
                "request-id": "b2d9ec62-0b65-44eb-9e0f-4aec52b45750",
                "date": "2017-03-22T19:19:48"
            }
        }
    }
    

Furthermore, doing a request to https://graph.microsoft.com/v1.0/me returns:

{
  "error": {
    "code": "BadRequest",
    "message": "Current authenticated context is not valid for this request",
    "innerError": {
      "request-id": "047e2ba9-a858-45fc-a0dd-124e1db503f3",
      "date": "2017-03-22T19:39:25"
    }
  }
}

Which leads me to believe that Microsoft knows this token and knows it is not impersonating any user.

I've been looking for documentation on Azure AD and Microsoft Graph authentication but I only find blog posts and all seem outdated (although most features are in preview). If you could point me in the right direction I would thank you.

I've also found this and this similar questions on SO but they all remain unanswered.

Update, after this answer

Thank you, Dan, I've used my organization domain name and I'm also able to get a token.

Now the response from https://graph.microsoft.com/v1.0/users/ is:

{
  "error": {
    "code": "Authorization_RequestDenied",
    "message": "Insufficient privileges to complete the operation.",
    "innerError": {
      "request-id": "3f190b47-73f5-4b29-96f9-54ed3dbc3137",
      "date": "2017-03-23T11:07:15"
    }
  }
}

Which makes no sense because in the azure portal I have User.Read.All as Application Permission (already consented by the admin).

I think the problem is with the request for the token, that returns successfully no matter the scope I send, even if I made one up.

For Example:

POST https://login.microsoftonline.com/<domain>/oauth2/token

client_id:*******
client_secret:*******
resource:https://graph.microsoft.com/
grant_type:client_credentials
scope:Foo.Bar

Returns:

{
  "token_type": "Bearer",
  "expires_in": "3599",
  "ext_expires_in": "0",
  "expires_on": "1490271617",
  "not_before": "1490267717",
  "resource": "https://graph.microsoft.com/",
  "access_token": *****
}
2

2 Answers

4
votes

I had two problems, both not covered documentation:

  • For client credentials, if the app belongs to a work or school (organization) context then for https://login.microsoftonline.com/common/oauth2/token replace common with a tenantId or domain name (thanks to Dan Kershaw)

  • For https://graph.microsoft.com/v1.0/users or https://graph.microsoft.com/v1.0/users/{id | userPrincipalName} you need Directory.Read.All permission.

Note:

  • User.Read.All is relevant for Microsoft to stop requesting permissions (delegation) to the user when you ask for User.Read in the OAuth workflow. Check this and other Permission related issues in the Release Notes.
  • I've added this issue to the Microsoft Graph Docs!
1
votes

The /me segment is a shortcut or alias for the currently signed-in user. The request to /me will never work with an application token, because it doesn't contain any user context (or signed in user) - and hence the error. We might be able to improve this error though ;)

I believe when using the client credentials flow, you need to specify the actual tenant that you want a token for.

If you're app is performing this operation in a work or school (organization) context then for https://login.microsoftonline.com/common/oauth2/token replace common with a tenantId or domain name, and see if that works.

If you are following https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds it looks like we might have a couple of doc bugs in there that we need to fix...

Hope this helps,