Node JS auth request validation

[jennyf19]

Node JS validation replacement for passport.js

Dear Node JS customers,

We understand that many of you have been frustrated by the lack of a replacement for this deprecated passport.js library. We want you to know that we hear your concerns and are actively working on a solution. In the meantime, we want to assure you that we haven't forgotten about you. Auth validation is very complicated and hard to get right. For this reason, we will leverage Microsoft.IdentityModel, which has a proven track record over many years, and is hitting impressive perf metrics with the latest improvements in IdentityModel 7x on .NET 8, making Ahead of Time (AOT) comparable with non-AOT, especially in terms of request per second, which is very promising for our goal of covering all services, regardless of language with Microsoft.IdentityModel.

We are experimenting with a simple wrapper over a shared library in Node JS that will allow you to continue using the Microsoft identity platforms. This wrapper is currently only available to internal Microsoft services, but we're working hard to make it available to all of our customers as soon as possible. Thank you for your patience and understanding as we work to improve our offerings. We'll keep you updated as we make progress on this front. Please provide us with your feedback/questions/concerns as we go through this process together.

[mdodge-ecgrow]

Thank you for the update.
So just to clarify, at this time we should continue to use the Microsoft Azure Active Directory Passport.js Plug-In until this new Identity Model wrapper is finished?

[jennyf19]

The passport.js plug-in was deprecated before a replacement was created. It is no longer maintained and not receiving security updates/fixes.
We will post here any updates on the wrapper and as soon as we have something you can try, we will definitely let you know.

[CrazyBaran]

@jennyf19 3 weeks pass and still nothing about @azure/node-token-validation? Is it not even possible to share some under development package?

[CrazyBaran]

@jennyf19 Something new in topic of replacement?

[anthonyhoegberg]

Any news here?

[renanbatel]

Never would expect from MS to deprecated a library before creating a replacement, unbelievable

[lucassith]

Really? In my development team, everyone agrees that Microsoft is the first element to fail. Whether it's source code, the cloud, or tools, it's always in the microsoft realm where something fails.

[mccolljr]

Has there been any progress on this front?

[mccolljr]

Also - although this will be like talking to a brick wall, you said:

Please provide us with your feedback/questions/concerns as we go through this process together

The fact that there have been 6 months of dead air in this discussion indicates that we are not in any way "going through this process together".

[lucassith]

Of course not, they deprectated passport.js extensions simply because they don't want to maintain it anymore and they don't care.

Pure Microsoft's thinking.

[ethanherbertson]

Does anyone have a link to an explanation of why this package was deprecated? Like, are there known vulnerabilities? Or is it just deprecated because it's abandonware and it therefore should not be trusted?

[ethanherbertson]

Update: As near as I can tell, as of this writing, there are not any known (or disclosed) vulnerabilities. But with such limited communication from the former maintainers it's not something that can be easily confirmed.

[ethanherbertson]

It seems like a very bad break from best practices to "deprecate" a node module without actually deprecating it in npm, especially when it's still being downloaded ~150k a week.

[ethanherbertson]

Probably also should be deprecated or removed from the PassportJS website's list of strategies, too.

[ethanherbertson]

It is especially bad in this case, because it's not even clear (to outsiders, at least) what the canonical repository even is for pasport-azure-ad at this point.

NPM & package.json both reference AzureAD/microsoft-authentication-library-for-js as the repo, but that project does not contain the source code on its default branch—and the branches I've found that do contain the source code there do not contain the README "deprecation notice".

Finding AzureAD/passport-azure-ad—which is what I currently assume to be canonical—is not exactly difficult via Google or GitHub searches, but without the direct links that are most trusted by the users I don't know how many people would actually do so.

Meanwhile, this discussion thread, linked to by the notice, is in a third repository. As an outsider I don't understand how this repository even relates to the other two, except that presumably it is (was?) a handy high-traffic project by the same group of developers, that they were assuming would be the place where they would eventually release the replacement.

[ethanherbertson]

If MS doesn't want to support the module, @jennyf19, would they be willing to hand over control to the community that's still relying on it? Without a public timeline or at least limited support for security updates, the only responsible thing for the userbase to do is to abandon the use of the module, and pivot to either a different language or a different identity platform altogether... but at the moment they're not even being informed of the deprecation in the first place.

Meanwhile, are there any other devs/contributors who could answer some of these questions? I don't really want to just randomly @ people but I feel somewhat duty-bound to do something in the name of all those many thousands of downloaders who have not and will not notice that they're using an unsupported & "deprecated" security module. This isn't how you OSS.

[ethanherbertson]

Occurred to me that this particular concern is perhaps better addressed via an issue, so I filed one. (#2847)

[mccolljr]

@jennyf19 are you or anyone else able to speak to progress that has been made?

[mccolljr]

@jennyf19 bumping this - can we get any sort of update here?

[RomanKonopelkoVoypost]

@jennyf19 Randomly seeing the npm package of passport-azure-ad as deprecated killed me. I see that this message hangs for one year almost. So, is there any updates? And what is the current solution for the developers that has been using passport-azure-ad until getting surprised by npm deprecate warning?

[zWaR]

@RomanKonopelkoVoypost @jennyf19 I wonder the same. I found this: https://github.com/AzureAD/microsoft-authentication-library-for-js However, I haven't used it. I wonder if that's meant to be the replacement and if so, how does the migration to it look like?

[ethanherbertson]

@zWaR That library (aka MSAL.js) is still supported, but it's the library for acquiring tokens from Azure AD (aka "Entra ID"). This library was designed to actually validating those tokens, for example as part of the backend application that the user's client passes the tokens to after acquisition.

(EDIT: Just noticed jdthorpe's comment below. Threading is hard!)

[jdthorpe]

Nope. `MSAL.js` is for acquiring tokens. `passport-azure-ad` was for validating them.

…

On Wed, Jul 24, 2024 at 8:30 AM zWaR ***@***.***> wrote: @RomanKonopelkoVoypost <https://github.com/RomanKonopelkoVoypost> @jennyf19 <https://github.com/jennyf19> I wonder the same. I found this: https://github.com/AzureAD/microsoft-authentication-library-for-js However, I haven't used it. I wonder if that's meant to be the replacement and if so, how does the migration to it look like? — Reply to this email directly, view it on GitHub <#2405 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTMQBLJZKIQ67Q4I2L6W3DZN7CALAVCNFSM6AAAAAA4B3HQLWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMJTHE2TEOI> . You are receiving this because you commented.Message ID: <AzureAD/microsoft-identity-web/repo-discussions/2405/comments/10139529@ github.com>

[sungyan]

A year has passed and there is no news.
I can't believe that this is microsoft's service

[kdarakji]

My friends any news on that?

[ssahillppatell]

Still looking for the promised simple wrapper (╥﹏╥)

[Hatko]

Has it been abandoned? We are experimenting with integrating MS AD into our NodeJS app, but it proves to be a struggle at every step

[michaelparkadze]

Seems to be abandoned and no news about the future..

[chdeliens]

Hi everyone,

Since the passport-azure-ad package is deprecated and no longer maintained, I did some research and found an alternative for securing our NodeJS applications with Azure AD authentication: the Microsoft Authentication Library (MSAL).

It provides secure access to Microsoft services and APIs using OAuth 2.0 and OpenID Connect standards, and it’s actively maintained by Microsoft.

Implementation steps

1. Set Up Your Azure AD Application

1. Register Your Application in Azure AD:

   • Go to the Azure Portal.
   • Navigate to Azure Active Directory > App registrations > New registration.
   • Enter a name for your application.
   • Set the Redirect URI to http://localhost:3000/auth/redirect (adjust based on your app’s domain and callback endpoint).
   • Choose Single-tenant or Multi-tenant based on your needs.
   • Click Register.

2. Configure Authentication Settings:

   • Under Authentication, set the Redirect URIs to match your redirect endpoint.
   • Set the Implicit grant and hybrid flows section to allow ID tokens.

3. Create a Client Secret:

   • Under Certificates & secrets, create a new client secret. Save this value; you’ll need it for the MSAL configuration.

2. Install MSAL Node Package

Install the MSAL Node package in your NodeJS project:

npm install @azure/msal-node express-session

3. Set Up MSAL in Your NodeJS App

Sample Code for NodeJS Authentication with MSAL

Not suitable for production usage, only for developement/experimentation purposes
Below is a setup to authenticate users with Azure AD, manage sessions, and protect routes:

// server.js
const express = require('express');
const session = require('express-session');
const { ConfidentialClientApplication } = require('@azure/msal-node');

const app = express();
const PORT = process.env.PORT || 3000;

// MSAL configuration
const msalConfig = {
  auth: {
    clientId: process.env.OAUTH2_CLIENT_ID,
    authority: `https://login.microsoftonline.com/${process.env.TENANT_ID}`, // Tenant ID or common for multi-tenant
    clientSecret: process.env.OAUTH2_CLIENT_SECRET,
  },
};

const msalClient = new ConfidentialClientApplication(msalConfig);

// Configure session middleware
app.use(
  session({
    secret: process.env.SESSION_SECRET_KEY || 'default_secret',
    resave: false,
    saveUninitialized: false,
    cookie: { secure: false }, // Set to true if using HTTPS
  })
);

// Login route - redirects to Azure AD for authentication
app.get('/login', (req, res) => {
  const authCodeUrlParameters = {
    scopes: ['user.read'],
    redirectUri: 'http://localhost:3000/auth/redirect', // Adjust the redirect URI
  };

  // Redirect to Microsoft login page
  msalClient.getAuthCodeUrl(authCodeUrlParameters).then((response) => {
    res.redirect(response);
  }).catch((error) => {
    console.error('Error generating auth code URL:', error);
    res.status(500).send('Error during login');
  });
});

// Callback route - handles Azure AD redirect with authorization code
app.get('/auth/redirect', (req, res) => {
  const tokenRequest = {
    code: req.query.code, // Authorization code from query params
    scopes: ['user.read'],
    redirectUri: 'http://localhost:3000/auth/redirect', // Must match exactly with Azure AD config
  };

  // Exchange authorization code for tokens
  msalClient.acquireTokenByCode(tokenRequest).then((response) => {
    req.session.user = {
      username: response.account.username,
      name: response.account.name,
      idToken: response.idToken,
    };
    res.redirect('/profile');
  }).catch((error) => {
    console.error('Error acquiring token by code:', error);
    res.status(500).send('Error during token acquisition');
  });
});

// Protected route example
app.get('/profile', (req, res) => {
  if (!req.session.user) {
    return res.redirect('/login');
  }
  res.send(`Welcome, ${req.session.user.name}`);
});

// Logout route
app.get('/logout', (req, res) => {
  req.session.destroy((err) => {
    if (err) {
      console.error('Error during logout:', err);
      return res.status(500).send('Error during logout');
    }
    res.redirect('/');
  });
});

app.listen(PORT, () => {
  console.log(`Server is running on http://localhost:${PORT}`);
});

Explanation of Key Components

1. MSAL Configuration:

   • The MSAL configuration (msalConfig) specifies your Azure AD tenant, client ID, and client secret.

2. Login and Redirect Handling:

   • /login Route: Redirects the user to Azure AD for authentication.
   • /auth/redirect Route: Handles the callback from Azure AD, exchanges the authorization code for tokens, and stores user information in the session.

3. Protected Routes:

   • Example protected route (/profile) checks for session data to verify the user is authenticated.

4. Session Management:

   • Session middleware (express-session) is used to manage user sessions and handle authentication state.

Advantages of Using MSAL

• Actively Maintained: MSAL is actively maintained by Microsoft, ensuring security updates and compatibility with the latest Azure AD features.
• Robust Security: Supports modern authentication flows, including OAuth 2.0 and OpenID Connect.
• Scalable and Configurable: Easily handles multi-tenant scenarios and complex authentication requirements.

Final Steps

1. Set Up Environment Variables:

   • Ensure that you have configured the necessary environment variables:
     • OAUTH2_CLIENT_ID
     • OAUTH2_CLIENT_SECRET
     • TENANT_ID
     • SESSION_SECRET_KEY

2. Test the Application:

   • Run your NodeJS application, navigate to /login, and test the authentication flow.

It worked for me ;) Hope this helps!!!

[Ben-CA]

Can you elaborate on what you mean when you say that "access tokens can't be validated"? Were you getting an error or unable to configure it? I've been using this to validate access tokens. The TL;DR on that is that the library validates the issuer and signature and it's up to you to apply your business logic, (i.e. to inspect the claims like the roles assigned via Azure AD or your auth provider...).

@jdthorpe I've updated my comment slightly; I gather it depends on what access tokens you're getting from Entra ID. The default tokens received (for MS Graph) cannot be validated ("invalid signature" using jwt.verify, which can also be seen https://jwt.io - invalid signature ), whereas the default id tokens received have valid signatures.

Now from what I understand, you can create separate API scopes within Entra with their own respective access tokens, which probably CAN be verified, but that wasn't what I was doing, and this had me stumped for a while.

[jdthorpe]

@Ben-CA debugging the configuration can certainly be frustrating. I've certainly spent my fair share of time pulling my hair out trying to figure out what's wrong with my configuration. My best recommendation is to include an error handler in your passport.authenticate() call ( as in passport.authenticate("jwt",{session: false}, (error,user,info) => {console.log(error,user,info); debugger})). The error messages are relatively specific ("expected audience X but found Y") which is very helpful. For example, this is how I figured out the correct configuration for validating B2C access tokens in my comments below.

[Ben-CA]

@jdthorpe Good point, error logs are essential for diagnostics. In my case I chose to not use Passport entirely, since passport-azure-ad was deprecated. But I was logging errors, but was stumped for a while why I was getting "invalid signature".

[jdthorpe]

@jdthorpe Good point, error logs are essential for diagnostics. In my case I chose to not use Passport entirely, since passport-azure-ad was deprecated. But I was logging errors, but was stumped for a while why I was getting "invalid signature".

Agreed that it's not a good idea to use this passport package, but Azure Entra Access and Id tokens are just ordinary JWTs, which is why I went with the passport-jwt library.

FWIW, the error you were getting indicates that passport grabbed public keys from the wrong tenant / endpoint. You can find your issuer's jwks url by adding .well-known/openid-configuration to the end of the issuer url and searching for the jwks_urk entry.

[bora89]

@chdeliens knock off with your GPT shit

[DanielOverdevestPZH]

Dear community,

I have found a "drop-in replacement" for the deprecated passport-azure-ad. The replacement utilizes the passport-jwt and jwks-rsa packages.

• passport-jwt serves as the middleware replacement.
• jwks-rsa handles the validation of the Bearer token with public signed keys from Microsoft.

This solution supports the Bearer token approach of passport-azure-ad, but does not support the OIDC approach.

Here is the code before the replacement:

const { BearerStrategy } = require('passport-azure-ad');

const tenantId = process.env.AD_APPLICATION_TENANT_ID;
const clientId = process.env.AD_APPLICATION_CLIENT_ID;
const identityMetadata = `https://login.microsoftonline.com/${tenantId}/v2.0/.well-known/openid-configuration`;
const issuer = `https://login.microsoftonline.com/${tenantId}/v2.0`;

const options = {
  identityMetadata: identityMetadata,
  clientID: clientId,
  validateIssuer: true,
  issuer: issuer,
};

async function verifyCallBack(token, done) {
  // do some stuff
  return done(null, token, token);
}

const bearerStrategy = new BearerStrategy(options, verifyCallBack);

module.exports = {
  bearerStrategy
};

And here is the new "drop-in replacement" code:

const { Strategy, ExtractJwt } = require('passport-jwt');
const jwksRsa = require('jwks-rsa');

// The tenant ID is the Azure AD tenant ID. The client ID is the application ID of the app registration.
const tenantId = process.env.AD_APPLICATION_TENANT_ID;
const clientId = process.env.AD_APPLICATION_CLIENT_ID;

// This is the URL where the public keys for the tenant are stored.
const jwksUri = `https://login.microsoftonline.com/${tenantId}/discovery/v2.0/keys`;

// This issuer and audience are used for API scope with MSAL
const issuer1 = `https://sts.windows.net/${tenantId}/`;
const audience1 = `api://${clientId}`;

// This issuer and audience are used if authentication is enabled on App Service with token cache.
const issuer2 = `https://login.microsoftonline.com/${tenantId}/v2.0`;
const audience2 = `${clientId}`;

// The options for the JWT strategy
const options = {
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  audience: [audience1, audience2],
  issuer: [issuer1, issuer2],
  algorithms: ['RS256'],
  secretOrKeyProvider: jwksRsa.passportJwtSecret({
    cache: true,
    rateLimit: true,
    jwksRequestsPerMinute: 5,
    jwksUri: jwksUri,
  }),
};

// This function is called when the token is verified
async function verifyCallBack(token, done) {
  // do something with the token
  return done(null, token);
}

const bearerStrategy = new Strategy(options, verifyCallBack);

module.exports = { bearerStrategy };

This replacement should help anyone who still needs the Bearer token validation functionality after passport-azure-ad's deprecation.

[Ben-CA]

Appreciate you sharing, but considering https://www.npmjs.com/package/passport-jwt hasn't been updated since 2022, and relies on a really old dependency: https://www.npmjs.com/package/passport-strategy (11yrs since last update) and a slightly outdated version of https://www.npmjs.com/package/jsonwebtoken, I'm not sure this is the best route either...

[jdthorpe]

FWIW, "Really old" is not the same as defunct or insecure. The 11 year old package you reference is just an Abstract Class (interface) declaring that classes that implement a Strategy should have an authenticate() method.

[Ben-CA]

Agreed; but it does make me question if I want to base a new application on it...

[DanielOverdevestPZH]

Thanks for mentioning, the package is still downloaded 1 million per day. But would be good to find a replacement for passport. Seems @sam-mfb have already a good start to look at!

[sam-mfb]

Here's a way to do it in express without using passport (based on @DanielOverdevestPZH 's approach):

import { expressjwt, Request as RequestJWT } from "express-jwt"
import type { Request } from "express"
import jwksRsa, { GetVerificationKey } from "jwks-rsa"
// needed for type inference
import "express-unless"

// eslint-disable-next-line @typescript-eslint/explicit-function-return-type
export function buildExpressMsalToken({
  tenantId,
  clientId
}: {
  tenantId: string
  clientId: string
}) {
  // This is the URL where the public keys for the tenant are stored.
  const jwksUri = `https://login.microsoftonline.com/${tenantId}/discovery/v2.0/keys`

  // This issuer and audience are used for API scope with MSAL
  const issuer1 = `https://sts.windows.net/${tenantId}/`
  const audience1 = `api://${clientId}`

  // This issuer and audience are used if authentication is enabled on App Service with token cache.
  const issuer2 = `https://login.microsoftonline.com/${tenantId}/v2.0`
  const audience2 = `${clientId}`

  return expressjwt({
    secret: jwksRsa.expressJwtSecret({
      jwksUri: jwksUri,
      cache: true,
      rateLimit: true,
      jwksRequestsPerMinute: 5
    }) as GetVerificationKey,
    audience: [audience1, audience2],
    issuer: [issuer1, issuer2],
    algorithms: ["RS256"],
    credentialsRequired: true
  })
}

export type RequestWithMsalAuth = {
  auth?: RequestJWT["auth"] & {
    name?: string
    unique_name?: string
    upn?: string
    oid?: string
    scp?: string
    roles?: string[]
  }
} & Request

use it as follows, for example:

const app = express()
const port = 3000

const tenantId = process.env.TENANT_ID
if (!tenantId) {
  throw new Error(
    "TENANT_ID not defined."
  )
}

const clientId = process.env.CLIENT_ID
if (!clientId) {
  throw new Error(
    "CLIENT_ID not defined."
  )
}

app.use(buildExpressMsalToken({tenantId,clientId})

app.get(
  "",
  (req: RequestWithMsalAuth, res, next) => {
  // do stuff in your controller, req.auth will be typed
    }
)

app.listen(port, () => {
  console.log(`Server running on port ${port}`)
})

[jdthorpe]

Note that if you want to use DanielOverdevestPZH's solution to validate tokens issued by Azure AD B2C, you'll need to change your configuration like so:

// This is the URL where the public keys for the tenant are stored.
const jwksUri = `https://${tenant_name}.b2clogin.com/${tenant_name}.onmicrosoft.com/${user_flow}/discovery/v2.0/keys`;

// This issuer and audience are used for API scope with MSAL
const issuer1 = `https://${tenant_name}.b2clogin.com/${tenantId}/v2.0/`;
const audience1 = clientId;

// The options for the JWT strategy
const options = {
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  audience: [audience1],
  issuer: [issuer1],
  algorithms: ["RS256"],
  secretOrKeyProvider: jwksRsa.passportJwtSecret({
    cache: true,
    rateLimit: true,
    jwksRequestsPerMinute: 5,
    jwksUri: jwksUri,
  }),
}

Where:

• tenant_name is the name of your b2c tenant (e.g. "contoso" in the b2c examples)
• tenant_id is your b2c tenant's guid
• client_id is the app (client) Id of you app registration
• uesr_flow is the name of your user flow (typically "b2c_1_signupsignin" or "b2c_1_signupin" in the b2c examples)

[DanielOverdevestPZH]

Hi @jdthorpe, thanks for this addition how to use it for B2C!

[andokai]

FWIW if anyone is using Fastify fastify-jwt-jwks works pretty well.

This is a basic example of adding it as a plugin.

import jwtJwks from "fastify-jwt-jwks"
import fp from "fastify-plugin"

export default fp(async function (fastify) {
	await fastify.register(jwtJwks, {
		jwksUrl: "https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys",
		secret: "shhhh",
		audience: ["audience1", "audience2"],
		issuer: ["https://sts.windows.net/<TENANT_ID>/"],
	})

	fastify.addHook("preValidation", fastify.authenticate)
}

[Ben-CA]

Still no official replacement from Microsoft? It's 2025, and they deprecated https://github.com/AzureAD/passport-azure-ad in Aug. 2023.

[ethanherbertson]

Actually, based on the contents of that Aug 2023 update to the README, it had already been deprecated (in some sense) for long enough for users to be frustrated by it. So it's been longer even than that.

[patoperpetua]

Hi community,

I saw the implementation of passport-azure-ad and it's using passport-http-bearer

This is how I replace the implementation:

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { AuthGuard, PassportStrategy } from '@nestjs/passport';
import { EnvironmentConfigServiceService } from 'src/services/environment-config-service/environment-config-service.service';
import { Strategy } from 'passport-http-bearer';
import { decode, verify } from 'jsonwebtoken';
import * as jwksClient from 'jwks-rsa';

@Injectable()
export class AzureADStrategyService extends PassportStrategy(
Strategy,
'azure-ad',
) {
private jwksClient: jwksClient.JwksClient;

constructor(private configService: EnvironmentConfigServiceService) {
super();

// Initialize JWKS client for retrieving Azure AD signing keys
this.jwksClient = jwksClient({
  jwksUri: `https://login.microsoftonline.com/${configService.getAzureADTenantID()}/discovery/v2.0/keys`,
});

}

async validate(token: string): Promise {
try {
// Decode the token to extract the header and find the signing key
const decodedToken = decode(token, { complete: true });
if (!decodedToken) {
throw new UnauthorizedException('Invalid token');
}

  // Get the signing key using the Key ID (kid) from the token header
  const key = await this.jwksClient.getSigningKey(decodedToken.header.kid);
  const signingKey = key.getPublicKey();

  // Verify the token with the signing key
  const issuerV1 = `https://sts.windows.net/${this.configService.getAzureADTenantID()}/`;
  const issuerV2 = `https://login.microsoftonline.com/${this.configService.getAzureADTenantID()}/v2.0`;

  const verifiedToken = verify(token, signingKey, {
    algorithms: ['RS256'],
    audience: this.configService.getAzureADClientID(),
    issuer: [issuerV1, issuerV2], // Allow both v1 and v2 issuers
  });

  // Return the verified token's claims
  return verifiedToken;
} catch (error) {
  throw new UnauthorizedException(
    `Token validation failed: ${error.message}`,
  );
}

}
}

export const AzureADGuard = AuthGuard('azure-ad');

Perhaps it's useful for someone looking for an alternative

[TobiasJu]

Your are using passport-http-bearer which latest versions is over 10 years old and not maintained, idk man. Thanks for the effort, but this is not the alternative we are looking for.

[Ben-CA]

Somewhat concerning that Microsoft is still referencing this deprecated library in "how to" information: (which was written or updated after it was already deprecated)
https://learn.microsoft.com/en-us/azure/active-directory-b2c/enable-authentication-in-node-web-app-with-api

[sam-mfb]

A few notes on this issue and a link to the start of a modern option for express (which I hope becomes unnecessary when MSFT provides a package.)

The solutions provided by @DanielOverdevestPZH, me and others in this thread are good in the sense that they provide a simple, drop-in way to do basic MSAL token validation. But, like a lot of things, they suffer from what I think of as the curl rewrite problem, i.e., it's pretty easy to write something to handle the simple, happy-path flow, but much much harder to capture every use case.

To illustrate a few possible problems with the approaches outlined here:

• The solutions here hardcode in the uris for keys and issuers. These aren't likely to change any time soon, but per the Open Id Connect standard (and MS documentation) these should really be obtained from a discovery endpoint.
• Making the above more complicated, MSFT provides both standards compliant OIDC discovery endpoints and tenant-independent endpoints. See here
• The solutions tend to validate as if tokens could be either v1 or v2. It probably makes more sense to only validate for the specific version your resource server is expecting.
• The solutions tend to assume that the audience will be derived from the app's clientId -- this is true for v2 tokens, but is not necessarily true for v1 tokens (although it is the default in Azure's GUI). See here
• For typescript users typing the claims that show up in validated tokens is very tricky because it varies based on, among other things, v1 vs v2, use of optional claims, permissions to MS Graph, and probably a bunch of other things.
• As note above by @jdthorpe, there's a whole different set of issues when dealing with B2C

All of which is to say that, while drop-in code snippets are (extremely) helpful, they aren't a total solution, and a library really is needed.

I have started such a library here. It currently acheives the same kind of basic validation as the drop-in snippets above but also:

• gets the key and issuer uris through a discovery endpoint
• distinguishes between v1 and v2 tokens
• allows the use of arbitrary audiences
• provides some additional Request typing

It's only dependencies are expressjwt and jwks-rsa both of which are well-known and reasonably actively developed. (That said, even this isn't perfect -- expressjwt relies on jsonwebtoken and jwks-rsa uses jose, which seems like an unnecessary inconsistency; also, expressjwt hasn't been updated for express 5, though i've worked around that in this library as the differences are not actually relevant here).

There is also a lot of room for improvement. I'm not sure how much time I will have to do that (it's not a huge need in our organization), but am happy to try. Feel free to post issues/thoughts on the repo.

[DanielOverdevestPZH]

@sam-mfb , thanks for your contribution to build a package/repo like this!

Still very strange that Microsoft isn't coming up with a replacement for package passport-azure-ad as it was a very wide used package.

I think we should contribute to your package so this will be a good replacement.

[Oryanab]

Hey everyone, I’ve put together a comprehensive tutorial on implementing authentication with Passport.js and Azure in 2025. If you’re interested, feel free to check it out here: Complete Guide to Authentication with Passport.js & Azure in 2025.

Hope it helps, and I’d love to hear your thoughts!

[mrwillis]

Here is some working code based on an official msal example if this helps anyone. One thing I can't figure out is why the issuer doesn't match, but that is another issue.

Hope this helps.

This should really be built into the library. Kind of a joke that it is not.

https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/samples/msal-node-samples/on-behalf-of/web-api/index.js#L35

/**
 * Validates the ID token and checks the nonce
 * @param idToken - The ID token to validate
 * @param nonce - The nonce to check against
 * @returns The decoded token payload
 */
async function validateIdToken(idToken: string, nonce: string): Promise<JwtPayload> {
  const config = getConfig();
  const clientId = config.microsoftIdentity?.clientId;
  if (!clientId) {
    throw new Error('Microsoft identity client ID not set in config');
  }

  const client = jwksClient({
    jwksUri: 'https://login.microsoftonline.com/common/discovery/v2.0/keys',
  });

  const getKey = (header: JwtHeader, callback: SigningKeyCallback): void => {
    client.getSigningKey(header.kid, (err: Error | null, key: jwksClient.SigningKey | undefined) => {
      if (err) {
        callback(err);
        return;
      }
      const signingKey = key?.getPublicKey();
      callback(null, signingKey);
    });
  };

  return new Promise((resolve, reject) => {
    verify(
      idToken,
      getKey,
      {
        audience: clientId,
        // TODO: figure out why you can't use the common issuer. How do you specify the tenant?
        // If uncommented, will get errors that the issue is incorrect, as the 
        // returned issuer is some random tenant that I can't even find on the application page in azure.
        // issuer: 'https://login.microsoftonline.com/common/v2.0', 
      },
      (err, decoded) => {
        if (err) {
          reject(new Error(`Token validation failed: ${err.message}`));
          return;
        }

        if (!decoded) {
          reject(new Error('Token validation failed: no payload'));
          return;
        }

        if ((decoded as JwtPayload).nonce !== nonce) {
          reject(new Error('Nonce mismatch'));
          return;
        }

        resolve(decoded as JwtPayload);
      }
    );
  });
}

[loucadufault]

I spent some time figuring out how to implement this for a use case that doesn't use express (or passport). The goal was minimal dependencies and custom code (especially for the security sensitive parts such as JWT verification).

The custom code is mainly for extracting the JWT as a first step, largely adapted from passport-js, express-jwt, and then to retrieve the jkws_uri from the AD FS OpenID Connect configuration document. The only dependency is on jose, which handles fetching the JWKS (signing keys) from the jwks_uri, and performs the JWT verification itself.

// extract JWT

/**
 * Implementation of Auth header parsing adapted from https://github.com/mikenicholson/passport-jwt/blob/fed94fa005c5b2dcb7e6d5d5372e3b20cae898f1/lib/extract_jwt.js#L70-L72
 */

import type { IncomingMessage } from 'node:http'

export const fromAuthHeaderAsBearerToken = (request: IncomingMessage): string | null => {
  const headerValue = request.headers.authorization
  if (headerValue === undefined) {
    return null
  }

  const authParams = parseAuthHeader(headerValue)
  return authParams && authParams.scheme.toLowerCase() === 'bearer' ? authParams.value : null
}

const AUTH_HEADER_REGEX = /(\S+)\s+(\S+)/

function parseAuthHeader(value: string) {
  const matches = value.match(AUTH_HEADER_REGEX)
  return matches && { scheme: matches[1], value: matches[2] }
}

// setup JWKS

import { createRemoteJWKSet, type JWTVerifyGetKey } from 'jose'

async function getJwksUri(openIdConfigurationDocumentUrl: string) {
  return (await fetch(openIdConfigurationDocumentUrl).then((res) => res.json())).jwks_uri
}

export const createRemoteJwks = async (authorityUrl: string): Promise<JWTVerifyGetKey> =>
  createRemoteJWKSet(
    new URL(await getJwksUri(authorityUrl + '.well-known/openid-configuration')),
  )

// server code

import { jwtVerify } from 'jose'

const config = {
  authorityUrl: 'https://your-adfs-server.com',
  expectedClaims: {
    audience: 'https://this-resource-server.com',
    issuer: 'https://your-adfs-server.com/services/trust',
  },
}

const jwks = await createRemoteJwks(config.authorityUrl) // create as a singleton, since it memoizes network requests

async function isRequestAuthorized(request: IncomingMessage) {
  try {
      const jwt = fromAuthHeaderAsBearerToken(request)
      if (jwt === null) {
        throw new Error('Unable to extract Bearer token from Authorization header')
      }

      await jwtVerify(jwt, jwks, { ...config.expectedClaims })
    } catch (e) {
      console.info(e, 'Failed to authorize request')
      return false
    }

    return true
}

Then you would have your server call isRequestAuthorized on incoming requests to check whether the request is authorized (and reject or allow accordingly). For example, you could wrap this as a middleware for your favorite server framework.

You can also easily change the method of extracting the JWT from the request, by changing the call to fromAuthHeaderAsBearerToken(request) to some other function. In my case, I am checking authorization for WS requests, so I extract it from the Sec-Websocket-Protocol header instead (which is non-standard, but required due to limitations of the WS spec).

---

For the record, probably the best approach would be to use this library function: https://github.com/panva/oauth4webapi/blob/v2.12.2/docs/functions/validateJwtAccessToken.md

This would effectively bring the validation code down to one function call. However, the catch is in the docs:

This does NOT validate the sub, jti, and client_id claims beyond just checking that they're present and that their type is a string. If you need to validate these values further you would do so after this function's execution.

Access tokens issued by AD FS are unfortunately non-compliant with the spec (for example missing the jti claim) which is a requirement for using this library.

It is probably possible to get this working by configuring custom claims for the access token issuance in your AD FS config. If someone manages to get that working please tag me.

[invaderb]

The fact that's it's been 2 years and no updates it's pretty safe to assume it's 100% abandoned with no alternative in the future, I wouldn't expect much less from Microsoft what a joke of a company.

For those using nestjs I incorporated @loucadufault implementation with a custom passport strategy based on the passport-azure-ad

import { Logger } from '@nestjs/common';
import passport from 'passport';
import { Strategy } from 'passport';

import { createRemoteJWKSet, type JWTVerifyGetKey } from 'jose';
import { jwtVerify } from 'jose';

const CLOCK_SKEW = 300; // 5 minutes
const POLICY_REGEX = /^b2c_1a?_[0-9a-z._-]+$/i; // policy is case insensitive
const AUTH_HEADER = 'authorization';
const ACCEPTED_AUTH_SCHEME = 'Bearer';
const AUTH_HEADER_REGEX = /(\S+)\s+(\S+)/;

export class BearerStrategy extends Strategy {
	private logger = new Logger(BearerStrategy.name);
	name: string;
	_verify: any;
	_options: any;
	constructor(options, verifyFn) {
		super();
		this.name = 'oauth-bearer';
		if (!options) throw new Error('In BearerStrategy constructor: options is required');
		if (!verifyFn || typeof verifyFn !== 'function') {
			throw new Error('In BearerStrategy constructor: verifyFn is required and it must be a function');
		}
		this._verify = verifyFn;

		// Initialize options with defaults
		this._options = this._initializeOptions(options);

		// Validate options
		this._validateOptions(options);
	}

	_initializeOptions(options) {
		// Clock skew validation
		if (
			options.clockSkew &&
			(typeof options.clockSkew !== 'number' || options.clockSkew <= 0 || options.clockSkew % 1 !== 0)
		)
			throw new Error('clockSkew must be a positive integer');

		options.clockSkew = options.clockSkew || CLOCK_SKEW;
		options.passReqToCallback = options.passReqToCallback === true;
		options.validateIssuer = options.validateIssuer !== false;
		options.allowMultiAudiencesInToken = options.allowMultiAudiencesInToken === true;
		options.isB2C = options.isB2C === true;

		// Handle audience
		if (options.audience && typeof options.audience === 'string') {
			options.audience = [options.audience];
		} else if (!options.audience || !Array.isArray(options.audience) || options.length === 0) {
			options.audience = [options.clientID, 'spn:' + options.clientID];
		}

		// Handle issuer
		if (options.issuer === '') options.issuer = null;
		if (options.issuer && Array.isArray(options.issuer) && options.issuer.length === 0) options.issuer = null;
		if (options.issuer && !Array.isArray(options.issuer)) options.issuer = [options.issuer];
		return options;
	}

	_isHttpsUri(uri) {
		return uri && uri.indexOf('https://') === 0;
	}
	_validateOptions(options) {
		if (!options.clientID || options.clientID === '')
			throw new Error('In BearerStrategy constructor: clientID cannot be empty');

		if (!options.identityMetadata || !this._isHttpsUri(options.identityMetadata))
			throw new Error('In BearerStrategy constructor: identityMetadata must be provided and must be a https url');

		if (options.scope && (!Array.isArray(options.scope) || options.scope.length === 0))
			throw new Error('In BearerStrategy constructor: scope must be a non-empty array');

		// B2C validation
		if (options.isB2C) {
			if (!options.policyName || !POLICY_REGEX.test(options.policyName))
				throw new Error('In BearerStrategy constructor: invalid policy for B2C');
		}

		// Common endpoint detection
		options._isCommonEndpoint = options.identityMetadata.indexOf('/common/') != -1;

		if (!options.validateIssuer) {
			this.logger.warn('Production environments should always validate the issuer.');
		}
	}

	async _createRemoteJwks(identityMetadata: string): Promise<JWTVerifyGetKey> {
		return await createRemoteJWKSet(new URL(await this._getJwksUriFromOpenIdConfiguration(identityMetadata)));
	}

	_parseAuthHeader(value: string) {
		const matches = value.match(AUTH_HEADER_REGEX);
		return matches && { scheme: matches[1], value: matches[2] };
	}

	_fromAuthHeaderAsBearerToken(request: Request): string | null {
		const headerValue = request.headers[AUTH_HEADER];
		if (headerValue === undefined) {
			return null;
		}

		const authParams = this._parseAuthHeader(headerValue);
		if (authParams && ACCEPTED_AUTH_SCHEME.toLowerCase() === authParams.scheme.toLowerCase()) {
			return authParams.value;
		}

		return null;
	}

	async _getJwksUriFromOpenIdConfiguration(identityUri: string): Promise<string> {
		const openIdConfigurationDocument = await fetch(identityUri).then((res) => res.json());
		return openIdConfigurationDocument.jwks_uri;
	}

	_validatePayloadContent(payload, options) {
		const hasCommonElem = (array1, array2) => {
			for (let i = 0; i < array1.length; i++) {
				if (array2.indexOf(array1[i]) !== -1) return true;
			}
			return false;
		};
		// (1) issuer
		//   - check the existence and the format of payload.iss
		//   - validate if options.issuer is set
		if (typeof payload.iss !== 'string' || payload.iss === '') return new Error('invalid iss value in payload');
		if (options.validateIssuer !== false) {
			if (
				!options.issuer ||
				options.issuer === '' ||
				(Array.isArray(options.issuer) && options.issuer.length === 0)
			)
				return new Error('options.issuer is missing');
			let valid = false;
			if (Array.isArray(options.issuer)) valid = options.issuer.indexOf(payload.iss) !== -1;
			else valid = options.issuer === payload.iss;
			if (!valid) return new Error('jwt issuer is invalid');
		}

		// (2) subject (id_token only. We don't check subject for access_token)
		//   - check the existence and the format of payload.sub
		//   - validate if options.subject is set
		if (options.isAccessToken !== true) {
			if (typeof payload.sub !== 'string' || payload.sub === '') {
				return new Error('invalid sub value in payload');
			}
			if (options.subject && options.subject !== payload.sub)
				return new Error('jwt subject is invalid. expected');
		}

		// (3) audience
		//   - always validate
		//   - allow payload.aud to be an array of audience
		//   - options.audience must be a string
		//   - if there are multiple audiences, then azp claim must exist and must equal client_id
		if (typeof options.audience === 'string') options.audience = [options.audience, 'spn:' + options.audience];
		if (options.allowMultiAudiencesInToken === false && Array.isArray(payload.aud) && payload.aud.length > 1)
			return new Error('multiple audience in token is not allowed');
		const payload_audience = Array.isArray(payload.aud) ? payload.aud : [payload.aud];
		if (!hasCommonElem(options.audience, payload_audience)) return new Error('jwt audience is invalid');
		if (payload_audience.length > 1) {
			if (typeof payload.azp !== 'string' || payload.azp !== options.clientID)
				return new Error('jwt azp is invalid');
		}

		// (4) expiration
		//   - check the existence and the format of payload.exp
		//   - validate unless options.ignoreExpiration is set true
		if (typeof payload.exp !== 'number') return new Error('invalid exp value in payload');
		if (!options.ignoreExpiration) {
			if (Math.floor(Date.now() / 1000) >= payload.exp + options.clockSkew) {
				return new Error('jwt is expired');
			}
		}

		// (5) nbf
		// - check if it exists
		if (payload.nbf) {
			if (typeof payload.nbf !== 'number') return new Error('nbf value in payload is not a number');
			if (payload.nbf >= payload.exp) return new Error('nbf value in payload is not before the exp value');
			if (payload.nbf >= Math.floor(Date.now() / 1000) + options.clockSkew) return new Error('jwt is not active');
		}
	}

	async authenticate(this: passport.StrategyCreated<this, this & passport.StrategyCreatedStatic>, req) {
		try {
			const jwks = await this._createRemoteJwks(this._options.identityMetadata);
			const jwt = this.fromAuthHeaderAsBearerToken(req);
			if (jwt === null) {
				throw new Error('Unable to extract Bearer token from Authorization header');
			}
			const res = await jwtVerify(jwt, jwks, {});
			console.log('res: ', res);
			// check if no res payload and fail
			if (!res.payload) return this.failWithLog(this, 'no payload in jwt');
			this._validatePayloadContent(res.payload, this._options);
			return this.success(res.payload);
		} catch (error) {
			console.log(error);
			return this.failWithLog(this, error);
		}
	}

	failWithLog(this: passport.StrategyCreated<this, this & passport.StrategyCreatedStatic>, message) {
		this.logger.log(`authentication failed due to: ${JSON.stringify(message)}`);
		return this.fail(message);
	}
}

import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { BearerStrategy } from './bearer.strategy';

@Injectable()
export class JwtStrategy extends PassportStrategy(BearerStrategy, 'azure-ad') {
	constructor() {
		const issuer = `https://login.microsoftonline.com/{tenant ID}/v2.0`;
		const jwksUri = `https://login.microsoftonline.com/{tenant ID}/v2.0/.well-known/openid-configuration`;
		super({
			identityMetadata: jwksUri,
			issuer: issuer,
			clientID: process.env.AD_CLIENT_ID,
			audience: process.env.AD_CLIENT_ID,
			loggingLevel: process.env.JWT_LOG_LEVEL,
			loggingNoPII: false
		});
	}

	async validate(payload: unknown): Promise<any> {
		return payload;
	}
}

[invaderb]

also wanted to note you will need to use jose version 5 with nestjs out of the box since it compiles as cjs and version 6 is esm only

it is possible to to use version 6 but will need to refactor your nestjs build process to use SWC among other things
https://gist.github.com/eugenk/3d116d2a1cc34fdc446aef97d2afdcb9