IdentityModel Extensions for .NET: the token validation layer behind ASP.NET auth

The support matrix decides which package you should pin

The first thing to read in this repository is not a usage guide but a table of which major versions are still alive, because the lines have different end dates and different rules.

The 8.x line is the current one, running from 8.0.1 up to the latest release, and it is tied to.NET 9 as STS and.NET 10 as LTS, with support running to roughly November 2028. The 7.x line is in long term support through the.NET 8 LTS lifetime, which ends on 2026-11-10, and the documentation is explicit that versions below 7.7.1 are not supported. The 5.x line is a separate long term support track tied to the Microsoft.Owin.Security.JWT 4.2.2 lifetime, and versions below 5.7.0 are not supported either.

The two older lines carry blunt labels. IdentityModel 6.x is marked deprecated, with support ended with the.NET 7 LTS lifetime in May 2024, and the action given is to move to 8.x. IdentityModel 5.x is marked as not a recommended version, with the same action.

The 7.x section adds a recommendation to move to 8.x. The details of each policy live in supportPolicy.md, and per version release notes are on the releases page, with older notes kept in the project wiki. The repository is not archived and the last push was on 2026-10-16, with recent releases 5.7.2, 8.23.0 and 8.22.0.

Token parsing, validation and writing in one package family

The library exists to make OpenID Connect, OAuth 2.0 and JSON Web Token work less painful in .NET code, and the documentation positions it as part of ASP.NET security, used to validate tokens in web apps and web APIs.

The separation between a handler and a token object is the part worth understanding before writing code against it. The reference documentation links to `JsonWebTokenHandler`, which suggests the newer handler-based model rather than the older `JwtSecurityTokenHandler` style, and the 7.x notes mention improvements to serialization and consistency in the API, plus full AOT compatibility on .NET and performance work relative to 6.x.

Two related package names appear in the documentation, `Microsoft.IdentityModel.JsonWebTokens` and, in the 5.x support row, `Microsoft.Owin.Security.JWT`. The latter is the OWIN-era path, which is why the 5.x line has a lifetime tied to that package rather than to a .NET release.

The scenarios the library covers are described on a wiki page, and the documentation points at separate guides for Microsoft Entra ID with ASP.NET Core, for developing ASP.NET apps with Microsoft Entra ID, and a page devoted to validating tokens, with the project wiki and the API reference as the general references.

AOT compatibility note in 7.x is a real migration signal

Two claims in the 7.x notes carry more weight than the rest of that section.

The first is full AOT compatibility on.NET. For teams trimming startup time and memory in serverless or container workloads, that changes what a token library costs at runtime, and it is the kind of property that influences whether the library can be used at all in a native AOT project.

The second is the claimed performance improvement over 6x, described as considerable. The documentation does not attach a benchmark number to it, and the repository does contain a benchmark directory and a PerfAndStress solution filter, which tells you the work exists in the tree even if the README does not cite figures. Anyone who needs a specific number should measure it themselves against their own payload mix rather than trust the adjective.

The 8.x section adds a similar pair of claims: enhanced performance from optimized token validation for high throughput scenarios, and full compatibility with.NET 9. Again, the version is described as tied to.NET 9 STS and.NET 10 LTS, which is a different way of saying the same thing in slightly confusing terms, since.NET 9 is the shorter lived of the two and.NET 10 is the long term one.

One more detail in the repository layout is relevant to how a team would consume this. The top level contains Wilson.sln and WilsonUnix.sln files, a FileList.txt, a buildConfiguration.xml and both build.sh and build.ps1, which tells you the source builds on Unix and Windows from the same tree.

What the repository contains beyond the library

The tree is bigger than a typical single purpose package, and the extra files explain how the project is validated and shipped.

There are several test playlists, OpenIdConnectMessageTests.playlist, SamlTests.playlist, TokensTests.playlist and XmlTests.playlist, which suggests the test suites are grouped by the protocol area they cover, and that SAML and XML handling sit alongside the OIDC and JWT work. A benchmark directory and the PerfAndStress.slnf filter point to a separate performance and stress lane. CodeQL.yaml means the repository runs a code scanning workflow, and SECURITY.md and SECURITY_NOTICE.md handle the reporting path.

There is also a BannedSymbols.txt, which in a C# repository is a file used to block specific symbols from being used, and a ThirdPartyNotice.txt for dependency attribution. NuGet.Config, Directory.Build.targets, global.json and pack.cmd and pack.ps1 cover the packaging pipeline.

For contributors, Contributing.md carries the guidelines, branch information and build instructions, and the project asks for a design proposal to be submitted before a pull request so that goals and priorities can be agreed first. Bugs and feature requests go through the issue tracker.

Licensing is straightforward. All code is licensed under the MIT license, and the copyright is held by Microsoft Corporation. The project also states that it adheres to the Microsoft Open Source Code of Conduct.

Picking the package and the version before you write code

The project distributes through NuGet rather than as a source drop, and the package named in the README badge is `Microsoft.IdentityModel.JsonWebTokens`, with a link to its NuGet page carrying the latest release number. The 5.x support row names a second package, `Microsoft.Owin.Security.JWT`, which is the OWIN-era path with its own lifetime.

The documentation does not give a command line install recipe, so there is nothing to copy here, and writing out a package restore command with a specific version would be guessing at the exact package set your project needs. What the documentation does support is a version decision, and it is a two step one. First choose the major line, using the support matrix to see which one your target framework allows and when that line stops being patched. Then pick a patch release inside that line, from the release notes on the releases page or the older notes in the wiki.

The first real use is a validation call in a request pipeline. The library is described as part of ASP.NET security, used to validate tokens in web apps and web APIs, and the reference documentation names `JsonWebTokenHandler` as the entry point. The wiki pages named for Entra ID with ASP.NET Core and for validating tokens carry the worked scenarios, and the reference documentation link points at `JsonWebTokenHandler` in the Microsoft Learn API browser, which is where the parameters live.

A practical note on versions: because 7.x and 8.x are both currently supported, a service that started on 7.x can move to 8.x when its runtime allows, and the two lines are separately patched in the meantime.

Where the library is the wrong choice

Two cases stand out.

The first is a service that does not validate third party tokens at all. If your API issues and consumes only its own opaque session tokens, adding a JWT stack brings parsing, key resolution and clock handling into the threat surface without buying anything. The library earns its place in the presence of OIDC, OAuth 2.0 and JWT, not in their absence.

The second is the temptation to treat a validation library as a complete security answer. It parses and validates a token. It does not decide which issuer, audience, algorithm and lifetime your service should accept, and the documentation directs developers to scenario pages and Entra ID guides for that part. A service that calls the handler without pinning accepted algorithms and audiences has still got the job to do.

There is also a version-strategy cost. The repository publishes parallel major lines with distinct support windows, and the 5.x track exists only to serve an OWIN package lifetime. Any adoption decision is really a decision about which line your target framework allows, and the matrix in the README is the authority on that.

The alternative approach for a .NET team is the platform's own ASP.NET Core authentication stack, which handles token validation as part of the framework pipeline rather than as a separate library call. The difference in approach is where the policy lives: the framework stack binds validation to the middleware pipeline, while IdentityModel gives you a handler you call and configure yourself, which is more code to write but also more direct control over cache lifetimes, key resolution and what your API does with a rejected token.

Editorial conclusion

IdentityModel Extensions for .NET is the right dependency for a .NET service that accepts bearer tokens, because it handles OIDC and JWT validation under active maintenance and ships a documented support matrix you can check against your runtime. Stay on it if you are already on 7.x until .NET 8 support ends on 2026-11-10, but do not start new work on 5.x, which is not a recommended version. Before you pin a package version, read supportPolicy.md and confirm which major line your target framework allows, and check SECURITY.md for how to report a vulnerability in the token handling code, since a flaw in that path is a flaw in your API.

Frequently asked questions

Official sources

1. AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases