OpenIddict: an OAuth 2.0 and OpenID Connect stack for .NET that you assemble yourself

The problem OpenIddict solves: OAuth 2.0 and OIDC without someone else's product decisions

Most .NET teams facing an OAuth 2.0 or OpenID Connect requirement pick between two bad options. They either stand up a separate identity product and accept its data model, its deployment shape and its upgrade calendar, or they hand-roll tokens, discovery documents and JWKS endpoints and get the edge cases wrong. OpenIddict is aimed at the space in between. The README describes it as a "versatile solution" for implementing OpenID Connect client, server and token validation support in .NET applications, which is a precise way of saying it ships protocol machinery and leaves the application-specific parts to you.

The audience follows from that. This is for developers who already know what an authorization endpoint is and want to control what happens inside it: which clients are registered, how consent is recorded, which claims end up in an access token. The README is explicit that OpenIddict "is not a turnkey solution but a framework that requires writing custom code to be operational (typically, at least an authorization controller)". If that sentence reads as a warning rather than a feature, this is the wrong library.

The supported surface is broad. The README states full support for the code, implicit and hybrid flows, the client credentials and resource owner password grants, the device authorization flow, and the token exchange grant. The client side is not limited to web apps: the same feature can run in Android, iOS, Linux, Mac Catalyst, macOS and Windows applications, while client, server and token validation all work in any ASP.NET 4.6.2+ or ASP.NET Core 2.3+ web application.

How OpenIddict is put together: handlers, stores and three separable features

The repository layout tells you more about the architecture than the README does. There is a src/ directory holding the packages, a shared/ directory for code common to several of them, a sandbox/ directory, and a test/ directory, with the solution file OpenIddict.slnx at the root. The published packages split along the same lines: OpenIddict.EntityFrameworkCore, OpenIddict.EntityFramework and OpenIddict.MongoDb are separate NuGet packages, which means persistence is a pluggable layer rather than a hard dependency. The README confirms custom stores can be implemented to support other providers.

The functional split is the more interesting design decision. Client, server and token validation are three features of one stack, not three products. A service that issues tokens for third-party apps uses the server feature. A service that consumes tokens issued elsewhere uses token validation. An application that signs users in through Google or another compliant provider uses the client feature. Because the same library covers all three, an application can be a client to one provider and a server to another without pulling in a second identity stack.

OpenIddict also has a degraded mode, documented in the project's blog posts, that lets it act as an OpenID Connect server proxy. That is a real capability with real consequences: a proxy between two identity systems has to decide what it rewrites and what it passes through, and the project's own write-up frames it as a mode you opt into rather than the default path.

The certification section is where the design philosophy is clearest. OpenIddict does not submit itself to the OpenID Connect certification program, and the README gives the reasoning: because implementations are written by users, a certified reference implementation "wouldn't guarantee that implementations deployed by OpenIddict users would be standard-compliant". Instead the README tells developers to run the conformance tests against their own deployment, and points to a sample in the samples repository built for exactly that.

Installing OpenIddict and getting a first server running

OpenIddict is distributed on NuGet, so installation is a package reference. Which package you add depends on your storage: OpenIddict.EntityFrameworkCore for EF Core, OpenIddict.EntityFramework for EF6, OpenIddict.MongoDb for MongoDB. The README gives those package identifiers as NuGet links. It does not print a dotnet add package line, so the honest first step is to open the NuGet package pages for the identifiers the README lists and add the reference from there.

The repository keeps samples in a separate project, openiddict-samples, rather than in this tree, so the fastest honest path to a working server is to clone that repository and read the flow you need. The README names it directly: samples demonstrating the different OAuth 2.0 and OpenID Connect flows live there.

For the server feature, the README is unambiguous that the minimum viable integration includes an authorization controller. That is the piece you write. It handles the interactive part of the flow: deciding whether to show a login form, whether to ask for consent, and what to do when the user approves or denies. There is no configuration flag that generates it for you.

There is one sample worth knowing about before you start. The samples repository contains Contruum.Server, described in the README as "specially designed to be used with the OpenID Connect Provider Certification tool". It deliberately omits membership and consent features and ships two hardcoded identities so the conformance tests can switch between them quickly. That makes it a poor template for production and a good one for checking whether your protocol behaviour is correct.

If you are integrating rather than issuing, the client feature works in non-web .NET targets as well. The README lists Android, iOS, Linux, Mac Catalyst, macOS and Windows as supported platforms for the client, which matters if the same application needs to sign in against an OpenIddict-based provider or any other OAuth 2.0/OpenID Connect-compliant implementation.

What you take on when you choose a framework over a product

The largest cost is the authorization controller and everything behind it. Consent screens, user lookup, client registration and the persistence of all of it are application code. The README's own framing is that OpenIddict requires custom code "to be operational", which is a stronger statement than the usual "some assembly required". A team that has never implemented an authorization endpoint should budget for reading the specification, not just the documentation.

The second cost is compliance. OpenIddict does not hold OpenID Connect certification, and the README explains that this is deliberate rather than an oversight. The practical consequence is that conformance is your responsibility: you run the certification tool against your deployment, and the result describes your implementation, not the library. If a customer or auditor asks for a certificate naming your identity provider, no amount of OpenIddict adoption produces one.

The third cost is upgrade surface. Recent releases include 7.7.1 and 7.7.0 on the stable line and 8.0.0-preview.4 as a preview, all published within the same few weeks, and the default branch is dev rather than a release branch. That is a normal cadence for a library with an active maintainer, but it means you should pin versions and read release notes rather than float. The README does not document a rollback procedure for the database schema, so if you are running the EF Core or EF6 stores, treat schema migrations as something you plan before upgrading, not after.

Finally, OpenIddict is the wrong tool when the requirement is a running identity server. If you need an admin interface for registering clients and scopes, or you want something operational the same afternoon, a framework that ships protocol handlers and expects you to write the endpoints is a mismatch, not a challenge.

OpenIddict compared with Keycloak and the turnkey .NET options

The comparison people search for is OpenIddict versus Keycloak, and the difference is not features. Keycloak is a standalone identity server you deploy as its own service, with its own database, its own admin console and its own release cycle. OpenIddict is a library that lives inside your ASP.NET application. With Keycloak, your application talks to an external system over HTTP. With OpenIddict, the token endpoint is a route in your own process, and the client registrations sit in your own tables.

That has a concrete consequence for data. With OpenIddict and the EF Core store, user and client data live in the same database your application already uses, and consent decisions can join against your domain model. With Keycloak, identity data lives in Keycloak's schema, and synchronising it with your application's users is a problem you solve separately. Which is better depends on whether you want identity to be a bounded context of its own or a table next to everything else.

The same axis separates OpenIddict from the turnkey .NET options. The README points developers who want "a simple and turnkey solution" at Volo.OpenIddict.Pro, which is built on OpenIddict, supports the common flows and adds an applications and scopes management GUI. The OrchardCore OpenID module is another turnkey server built with multitenancy in mind. Both sit on top of the same protocol work; the difference is who writes the controller, who maintains the admin surface, and how much of the deployment shape you control. Choosing OpenIddict over them is choosing control over the data model and the endpoints, and paying for it in code you now own.

Licence and the cost of staying current

OpenIddict is licensed under Apache-2.0, and the repository carries a LICENSE.md at the root alongside a SECURITY.md for vulnerability reporting. Apache-2.0 is a permissive licence with an explicit patent grant, which is the usual reason teams pick it over a copyleft option for infrastructure code. The README also links to third-party projects built on OpenIddict, including OpenIddict.AmazonDynamoDB, OpenIddict UI and P41.OpenIddict.CouchDB, and those carry their own licences, which you should check separately if you depend on them. This is a description of what the repository states, not legal advice; if licence terms matter to your organisation, have someone qualified read LICENSE.md.

On maintenance, the evidence is recent activity rather than a promise. The last push to the default branch was on 2026-09-18, and the newest stable release, 7.7.1, was published on 2026-09-17, with 7.7.0 and the 8.0.0-preview.4 preview both dated 2026-09-06. A preview line running alongside a stable line is normal, but it means two upgrade paths exist and only one of them is meant for production. The repository is not archived.

Upgrade cost is dominated by the persistence layer. If you use OpenIddict.EntityFrameworkCore or OpenIddict.EntityFramework, a version bump can come with schema changes, and the README does not describe a downgrade path. Pin the package versions in Directory.Packages.props, read the release notes before moving, and keep the database migration reversible on your side. If you implement custom stores, the cost shifts to you entirely: the README states they are supported, and by definition nothing in the project's release notes can tell you whether your store still satisfies the contracts.

Editorial conclusion

Adopt OpenIddict if you are a .NET team that needs OAuth 2.0 or OpenID Connect behaviour shaped to your own domain and is willing to own an authorization controller and its persistence. Do not adopt it if you want a running identity server with an admin GUI on day one; the README itself points turnkey-seekers at Volo.OpenIddict.Pro or the OrchardCore OpenID module instead. Verify three things first: whether Entity Framework Core, Entity Framework 6 or MongoDB matches your storage, whether your target framework is in the ASP.NET 4.6.2+/ASP.NET Core 2.3+ range the README states, and whether you can run the OpenID Connect Provider Certification tool against your own deployment, since OpenIddict deliberately does not certify on your behalf.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openiddict/openiddict-core on GitHub
3. Project website
4. README
5. Releases