Error during login "AADSTS901002: The 'resource' request parameter is not supported"

With code version 8.x-1.x-dev (commit 97947a224f / updated 21 Jul 2020 at 16:44 UTC) works fine using v2.0 + either Windows Graph 1.0 or Azure Graph 1.6, although you might get a message that email couldn't be retrieved from token, but that should be fixed on the Azure side if possible.

@kevin-w Currently this module does not officially support the Microsoft identity platform (v2.0). It was designed for Azure AD (v1.0). However with that said it may still work if you keep your configuration simple (meaning don't set options like group mapping, etc) and choose 'Alternate or no user endpoint' and set the custom endpoint to be blank. This should remove the resource parameter from being sent in the request. I'm not sure if additional claims will be needed though in order to get the proper data returned in the id token.

Let me know if this happens to work for you? We should probably try to work on some v2.0 integration but I haven't required it yet myself and I have also not had to use the common endpoints yet and have only worked with tenant specific so far.

I've just had the same issue and stumbled upon this issue https://www.drupal.org/project/openid_connect_windows_aad/issues/3040473 first instead of this one.

I just submitted a patch to remove those lines from the retrieveTokens function but I will give it a go now and see if it works by changing 'resource' to 'scope' as mentioned above.

Though if v1 needs 'resource' and v2 needs 'scope' there's a bit more work to be done I guess to check which API it's using.

I've checked it and now getting a different error:
{"error":"invalid_scope","error_description":"AADSTS70011: The provided request must include a 'scope' input parameter. ...

So it's now missing a scope parameter. I'll leave mine completely removed for now as I don't see why it's needed anyway as the function is just to 'retrieve tokens', unless I'm missing something.

Hi @oldspot, yes as mentioned the module does not currently support v2. To properly implement its definitely not as simple as replacing a parameter or two. We also don't want to do away with v1 implementation either. With v2 comes an entirely different auth workflow and scopes are used to progressively request access to additional resources as needed where resources are tied to various scopes, permissions, etc. For example Microsoft graph api has various scopes including user.read. In our case where we are logging in and want to know info about the user we want to request the scope user.read. In the Azure AD your app registration would be configured to use the user.read permissions. There are many layers to MS Azure AD auth that are beyond any conversation here.

Hopefully we'll eventually get to adding v2 functionality to this module, but it will be quite a bit of work and will take one of us maintainers to dedicate a significant amount of time to. I don't see this being added in the short term unfortunately.

There are a few v2 issues but I'll post this here as it already contains the minimal information required.

To get this working with v2 for basic SSO (including email address) this is what we did:

• Use the latest dev version of openid_connect_windows_aad
• Add code to support scope as @Kevin W mentioned in #2 (you may want to support v1 and v2 though)
• Use Windows Graph API
• No User Claims Mapping
• Enable "Override registration settings"

This assumes you've set up Azure AD correctly. I don't have knowledge of that side of things.

I've used the steps in #8 which made the SSO implementation with Azure AD work.

Also created a patch file based on the dev release version 8.x-1.x-dev (commit 97947a224f / updated 21 Jul 2020 at 16:44 UTC) to use scope instead of resource.

According to https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permi... OpenID Connect scopes are openid, email, or profile
User.Read doesn't work with V2.

I guess it's better to this as config to let user choose the scope!

I've been having this issue & can confirm the patch in #10 resolves it for me, but not marking as RTBC as no idea if this is the best approach or might break in other use cases.

patch #10 resolved the following error for us:

```
Could not retrieve tokens. Details: Client error: `POST https://login.microsoftonline.com/XXXXXXX/oauth2/v2.0/token` resulted in a `400 Bad Request` response: {"error":"invalid_request","error_description":"AADSTS901002: The 'resource' request parameter is not supported.\r\nTrac (truncated...)
```

Thanks!

Hello @msti
you are using V1 or V2 of Azure AD ?
and did you check you have the correct permission in your app?

Here are the permissions we are using.

There is a v2.0 in the azure endpoint, so I assume we are using v2.
https://login.microsoftonline.com/XXXXXXX/oauth2/v2.0/authorize

For the patches provided in #9 and #10, why is the body of case 1 commented? The case 1 body pertains to Azure AD Graph and shouldn't affect the behavior of Microsoft Graph. This bug report is about Microsoft Graph.

Here's my patch which alters only case 2. As I explained in the previous comment, it's my observation that case 1 doesn't need to be altered, as is done in the earlier patches.

Please try version 2.0.0-beta1. It should fix the issue.