How to use custom Azure AD scopes?

[itsthekeming]

I'm looking into converting a React app to use Next.js. One requirement of this app is that it uses Azure AD to authenticate users via @azure/msal-react. It accesses an external API that is set up to validate against a custom scope defined in Azure AD. To use this API, it needs an access token. I want to call this API on the server to take advantage of SSR.

With a custom scope, getting the access token looks something like this with MSAL:

const { accessToken } = pca.acquireTokenSilent({ scopes: [ 'api://<identifier>/My.Custom.Scope' ] })

We call this on demand and pass the result as a Bearer token to the API call. Works like a charm.

However, I'm having trouble figuring out how to do this with next-auth.

I am able to authenticate just fine with the following configuration, and even have it set up to add my access token to the JWT.

// pages/api/auth/[...nextauth.js]

import NextAuth from "next-auth";
import AzureAdProvider from "next-auth/providers/azure-ad";

export default NextAuth({
  secret: process.env.NEXTAUTH_SECRET,
  providers: [
    AzureAdProvider({
      clientId: process.env.AZURE_AD_CLIENT_ID,
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
      tenantId: process.env.AZURE_AD_TENANT_ID,
    }),
  ],
  callbacks: {
    async jwt({ token, account }) {
      const { picture, ...rest } = token;

      if (account) {
        rest.accessToken = account.access_token;
      }

      return rest;
    },
  },
});

I can then get my access token in getServerSideProps just fine as well:

const { accessToken } = await getToken({
  req: context.req,
  secret: process.env.NEXTAUTH_SECRET,
});

However, this access token does not have my custom scope. It has these scopes: Directory.AccessAsUser.All User.Read profile openid email. This makes sense because I did not configure my custom scope anywhere.

If I add it to my config, however:

AzureAdProvider({
    clientId: process.env.AZURE_AD_CLIENT_ID,
    clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
    tenantId: process.env.AZURE_AD_TENANT_ID,
    authorization: {
        params: {
            scope: 'api://<identifier>/My.Custom.Scope'
        }
    }
})

I get the following error upon attempting to sign in:

https://next-auth.js.org/errors#oauth_callback_error expected 200 OK, got: 401 Unauthorized

With MSAL, one has to request tokens custom after the initial login because you cannot mix and match Microsoft/OpenID scopes with custom scopes. But in next-auth, it seems that the token is frozen once it's issued, and it doesn't seem like I can get the initial token with my custom scope because it needs those other scopes to authenticate properly.

Is there a way I could request a new token as needed with the custom scope as I do in MSAL? I did look over #2068 but was unsure how I would "sign in" again on the server with the new scope since the server is where I'd to perform the API call.

[danielweil]

Have you found a solution?

[itsthekeming]

I have not, though I haven't fiddled with it in the last couple of weeks. My best guess is to somehow call the login flow again with the new scopes but I'm not sure how that would work with there being two sessions. Will probably wait until 4.0 is out of beta and see what I can hack together then.

[manoj-mukherjee-maersk]

Same problem. are you got any solution?

[aliblack89]

Same problem here. Did you manage to make any progress or did you go back to using MSAL? @itsthekeming

[itsthekeming]

Sorry all, I have not yet found a solution. I also haven't looked at this in a couple of months.

The best I was able to hack was have next-auth and MSAL live side by side. Next-auth performed the initial authentication, while MSAL took over subsequent calls to the API. I didn't have to log in twice. It appeared that MSAL was able to recognize that the user was already authenticated from next-auth.

One option I wondered about was whether or not our custom scope is actually necessary. We only have one, and I believe it was configured more out of convention than actual need. Of course that doesn't help those who have this issue and actually utilize scopes.

[peter-olom]

I have implemented same and it worked. I believe your solution lies in how you pass in the scope.
example:

AzureADProvider({
      clientId: process.env.AZURE_AD_CLIENT_ID || "",
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET || "",
      tenantId: process.env.AZURE_AD_TENANT_ID,
      authorization: {
        params: {
          scope:
            "Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Calendars.ReadWrite.Shared",
        },
      },
    })

The scopes should be separated by spaces if more than one.
Also ensure you have specified the scopes in the Apps API Permission section in Azure Portal.

[itsthekeming]

Were you able to pass custom scopes alongside the predefined Graph scopes?

[manoj-mukherjee-maersk]

Is it possible fetch two token one for api and one for graph api?

[itsthekeming]

So after many months of looking at this on and off, I think I came to a solution that works for my use case.

Using the on-behalf-flow, we added an endpoint to our API that fetches the user info itself. I can't recall the implementation of that endpoint at the moment, but it calls the Graph API. We can then configure our authentication to only use our custom scope for our API, and call the endpoint we created as our userInfo endpoint.

I got a prototype working with remix and remix-auth, so I'm not sure the exact details of how to get it to work with next-auth, but this solved our issue. Happy to try and answer any further questions people have about this potential solution.

[stephen776]

Is there any way you can share your solution for remix-auth. I am running into the exact same problem I believe

[zmartell]

What kind of scopes are you looking for? I pull in Security groups they belong to, so i can define Roles just fine, and I pull in profilephoto. (my scope is "openid profile User.Read email", and the User.Read gives me the security group IDs.

Are you looking just to use it for Authentication stuff which is the purpose of next-auth, or are you looking to make it a real MSGraph api?

[manoj-mukherjee-maersk]

We solved the issue by after login calling msal-node with scope and store next-auth store two access token one for graph api another for custom backend.

[egreb]

@manoj-mukherjee-maersk Can you please provide an example?

[dmitryzelenkin]

const options = {
  providers: [
    AzureADProvider({
      clientId: process.env.AZURE_AD_CLIENT_ID,
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
      tenantId: process.env.AZURE_AD_TENANT_ID,
      authorization: {
        params: {
          scope: "openid profile email api://backend_client_id/access_as_user"
        }
      },
    }),
  ],
  site: process.env.NEXTAUTH_URL,
  session: { strategy: "jwt" },
  debug: true,
  callbacks: {

    async jwt({ token, user, account, profile, isNewUser }) {
      profile && (token.roles = profile.roles);
      if (account) {
        token.accessToken = account.access_token;
      }
      return token
    },
    async session({ session, user, token }) {
      session.user = token;
      return session
    }
  }
}

export default (req, res) => NextAuth(req, res, options)

[manoj-mukherjee-maersk]

@egreb Here how we generate two token.

import NextAuth from "next-auth";
import AzureADProvider from "next-auth/providers/azure-ad";
import * as msal from "@azure/msal-node";
import { JWT } from "next-auth/jwt";
import { NextApiRequest, NextApiResponse } from "next";

const clientId = process.env.AZURE_AD_CLIENT_ID;
const clientSecret = process.env.AZURE_AD_CLIENT_SECRET;
const tenantId = process.env.AZURE_AD_TENANT_ID;

// Construct a request object for auth code

const authority = `https://login.microsoftonline.com/${tenantId}`;

const config = {
  auth: {
    clientId: clientId || "",
    authority,
    clientSecret: clientSecret || "",
    knownAuthorities: [authority],
  },
  system: {
    loggerOptions: {
      loggerCallback(loglevel, message, containsPii) {
        console.log(message);
      },
      piiLoggingEnabled: false,
      logLevel: msal.LogLevel.Verbose,
    },
  },
};

const cca = new msal.ConfidentialClientApplication(config);

const generateApiAccessToken = async (refreshToken) =>
  await cca
    .acquireTokenByRefreshToken({
      scopes: [`api://${clientId}/APIScope`],
      refreshToken,
    })
    .catch((err) => console.log(err));

async function refreshAccessToken(token: JWT) {
  try {
    const tokenUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token?`;

    let formData = {
      client_id: clientId,
      grant_type: "refresh_token",
      client_secret: clientSecret,
      refresh_token: token.refreshToken,
    };

    const encodeFormData = (data) => {
      return Object.keys(data)
        .map((key) => encodeURIComponent(key) + "=" + encodeURIComponent(data[key]))
        .join("&");
    };

    const response = await fetch(tokenUrl, {
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
      },
      method: "POST",
      body: encodeFormData(formData),
    });

    const refreshedTokens = await response.json();

    if (!response.ok) {
      throw refreshedTokens;
    }

    const refreshToken = refreshedTokens?.refresh_token as string;
    if (refreshToken) {
      token.apiTokenDetails = await generateApiAccessToken(refreshToken);
    }

    return {
      ...token,
      idToken: refreshedTokens.id_token,
      graphAccessToken: refreshedTokens.access_token,
      accessTokenExpires: Date.now() + refreshedTokens.expires_in * 1000,
      refreshToken: refreshedTokens.refresh_token ?? token.refreshToken, // Fall back to old refresh token
    };
  } catch (error) {
    console.log(error);
    return {
      ...token,
      error: "RefreshAccessTokenError",
    };
  }
}

// For more information on each option (and a full list of options) go to
// https://next-auth.js.org/configuration/options
export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  return await NextAuth(req, res, {
    // https://next-auth.js.org/configuration/providers
    providers: [
      AzureADProvider({
        // @ts-ignore
        clientId: clientId,
        // @ts-ignore
        clientSecret: clientSecret,
        tenantId,
        authorization: {
          params: {
            scope: "User.Read openid email profile offline_access",
          },
        },
      }),
    ],
    // The secret should be set to a reasonably long random string.
    // It is used to sign cookies and to sign and encrypt JSON Web Tokens, unless
    // a separate secret is defined explicitly for encrypting the JWT.
    secret: process.env.NEXTAUTH_SECRET,

    session: {
      // Use JSON Web Tokens for session instead of database sessions.
      // This option can be used with or without a database for users/accounts.
      // Note: `strategy` should be set to 'jwt' if no database is used.
      strategy: "jwt",

      // Seconds - How long until an idle session expires and is no longer valid.
      maxAge: 30 * 24 * 60 * 60, // 30 days

      // Seconds - Throttle how frequently to write to database to extend a session.
      // Use it to limit write operations. Set to 0 to always update the database.
      // Note: This option is ignored if using JSON Web Tokens
      // updateAge: 24 * 60 * 60, // 24 hours
    },
    callbacks: {
      async jwt({ token, user, account, profile, isNewUser }) {
        // Persist the OAuth access_token to the token right after signin
        if (account && account.access_token && account.expires_at) {
          token.graphAccessToken = account.access_token;
          token.idToken = account.id_token;
          token.refreshToken = account.refresh_token;
          token.accessTokenExpires = account.expires_at * 1000;
        }
        // Return previous token if the access token has not expired yet
        // @ts-ignore
        if (Date.now() < token.accessTokenExpires) {
          token.apiTokenDetails = await generateApiAccessToken(token.refreshToken);
          return token;
        }

        // Access token has expired, refresh it
        return refreshAccessToken(token) ?? {};
      },
      async session({ session, token, user }) {
        // Send properties to the client, like an access_token from a provider.
        session.graphAccessToken = token.graphAccessToken;
        session.apiTokenDetails = token.apiTokenDetails;
        return session;
      },
    },
  });
}

[trm217]

This issue still persists in Next-Auth v5, as of now.
It's still not possible to request a second access token via a Next-Auth functionality.
The use case of logging in with (for example Azure Entra ID) to the MS Graph Client (for receiving MS user
data), and then using a second client (registered in Azure) as the API is quite common.
Would be really nice to see a solution for this in Next-Auth 😃