MSAL.NET: token acquisition for .NET, and the logging change that surprises teams

It acquires security tokens for protected APIs, over standard protocols

The scope is narrow and stated in the first paragraph. MSAL for .NET is part of the Microsoft identity platform for developers, formerly named Azure AD, v2.0, and it exists to acquire security tokens to call protected APIs. Underneath that sits no proprietary scheme: the library uses industry standard OAuth2 and OpenID Connect, and it also supports Azure AD B2C. Repository topics place it alongside maui, netcore and wam, which are the host surfaces the library has to coexist with rather than features it adds. Practical consequence for an architect: the token cache, refresh and redirect handling inside this library are the parts you would otherwise hand write, and they are the parts that change when the identity platform changes.

Reduced logging is on by default, and the opt out is read once

This is the section to read before an upgrade. MSAL moves selected routine Information messages down to Verbose, which is Debug in Microsoft.Extensions.Logging, and the list includes per request version banners, parameter dumps, regional authority selection, valid cache hit details and a redundant acquisition success heading. Acquisition start and result summaries stay at Information, warnings, errors and Always logs are unchanged, and PII logging settings still apply. Restoring the previous diagnostics means setting a process environment variable before you build:

MSAL_REDUCED_LOGGING=false

The default is true, and an unset, empty, true or 1 value all enable reduced logging. Boolean values are case-insensitive, and an unrecognised value leaves reduced logging enabled while raising a warning through the configured logger. The setting is captured once per MSAL application at construction and applies to its later requests and background refreshes, so changing the variable on a running host does nothing until you restart it. The change applies to MSAL applications in the process, including when MSAL is reached through Microsoft.Identity.Web or MISE, and it does not change logs emitted by those other libraries.

Only 4.77.1 and above receive security fixes

The support matrix has one row. The 4.x major version is in the Active phase, patched Monthly, with end of support Not planned, and the supported versions run from 4.77.1 to the current NuGet release. Anything below 4.77.1 is explicitly marked unsupported. Details are in supportPolicy.md at the repository root. For a team holding a pinned version this is the number to check first, because a pinned MSAL on an application that handles sign in is a security liability with a published end date rather than an open question. The library is published to NuGet under the package id Microsoft.Identity.Client.

The SLA drops support for older minor versions, on purpose

Two rules define the support commitment. Major versions are supported for twelve months after the release of the next major version, and minor versions older than N-1 are not supported. The README justifies the second rule by noting that minor versions carry bug fixes and features with non-breaking additive API changes, that applications are expected to be able to upgrade through the IDE or CLI with no friction, and that old minor versions will not be patched. When you open a new issue, you are asked to confirm you are on the latest minor version first. Practically, this converts a version pinning policy into a support requirement: an application stuck on a minor version from last year is outside the window, and the README's security section asks you to take the latest version when possible and rely on semantic versioning to keep the API surface stable.

Installing means taking the Microsoft.Identity.Client package

The README does not carry an install command, and none is invented here. It points at the NuGet package for the library, a getting started page on Microsoft Learn, a samples page, and API documentation for Microsoft.Identity.Client. The package is the whole installation story: reference Microsoft.Identity.Client in your project, configure your application registration, and call the acquire token API for the resource you need. If you want the surrounding guidance rather than just the API surface, the conceptual documentation and the getting started walkthrough are the two links to read first, and support is handled through Stack Overflow with the azure-ad-msal tag, with GitHub issues for bugs and feature requests after you have searched both.

The repository holds a library, a prototype tree and the release tooling

The root listing explains how the project is built. There is LibsAndSamples.sln plus a LibsAndSamples.sdk.slnf filter, a separate PerformanceTests.sln, src/ for the library, prototype/ for exploratory work, tests/, eng/ and build/ for the pipeline, tools/ for helper scripts, docs/ and media/ for documentation assets. Dependency versions are centralised in Directory.Packages.props with common properties in Directory.Build.props, and global.json pins the SDK, which is the modern .NET answer to the long maintenance of a multi targeted library. Release notes live in RELEASES.md and changelog.txt, plus CHANGELOG.md, so a version's contents can be checked without leaving the repository.

Against Microsoft.Identity.Web or hand written OAuth calls

There are two alternatives worth naming, and they sit at different levels. The README says reduced logging also applies when MSAL is used through Microsoft.Identity.Web. The other alternative is writing the OAuth2 and OpenID Connect flow yourself against the platform documentation. That gives you full control and full responsibility for cache, refresh and redirect handling, in a library whose whole value is that Microsoft's engineers keep those parts correct as the platform evolves.

Editorial conclusion

MSAL.NET is the right choice for a.NET application that needs tokens for Microsoft identity platform APIs or Azure AD B2C and wants the protocol handling, token cache and refresh behaviour maintained by the platform vendor, and the monthly 4.x cadence with a stated support matrix means you can plan upgrades around a published schedule. Do not adopt it on an old minor version, since minor versions older than N-1 receive no fixes and anything below 4.77.1 is unsupported outright. Before you upgrade, read the reduced logging section: the default moves version banners, parameter dumps, regional authority selection and cache hit details to Verbose, and MSAL_REDUCED_LOGGING=false is captured once when the MSAL application is constructed, so changing the environment variable requires a host restart. 4.91.0 was released on 2026-10-12.

Frequently asked questions

Official sources

1. AzureAD/microsoft-authentication-library-for-dotnet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases