MSAL.js: Microsoft's Authentication Library for Browser, Node and React
Microsoft Authentication Library (MSAL) for JS
At a glance
- What is it?
- MSAL.js is the Microsoft-supported way to sign users into Entra ID, MSA and Azure AD B2C from JavaScript. The repository ships separate packages per platform, and the version support table is the part most teams get wrong.
- Who is it for?
- Adopt MSAL.js if your identity provider is Microsoft Entra ID, MSA or Azure AD B2C and you want the vendor's own client rather than hand-rolled OAuth code. Do not adopt it as a general-purpose identity library for non-Microsoft IdPs; the README frames it entirely around the Microsoft identity platform.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 5, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What MSAL.js actually solves for JavaScript teams
Hand-writing the OAuth 2.0 authorization code flow with PKCE, then caching tokens, then refreshing them silently, then handling redirect vs popup vs iframe, is a few weeks of work that has to be redone whenever the identity platform changes a protocol detail. MSAL.js exists to absorb that work. The README describes the library as enabling both client-side and server-side JavaScript applications to authenticate users against Microsoft Entra ID for work and school accounts, Microsoft personal accounts, and social identity providers through Azure AD B2C. It also acquires tokens for Microsoft Cloud services such as Microsoft Graph.
The audience is narrow and specific. If you are building a SPA that signs in corporate users, msal-browser is the intended package. If you are building a Node backend that calls Graph as itself, msal-node is the intended package. If you are building a React or Angular app, the repository ships a wrapper over msal-browser rather than expecting you to wire the browser library into component lifecycle yourself. Teams whose identity provider is Okta, Auth0 or a self-hosted OIDC server are not the audience, and the README never positions the library for them.
Repository layout: one library, six packages, different protocols
The repository is a monorepo. The lib folder holds the packages under active development: msal-browser, msal-node, msal-react, msal-angular, plus native authentication code living at lib/msal-browser/src/custom_auth/. The extensions folder holds msal-node-extensions. The README states that install details live in each package's own README, not in the root one, which is the first place people look and the first place they get lost.
The protocol coverage differs by package, and this is the part worth reading carefully. msal-browser implements the OAuth 2.0 Authorization Code Flow with PKCE and is OpenID-compliant. msal-node implements a much longer list: Authorization Code Grant with PKCE, Device Code Grant, Refresh Token Grant, Client Credential Grant, silent flow, and the on-behalf-of flow. So a Node service that needs the client credential grant has no equivalent in the browser package, and a browser app has no device code path. The choice of package is really a choice of which OAuth grants your application is allowed to use.
There is a naming trap in the native authentication feature. The README says the codebase uses the term "Custom Auth" instead of "Native Auth", so classes and configuration options are prefixed CustomAuth, for example CustomAuthPublicClientApplication and CustomAuthConfiguration. Searching the repository for "NativeAuth" will not find the implementation. The README also notes this feature is available for SPAs on External ID for customers, which is a narrower scope than the rest of the library.
Installing MSAL.js and signing in for the first time
The root README does not contain install commands; it points at each package README. What the root repository does state is the CDN position: the @azure/msal-browser CDN was fully deprecated as of @azure/[email protected], and apps using it must move to a package manager or bundling tool. That rules out the script-tag approach that older tutorials still show.
For a browser app, the package name is @azure/msal-browser. The README gives the current major as v5 with v4 in long-term support. Installation through npm:
npm install @azure/msal-browserFor a Node service, the package is @azure/msal-node, currently at v5 with v3 in LTS:
npm install @azure/msal-nodeFor React, install the wrapper, which depends on msal-browser:
npm install @azure/msal-reactA first real use means constructing a client with a configuration object and calling a login method. The README does not print a full configuration example, but it does name the entry points: CustomAuthPublicClientApplication and CustomAuthConfiguration for the native authentication path, and the msal-browser package for the standard browser path. The repository ships working configurations in samples/msal-browser-samples, samples/msal-node-samples, samples/msal-react-samples and samples/msal-angular-samples. Read the sample for your framework before inventing a config, because the samples are the only complete, runnable configuration the repository provides. You will need an app registration in the Microsoft identity platform first; the homepage, aka.ms/aadv2, is where the README sends readers for that.
Version support, LTS and the upgrade cost nobody budgets for
MSAL.js is maintained, with the last push to the dev branch on 2026-09-23, and the releases listed in the repository include @azure/msal-react v5.7.1, @azure/msal-node v6.0.1 and @azure/msal-node-extensions v5.5.1, all dated 2026-09-15. The maintenance question is not whether it is alive but which version you are on.
The README publishes a support table with two columns, current and LTS. msal-browser is v5 current, v4 LTS. msal-node is v5 current, v3 LTS. msal-react is v5 current, v3 LTS. msal-angular is v5 current, v4 LTS. msal-node-extensions is v5 current, v1 LTS. Two packages, @azure/msal (msal-core) and @azure/msal-angularjs, are marked fully deprecated.
Read the disambiguation notes before planning an upgrade. LTS versions still receive some support and critical bug fixes but will not ship new features, and the README states the recommendation on encountering an issue is always to upgrade to the latest version. The table also records that all supported packages were brought to version parity at v5, and that packages with versions lower than v4 in the LTS column skipped as many versions as needed to jump directly to v5. That means the LTS column is not a smooth history; msal-node-extensions sits at v1 LTS while shipping v5 as current. If your dependency pinning assumes adjacent majors, it will not hold here. Note the release list contains msal-node v6.0.1 while the support table in the README lists v5 as current for @azure/msal-node, so verify the current major for your package against the published releases rather than trusting either source alone.
Where MSAL.js is the wrong tool
The clearest boundary is the identity provider. Every capability in the README is framed around Entra ID, Microsoft personal accounts, Azure AD B2C and Microsoft Graph. If your users live in a non-Microsoft directory and you have no Graph dependency, the library's main value, which is the vendor's tested implementation of Microsoft's flows against Microsoft endpoints, does not apply to you. A general OIDC client library will cover more providers with less Microsoft-specific surface.
The second boundary is the CDN removal. The README states the msal-browser CDN is fully deprecated and unsupported from version 3.0.0. Any project that cannot adopt a bundler, for example a legacy page that loads scripts directly from a CDN, has to change its build before it can take a supported version. That is a build-system migration disguised as an authentication upgrade.
The third is scope creep into native authentication. The README limits that feature to SPAs on External ID for customers. Teams on workforce tenants expecting the same end-to-end customizable sign-up and sign-in journey will not find it there. The README also carries a standing note to always use the most up-to-date version of the SDK, which is easy to write and expensive to follow in a monorepo with four packages at different majors.
MSAL.js against a general-purpose OIDC client
The obvious alternative for a JavaScript app is a provider-neutral OIDC client, for example one built around the standard authorization code flow that you point at any issuer. The difference in approach is not quality, it is where the complexity sits. A neutral client gives you the protocol and expects you to handle Microsoft-specific concerns yourself: tenant selection, the authority format, B2C user flows, silent token acquisition against the Microsoft cache, and the on-behalf-of flow for a middle-tier API.
MSAL.js moves those concerns into the library. That is why msal-node lists on-behalf-of and client credential grants as first-class supported flows, and why msal-node-extensions exists at all: the README describes it as offering secure cross-platform token cache serialization and persistence, giving additional support to msal-node. A neutral OIDC client leaves cache persistence to you, which is fine on a server where you control the process and painful in a desktop or CLI context where you do not.
The trade is portability. Choosing MSAL.js means your authentication code is shaped by Microsoft's package boundaries, its version support table and its deprecation schedule, including the CDN removal. Choosing a neutral client means you keep one integration for several IdPs but write and maintain the Microsoft-specific glue. If Microsoft is your only IdP, that glue is pure overhead. If it is one of several, the neutral client usually wins on total code.
Licence, contributions and security reporting
The repository is MIT licensed, with the LICENSE file at the root. MIT is permissive: it allows use, modification and redistribution with the copyright notice and licence text retained. That is a statement about the licence text, not legal advice about your product; if you redistribute the library inside a shipped binary or a hosted service, have your own counsel confirm the notice obligations for your distribution model.
Contributions go through the contributing guide at the repository root, and the README asks contributors to read it before starting. Security issues have a separate channel: the README directs reporters to the Microsoft Security Response Center with as much detail as possible, and notes that a submission may be eligible for a bounty. Do not open a public issue for a vulnerability. Support questions belong in GitHub Issues, the FAQ at aka.ms/msaljs-faq, or Stack Overflow under the "msal" and "msal.js" tags.
The repository also carries AGENTS.md, copilot-instructions.md and a samples/AGENTS.md, which tells you the project expects automated and agent-assisted contributions and has written conventions for them. If you plan to contribute, read those alongside contributing.md.
Editorial conclusion
Adopt MSAL.js if your identity provider is Microsoft Entra ID, MSA or Azure AD B2C and you want the vendor's own client rather than hand-rolled OAuth code. Do not adopt it as a general-purpose identity library for non-Microsoft IdPs; the README frames it entirely around the Microsoft identity platform. Before you start, check the version support table for the package you intend to install, and confirm whether your app is a public client (msal-browser) or a confidential client (msal-node), because the two packages implement different OAuth grants.
Frequently asked questions
What is the Microsoft Authentication Library for JavaScript?
It is a set of TypeScript packages that let client-side and server-side JavaScript applications authenticate users against Microsoft Entra ID, Microsoft personal accounts and Azure AD B2C, and acquire tokens for Microsoft Cloud services such as Microsoft Graph. The repository splits it into msal-browser, msal-node, msal-react, msal-angular and msal-node-extensions.
Does MSAL use OAuth?
Yes. The README states that msal-browser implements the OAuth 2.0 Authorization Code Flow with PKCE, and that msal-node implements the Authorization Code, Device Code, Refresh Token and Client Credential grants plus silent flow and on-behalf-of flow. Both are described as OpenID-compliant.
What does MSAL stand for?
Microsoft Authentication Library. The repository name is microsoft-authentication-library-for-js, and the README opens by expanding the acronym before describing the Entra ID, MSA and Azure AD B2C scenarios it covers.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/azuread-microsoft-authentication-library-for-js)