AADSTS65001: The user or administrator has not consented to use the application with ID '<uuid>' named '<name>'. Send an interactive authorization request for this user and resource

[mcarleio]

Environment

• Spring boot starter

  • active directory spring boot starter

• OS Type: Linux

• Java version:

  • 11

Summary

We are using the AppRole approach (see also #874). This was working with version 2.2.2 and stopped working with 2.2.3/2.2.4 with the following message (replaced some values): AADSTS65001: The user or administrator has not consented to use the application with ID '<uuid>' named '<name>'. Send an interactive authorization request for this user and resource.

Reproduce steps

We followed the steps here https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps to setup the appRoles in the manifest like this:

    "appRoles": [
        {
            "allowedMemberTypes": [
                "User"
            ],
            "description": "<some description>",
            "displayName": "WFS User",
            "id": "<uuid>",
            "isEnabled": true,
            "lang": null,
            "origin": "Application",
            "value": "WFS_USER"
        }
    ]

After this, we assigned a group to that role, so that everyone in that group will have the role.

In our project we added the library, configured the HttpSecurity and added some configs to application.yml

Expected Results

A user of the above configured group starts SSO and should be able to login. This is working like a charm with version 2.2.2.

Actual Results

With version 2.2.4 we get this exception (replaced some values):

Caused by: com.microsoft.aad.msal4j.MsalInteractionRequiredException: AADSTS65001: The user or administrator has not consented to use the application with ID '<uuid>' named '<name>'. Send an interactive authorization request for this user and resource.
Trace ID: <uuid>
Correlation ID: <uuid>
Timestamp: 2020-05-18 08:51:23Z
    at com.microsoft.aad.msal4j.MsalServiceExceptionFactory.fromHttpResponse(MsalServiceExceptionFactory.java:40)
    at com.microsoft.aad.msal4j.TokenRequest.executeOauthRequestAndProcessResponse(TokenRequest.java:109)
    at com.microsoft.aad.msal4j.ClientApplicationBase.acquireTokenCommon(ClientApplicationBase.java:163)
    at com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier.execute(AcquireTokenByAuthorizationGrantSupplier.java:52)
    at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:57)
    at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:17)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
    at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
    at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)

[saragluna]

Thanks for reporting this, we'll look into it ASAP.

[yiliuTo]

Hi, @mcarleio. I have done the reproduced steps as you mentioned with version 2.2.4 while I cannot reproduce your issue. Therefore, would you like to share your manifest and other configurations about your AAD? For example, the API permissions of your app registration, are they be consented by the admin and if they match the scope parameter of the authentication request url or not? If there are any other customized configurations related with AAD and the authentication progress, would you like to share them together?

[mcarleio]

Hi @yiliuTo Sorry for late answer. Regarding the manifest I can only share it with a lot of escaped data. I will try to reproduce this behaviour the next days with a small sample application.

Forgot to mention: In version 2.2.2 nobody had any problem to SSO. In version 2.2.4 anybody (except myself) got the upper exception. Maybe I have some special role, as I created the application in Azure AD and setup everything. So, could you please check if you can reproduce the error, when you SSO with a different user?

[yiliuTo]

Thanks for your information, @mcarleio , I will try to reproduce it and look into this issue.

[mcarleio]

Ok, I probably found the problem causing this: Under API permissions, we have "User.Read.All" but not "User.Read". For some reason this was working with versions prior to 2.2.4. I am not 100% sure, as I am waiting for some admin to add the "User.Read" permission and grant it, but in my small demo application, this was the factor to reproduce the error.

[yiliuTo]

Hi @mcarleio . Do you mean you use "User.Read.All" instead of "User.Read" and then version 2.2.4 gets the exception of "AADSTS65001"? Besides could you share how you use the AppRole approach? I tried to reproduce your issue using both the stateless sample and integration test of 2.2.4 and adding API permission of "User.Read.All", but sadly I still cannot get this exception.

[mcarleio]

Hi @yiliuTo .

Do you mean you use "User.Read.All" instead of "User.Read" and then version 2.2.4 gets the exception of "AADSTS65001"?

Yes. When we created the application in Azure AD, we removed "User.Read" and added "User.Read.All" and "Directory.AccessAsUser.All" and granted them by admin. This was working until we updated to version 2.2.4, which resulted in the upper AADSTS65001 exception.

We could fix this by readding "User.Read" and grant it by admin:

Regarding the AppRole approach I have to check how we are using that. But as we only have one AppRole defined, I think we just it as a filter i.e. when a user signs in and is not part of that AppRole, Azure AD does not let him access the application. But I am not 100% sure.

Nevertheless, the error was not an error, but a misconfiguration of Azure AD on our side, thank you nevertheless for your great support :-)

Best regards Marcel