OpenIddict is the identity framework you wire up yourself, not a login product

The framework refuses to be a turnkey identity provider

The clearest statement in the project's own words sits in its certification section: OpenIddict is not a turnkey solution but a framework that requires writing custom code to be operational, typically at least an authorization controller. That single line decides who owns the work. Nobody hands you a login page, a consent screen or a user store schema. You get the protocol machinery and you write the endpoint that a browser actually lands on.

This is a deliberate position, not an unfinished one. The project explains why it stays out of the certification program: a reference implementation could be submitted as is, but that would not guarantee that implementations deployed by OpenIddict users would be standard compliant. The reasoning is that compliance has to be demonstrated per deployment, not inherited from a vendor.

For a reader, the practical consequence is a line item rather than a feature list. Any estimate that treats adding OpenIddict as a package reference will be wrong by the size of one controller, one view and the identity plumbing behind them.

The repository is the library, and the tutorial lives on a documentation site

OpenIddict does not ship a getting started guide inside the repository. The README sends you elsewhere for the actual walkthrough: to implement a custom OpenID Connect server using OpenIddict, read the Getting started guide on the documentation site. Working examples sit in a separate repository, openiddict-samples.

What the repository itself contains is the engine. The top level is build machinery and source: a solution file, directory wide build props and targets, a central package versions file, a NuGet configuration, a global.json, a Build.cmd and build.sh, plus the eng, gen, sandbox, shared, src and test directories. The deliverable is compiled packages rather than a hosted product.

So the first hour with this project is not spent in the code. It is spent reading the documentation site and picking a flow, then returning to the source to find the handler type that implements it.

Three stores ship in the box and each one outlives the code that chose it

Storage is decided early and lives long. OpenIddict natively supports Entity Framework Core, Entity Framework 6 and MongoDB out of the box, and custom stores can be implemented to support other providers. The three are separate packages, referenced from the README as OpenIddict.EntityFrameworkCore, OpenIddict.EntityFramework and OpenIddict.MongoDb.

The choice is not cosmetic. Applications, authorizations and tokens are persisted through these providers, so the schema or collection layout becomes part of your deployment. Migrating later means moving data between stores.

Community projects widen the list rather than narrowing the commitment: OpenIddict.AmazonDynamoDB provides stores for DynamoDB, and P41.OpenIddict.CouchDB does the same for CouchDB. OpenIddict UI, a headless interface for managing client applications and scopes, and the ABP Framework module sit alongside them as third party work maintained outside this repository. Read the store package names as the decision you are making, not as alternatives to evaluate later.

Server code needs ASP.NET, while the client feature is the one that travels

The supported platforms are not the same for the three features, and the README draws the line explicitly. Client, server and token validation can be used in any ASP.NET 4.6.2+ or ASP.NET Core 2.3+ web application. The client feature can also be used in Android, iOS, Linux, Mac Catalyst, macOS and Windows applications, to integrate with OpenIddict based identity providers or any other OAuth 2.0 or OpenID Connect compliant implementation.

That asymmetry matters for how you plan a rollout. A worker service, a desktop tool or a mobile app cannot host the server half; it can only be a client talking to a provider. Only the ASP.NET side can issue tokens, and the operating system list applies strictly to consuming them.

The phrase at the end of that sentence is also a boundary worth respecting. The client targets OpenIddict based providers and other compliant implementations, so pointing it at a provider with different behaviour means debugging the gap yourself.

The flows are complete, including two grants most stacks leave out

Flow coverage is where the project is strongest. OpenIddict fully supports the code, implicit and hybrid flows from the OpenID Connect core specification, the client credentials and resource owner password grants, the device authorization flow in RFC 8628, and the token exchange grant in RFC 8693.

Two of those are worth pausing on. Token exchange lets one service obtain a token for another audience without the user present. The device authorization flow covers input constrained hardware; the README lists it as fully supported and links it to RFC 8628.

The resource owner password grant is also on the list, which tells you something about the project's stance: it ships the grant rather than discouraging it, so the decision to expose it belongs to you and to whatever your compliance review says about it.

The default branch is dev, and a preview release sits beside the stable ones

The default branch is dev, not main. That choice means a clone gives you the working line rather than the last stable tag, and the recent stable releases are version 7.7.2 on 2026-10-10, version 7.7.1 on 2026-09-17 and version 7.7.0 on 2026-09-06. The last push to the repository was on 2026-10-27.

Pin your packages by version and treat the dev branch as where the next major is assembled. The samples repository link in the README points at a dev branch path as well, which is the usual way to see the next major in action, and equally the easy way to end up copying code written for an unreleased API.

Conformance testing is handed back to the deployer, and the test sample drops consent

Since the framework cannot be certified as a product, the project asks each team to run the conformance tests against its own deployment once the custom logic is written. The tests are the OpenID Connect provider certification suite, and the sample prepared for them lives in the samples repository under a Contruum server project.

That sample is deliberately incomplete in a way that trips people up. It is built so the certification tests run as fast as possible, which means it contains no membership or consent feature at all, and it proposes two hardcoded identities for the tests that need to switch between identities. It demonstrates that a certified implementation is achievable; it does not demonstrate a login experience.

Copying it as a starting point means starting without the part that decides who signs in and what they are told, which is usually most of the work in a real deployment.

The README points at two paid alternatives for teams that want the parts left out

The project names its own escape hatches, and they are commercial. Developers looking for a simple and turnkey solution are strongly encouraged to evaluate Volo.OpenIddict.Pro, which is built on OpenIddict, supports the common OAuth 2.0 and OpenID Connect flows, and adds an applications and scopes management interface. That is the management layer the framework deliberately omits.

For SAML 2.0, the README names Rock Solid Knowledge, a sponsor of OpenIddict, as developing identity components, starting with a SAML2P component for talking to a SAML 2.0 identity provider or service provider. So the protocol boundary is stated plainly: OpenIddict is the OAuth 2.0 and OpenID Connect half, and SAML 2.0 is somebody else's product.

A commercial module on top of the framework changes the cost shape rather than the technical shape. The authorization controller is still yours, which is exactly the work the framework was built to let you own.

Editorial conclusion

OpenIddict fits a team that already runs ASP.NET, wants control over the consent screen and the token lifetime, and accepts owning a custom authorization controller plus its own conformance testing. It does not fit a product that needs a login server working this afternoon, and it will not save you from the OpenID Connect provider certification program, which the project itself calls a poor fit for a framework. Before committing, confirm that your store choice among Entity Framework Core, Entity Framework 6 and MongoDB is the one you want for the life of the tokens, and read the client integration notes for your platform, since the operating system support belongs to the client feature only. Version 7.7.2 shipped on 2026-10-10 and the last push to the repository was on 2026-10-27.

Frequently asked questions

Official sources

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