Status of node-token-validation?

[DevRCRun]

Core Library

MSAL Node (@azure/msal-node)

Core Library Version

1.17.3

Wrapper Library

Not Applicable

Wrapper Library Version

NA

Public or Confidential Client?

Confidential

Description

I note https://github.com/AzureAD/microsoft-authentication-library-for-js/pull/5921 but am unsure of its implications.

We are currently using passport-azure-ad and have been waiting for node-token-validation to release before migrating. (i.e. in a similar position to the OP in this thread https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/4816, our own previous issue on this https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/3939 )

Could you confirm the status of node-token-validation please?

MSAL Configuration

No response

Relevant Code Snippets

No response

Identity Provider

Azure AD / MSA

Source

External (Customer)

[sameerag]

@EmLauber Can you help here? @DevRCRun We have an alternative solution being built for token validation, hence we stopped work on node-token-validation. I will have @EmLauber update the status here.

[EmLauber]

Tagging in @jmprieur @jennyf19 for node token validation status.

[ghost]

@DevRCRun This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 5 days. If your issue has been resolved please let us know by closing the issue. If your issue has not been resolved please leave a comment to keep this open. It will be closed automatically in 7 days if it remains stale.

[DevRCRun]

bump

[ghost]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @sameerag please follow up.

[ghost]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @sameerag please follow up.

[egm9078]

const jwt = require('jsonwebtoken');
const jwksClient = require("jwks-rsa");

app.use('/protected-endpoints*', async (req, res) => {

    const authHeader = req.headers.authorization;
    if (!authHeader) return res.sendStatus(401);
    const token = authHeader.split(' ')[1];

    try {

        const getSigningKey = async (header) => {
            return new Promise((resolve, reject) => {
                const client = jwksClient({
                    jwksUri: `https://login.microsoftonline.com/${process.env.API_TENANTID}/discovery/v2.0/keys`,
                });

                client.getSigningKey(header.kid, (err, key) => {
                    if (err) {
                        reject(err);
                    } else {
                        const signingKey = key.publicKey || key.rsaPublicKey;
                        resolve(signingKey);
                    }
                });
            });
        };

        const decodedToken = jwt.decode(token, { complete: true });
        const header = decodedToken.header;
        const signingKey = await getSigningKey(header);
        const decoded = jwt.verify(token, signingKey);
        req.authInfo = decoded;

    } catch (err) {
        logger.error({error: err});
        res.sendStatus(401);
    }

});

What about this approach for validating and decoding tokens with node? The API needs a role or scope from the decoded token to proceed with the request.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @EmLauber please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @EmLauber please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @EmLauber please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @EmLauber please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[vgarmash]

@jmprieur Please let us know what library we should use for the new Node.js API projects to implement access token validation for authorization with Azure AD.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[dylel]

bump, this needs a real solution or at least a basic example of how to do it ourselves safely as right now we are just guessing

[samschurter]

What is the status on providing a mechanism for token validation in this library? If it's not going to happen at all, I need to know that so my team can spend the time to figure out safely validating tokens ourselves. If it's going to happen soon, I need to know that so my team doesn't waste that time. I see that "passport-azure-ad" is recommended in the docs, but it is archived and no longer getting security updates, so I don't feel comfortable using it.

I thought that "@msal/node-token-validation" was a thing because it appeared in the online documentation until very recently, but now those docs are 404 and even the code has been removed from the repo.

This is extra frustrating because looking through all of the linked issues on this topic, it seems to have been a known issue since 2021, and the only thing worse than spending the time rolling our own token validation is going to be discovering that you have released a version with token validation after we have built our own.

[jmprieur]

@samschurter. We want to provide a node SDK validating tokens before June 2024. We don't have a good solution until. I would not recommend validating your tokens yourselves, as there are a lot of things you could get wrong.

We'll communicate in the next week about this cc: @jennyf19

[egm9078]

I ran my code example again (which came from looking at MSAL code) and it seems to serve a need of validating and decoding tokens.

I'm now looking for feedback from your team, along with potential educational guidance. Especially now that we're aware that the goal is to provide a solution before June 2024.

What are the issues with using jsonwebtoken to validate and decode tokens generated by MSAL clients?

Our API has a need to process requests based on scopes and/or roles from the token.

[DevRCRun]

@jmprieur Thanks for coming back with the target date. The fact that we shouldn't do it ourselves in an ideal world was what prompted this thread and the ones that preceded it. I too had previously gone through the samples to get an idea of what might be necessary if we were to do it ourselves for an interim period.

Due to the suggested timescale we're now looking at what other modules might aid a suitable verification. I know auth0 have / sponsor a number of openid modules...

As @egm9078 has already asked, could you let us know what the problem has been using jsonwebtoken / jose / jwks-rsa etc? Do you see general problems with these implementations or is it more the integration with MSAL? If there is some sort of general problem you see with the way things are being done by those modules, such that you intend to roll your own, it'd be useful to open that up for discussion.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[microsoft-github-policy-service[bot]]

This issue requires attention from the MSAL.js team and has not seen activity in 5 days. @jmprieur please follow up.

[JoshCorps]

Is there any update on this?

[jbinto]

npm WARN deprecated passport-azure-ad@4.3.5: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.

The passport-azure-ad npm package was just deprecated here, and through that I was able to find this repo and this issue.

Also curious what options Azure B2C customers have for token validation in Node.js.

[EmLauber]

We have updated the deprecation notice of passport-azure-ad to now point to https://github.com/AzureAD/passport-azure-ad?tab=readme-ov-file#node-js-validation-replacement-for-passportjs. We are aware of the interest in a supported node token validation offering but don't yet have something available.

[nwalters512]

We want to provide a node SDK validating tokens before June 2024. We don't have a good solution until. I would not recommend validating your tokens yourselves, as there are a lot of things you could get wrong.

@jmprieur it's now June 2024; where do things stand here?

Assuming you don't yet have any solutions, it'd be helpful to know what exactly MSAL (and previously passport-azure-ad) do that sets it apart from libraries like https://github.com/panva/node-openid-client and https://github.com/panva/jose. That is, is there a reason users of your deprecated-without-replacement libraries shouldn't switch to generic, non-Microsoft-affiliated libraries?