Azure AD inconsistencies

[MasterLambaster]

I've tried to use Auzre AD auth form the next(version 4.0.0-beta.2) branch and came across some inconsistencies that it'd like to share.

Azure setup is for accounts withing organization only, i.e no personal user accounts are permitted. Implicit and hybrid flows are disabled. API/Permissions configured like that:

Essentially it's a setup with default options and additional permissions.

So lets take example from the doc

providers: [
  AzureADProvider({
    clientId: process.env.AZURE_CLIENT_ID,
    clientSecret: process.env.AZURE_CLIENT_SECRET,
    tenantId: process.env.AZURE_TENANT_ID,
    scope: 'offline_access User.Read',
  }),
],

The result is oauth_callback_error expected 200 OK, got: 403 Forbidden.
I've dig a bit and the response form azure was {"code":"Authorization_RequestDenied","message":"Insufficient privileges to complete the operation."}. Then I took a look on the auth url and it was https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?response_mode=query&client_id=...&scope=openid. The scope was not the part of the original request, I've tried couple other options but they did not work either so i ended up changing the url.

Once that been done auth request url is https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?response_mode=query&scope=openid%20User.Read&....
Then i've got the following error

[next-auth][error][OAUTH_CALLBACK_ERROR]
https://next-auth.js.org/errors#oauth_callback_error userinfo sub mismatch, expected <code>, got: undefined 

That's an interesting one, according to this discussion https://github.com/MicrosoftDocs/azure-docs/issues/28317 https://graph.microsoft.com/v1.0/me/ endpoint does not have sub property. The only endpoint that have that sub property is https://graph.microsoft.com/oidc/userinfo but its format is incompatible with the format that's used in the provider profile parser. It uses email, name etc in opposite to displayName, userPrincipalName on the me endpoint.
I'm not sure is it due to the account type differences or due to some other reasons.

Changing user info endpoint https://graph.microsoft.com/oidc/userinfo and updating profile callback makes it work. So the final look is something like

return {
    id: "azure-ad",
    name: "Azure Active Directory",
    type: "oauth",
    scope: 'https://graph.microsoft.com/user.read',
    authorization: `https://login.microsoftonline.com/${tenant}/oauth2/v2.0/authorize?response_mode=query&scope=openid User.Read`,
    token: `https://login.microsoftonline.com/${tenant}/oauth2/v2.0/token`,
    userinfo: "https://graph.microsoft.com/oidc/userinfo",
    profile(profile) {
      return {
        id: profile.email,
        name: profile.name,
        email: profile.email,
        image: profile.picture,
      };
    },

    options
  };

While working on this post I've started getting another error oauth_callback_error expected 200 OK with body but no body was returned but it might be a whole different story 😭

So can anyone confirm that next version Azuer AD works fine and what's your configuration?

[balazsorban44]

Unfortunately, I/we cannot confirm each and every Provider config as stated in #2524

There are just so many, so we kind of rely on the community to help us migrate them. Most of the providers have never been tested since they have been added, so it is highly likely, that some of them may have never even worked... 👀

[panigrah]

Here is mine. I gave up trying to use the built-in module. So I just call the below.
The module was ignoring the scope I updated in options and that only happens when authorization was initialized as an url instead of an object. So I send in the scope

const tenant = 'common' //or put in your tenant
providers: [{
      id: "azure-ad",
      name: "Azure Active Directory",
      type: "oauth",
      authorization: { // *** CHANGED ***
        url: `https://login.microsoftonline.com/${tenant}/oauth2/v2.0/authorize?response_mode=query`,
        params: {
           scope: 'openid email profile user.read offline_access'
        } 
      },
      token: `https://login.microsoftonline.com/${tenant}/oauth2/v2.0/token`,
      userinfo: "https://graph.microsoft.com/oidc/userinfo", /**** CHANGED ****/
      profile(profile) {
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: profile.picture
        }
      },
      options: {
        clientId: '*** UPDATE *****',
        clientSecret: '*** UPDATE *****',
      }
    }]

[MasterLambaster]

@balazsorban44 nextauthjs/docs#33

[inu4g0t]

@MasterLambaster From my investigation, the root cause is the scope parameter in the add provider is not really affective.
But the https://graph.microsoft.com/v1.0/me/ actually require User.Read scope.
Your change will made it work but the user will not be able to extend the scope when they need.
You can check my link for detail #2524 (comment)

[WilliamHartman]

I am getting undefined for the authorization url no matter how I try it. I copied it exactly like you have it, hard coded 'common' in, hardcoded my tenant id in, changed authorization to just be a string like in the OP. Same error every time.

[next-auth][error][get_authorization_url_error] https://next-auth.js.org/errors#get_authorization_url_error TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string. Received undefined

[...nextauth].js code is as follows right now

import NextAuth from "next-auth"

export default NextAuth({
  providers: [{
    id: "azure-ad",
    name: "Azure Active Directory",
    type: "oauth",
    authorization: {
      url: 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_mode=query',
      params: {
         scope: 'openid email profile user.read offline_access'
      } 
    },
    token: 'https://login.microsoftonline.com/common/oauth2/v2.0/token',
    userinfo: "https://graph.microsoft.com/oidc/userinfo", 
    profile(profile) {
      return {
        id: profile.sub,
        name: profile.name,
        email: profile.email,
        image: profile.picture
      }
    }
  }]
})

[balazsorban44]

@WilliamHartman make sure you use the correct version, you might be on v3.

[haydenisler]

Wanted to jump in here and say the OP of this comment helped me with my issue. The solution that ended up working for me is detailed here: #2772 (comment)

[mhilland]

thanks for addressing this guys, i ran into the same issue this morning when upgrading to v4. i ended up figuring this out on my own and wish i had found this thread sooner! however, there are some concerns that i still have with this solution:

a) there is no user ID returned anymore when using the new /userinfo endpoint. i feel like this is important to have, especially when you might need to do user-specific operations with an API. and according to the docs, you cannot extend this payload: https://docs.microsoft.com/en-us/azure/active-directory/develop/userinfo#notes-and-caveats-on-the-userinfo-endpoint

b) i'm still only seeing the openid scope being affixed to my authorization URL request parameters, no matter what i pass into the authorization object. in fact, if you look at line 72 of the client.js code for the openid-client module, you can see that its passing its own scope there, which seems to override any of the ones in the provider configuration. i can see this being an issue when you need to provide additional scopes for more granular access control.

[balazsorban44]

using idToken: true will skip the userinfo endpoint, and parse the returned id_token which in any case is available in its raw form in the account (either in the jwt callback or in the Account db table if you use an adapter)

I believe openid is a required scope in all case, if you use an OIDC compliant provider.

[panigrah]

@mhilland can you use the profile.sub as the id - that is supposed to be the unique identified for the user.

Also the profile() call back is an async method - so you could in theory make an additional call to the other https://.../me endpoint inside this callback to populate additional attributes if needed.

[balazsorban44]

Yes, profile.sub is great for id. And it is async exactly for scenarios where you need to fetch more data from other places. we give you the tokens (like access_token) in that callback

[balazsorban44]

Azure AD is fixed now, see: #2524 (comment)