Azure 活动目录双重同意，非确定性流

Question

I have an app registration in Azure with the following configured permissions:

From within my application, I start an oauth flow with the following url (redacted params with XXXXXXX):

https://login.microsoftonline.com/common/oauth2/authorize
     ?client_id=XXXXXXX
     &grant_type=client_credentials
     &redirect_uri=XXXXXXX
     &resource=https%3A%2F%2Foutlook.office365.com
     &response_type=code&scope=openid+email+profile+full_access_as_app
     &state=XXXXXXX

My user gets the same consent screen twice (notice the different URLs):

and then:

Then they are redirected to the redirect_url .

In the callback, most of the times I get:

access_denied | AADSTS650051: Claim is invalid: User.Read does not exist in client application's RequiredResourceAccess.

And the application is not added in the list of authorized applications for the user in Azure Portal.

However, sometimes the flow works.

What seems to be the relevant part from the application manifest is:

"oauth2Permissions": [
    {
      "adminConsentDescription": "Allow the application to access XXXXXX on behalf of the signed-in user.",
      "adminConsentDisplayName": "Access XXXXXX",
      "id": "XXXXXX",
      "isEnabled": true,
      "lang": null,
      "origin": "Application",
      "type": "User",
      "userConsentDescription": "Allow the application to access XXXXXX on your behalf.",
      "userConsentDisplayName": "Access XXXXXX",
      "value": "user_impersonation"
    }
  ],

Questions:

1. Why do they get the same consent dialog twice? Can I avoid it?
2. Any idea what might be wrong with my setup and the flow works non-deterministicly?

Answer 1

reading your answer again, it may be that you didn't have issues with the things I mentioned. But I'll leave it here in case it helps you anyway. Please do comment if you have further questions

Your config and URL look odd. Do you want to access the API as a user or as an app? Currently you have both.

Your authorize URL sets grant type to client credentials which does not make sense (frankly I'd expect AAD to error on this but I guess response type of code makes it use authorization code flow). Client credentials is a pure back-end flow and does not involve users, so it shouldn't be used in a redirect.

If you want to use the application permission correctly, you'll need to simplify your approach. Here are the docs for client credentials flow with the v2 endpoint: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow . If your app is multi-tenant, you'll need to do consent for your app like you are doing now, before you can actually use the flow. But, if it is only used in your org, you (or an admin) can consent to your permissions in the portal and you can then use the flow right away.

You acquire the token with an HTTP call, including your app's credentials + what you want the token for. With v2, the scope here should be the app ID / app id URI for Exchange + .default . I couldn't find a good reference for this regarding Exchange with a quick Google search, but I'll try to check again in a bit once I have my computer open.

Answer 2

I reproduced your issue yesterday, but today it works fine without any changes. You can try again. If this issue still exists, just let me know.

By the way, grant_type parameter isn't needed in the auth url, you can take a look at @junnas's answer.

Reference:

The differences between Application permissions and Delegated permissions