DEV Community: Stefano Pinato

Why You Shouldn't Build Your Own Authentication From Scratch

Stefano Pinato — Sun, 18 Oct 2026 16:03:26 +0000

The cost is not writing it, it is keeping it right

TL;DR: A working login takes an afternoon. What costs money is everything that keeps it correct afterwards: password hashing that has to be tuned, keys that have to rotate, protocol guidance that changes, passkeys and recovery flows, abuse protection and an audit trail. This article lists those ongoing costs with sources, says honestly when building your own is the right call, and shows how to price the alternative.

What "from scratch" actually means

The phrase covers three very different things, and most of the confusion in this debate comes from mixing them up.

Approach	What you write	What you keep maintaining
Hand-rolled	Password hashing, sessions, token issuing, reset flows	All of it, including the cryptographic choices
Framework building blocks (ASP.NET Core Identity, OpenIddict)	The screens, the policy, the glue, and for a token server, the whole server around the library	Configuration, upgrades, keys, recovery, operations
Packaged server or cloud service	Client registrations and settings	Configuration and upgrades, or a subscription

ASP.NET Core Identity is not "from scratch". Microsoft's documentation describes it as managing users, passwords, profile data, roles, claims, tokens and email confirmation, with support for external providers. If your need is one web application with its own user store, it is a perfectly reasonable foundation, and nothing below argues against it. The argument is about the point where that stops being enough, and about the second row of the table, where you still own a lot.

What sits under the login form

Each item below is a piece of work that does not end when the feature ships.

Password storage that has to be upgraded

OWASP's Password Storage Cheat Sheet covers Argon2id, scrypt, bcrypt and PBKDF2, and treats the work factor as something you raise over time as hardware gets cheaper. Its usual approach is to re-hash a password with the new settings the next time the user signs in. ASP.NET Core Identity's default hasher uses PBKDF2 with a default of 100,000 iterations, writes a version marker into every hash so older ones still verify, and can report that a correct password should be re-hashed. A hand-rolled scheme needs that upgrade path designed in from day one, which is easy to skip and hard to add later.

Keys that rotate, persist and survive a deployment

ASP.NET Core's Data Protection system, which protects cookies and many other payloads, creates keys with a default lifetime of 90 days and rolls them automatically. It also documents the trap: unless the environment provides a persistent location, keys are not persisted outside the process, and in a container they should be stored on a volume or in an external provider. Deleting a key makes everything protected with it permanently unreadable. None of this is exotic, but each deployment target needs someone to have thought about it. A token server adds signing and encryption certificates on top, with their own expiry dates and their own rotation.

A protocol that keeps moving

RFC 6749, the OAuth 2.0 core specification from 2012, was updated in January 2025 by RFC 9700, the current best-practice document for OAuth security, which also updates RFC 6750 and RFC 6819. It asks for exact redirect URI matching and PKCE for public clients, advises against the implicit grant and forbids the password grant. An implementation that was reasonable when you wrote it can drift out of line without a single line of your code changing. I walked through the practical consequences in What happens when your authentication is misconfigured.

Passkeys, second factors and the recovery question

.NET 10 added passkey support to ASP.NET Core Identity, which is a real step forward, and its documentation is candid about the edges. Passkeys are treated as a primary sign-in factor, not as a second factor. Attestation statements are not validated by default. Only the Blazor Web App template includes passkey support out of the box. For apps that allow passkeys as the only credential, recovery is left to you: the documentation suggests recovery codes, email-based flows or requiring several passkeys. It also notes that you may need to revoke credentials if a particular authenticator model turns out to be vulnerable. Microsoft's multi-factor authentication documentation adds that SMS as a second factor is no longer recommended, pointing to NIST's digital identity guidelines. Choices like these are product decisions that someone has to own and revisit.

Abuse protection and an audit trail

Lockout, rate limiting and detection of credential stuffing are not features you build once. They need tuning against real traffic, and OWASP keeps a separate cheat sheet on credential stuffing prevention for a reason. When something does go wrong you want to answer who signed in, who failed, which account was locked and which tokens were revoked. That means recording security events deliberately, from the start, in a form you can query.

💡 The pattern behind the list

Every item has a build cost, which is visible, and a maintenance cost, which is not. The maintenance cost is paid by whoever is on the team in two years' time, usually without having seen the original decision.

When building it yourself is the right call

It is a short list, but it is not empty:

One application, one user store, no third-party clients. ASP.NET Core Identity alone is enough, it is maintained by Microsoft, and adding an OpenID Connect server would be over-engineering.
Authentication is your product. If you are building an identity provider, you own all of it by definition.
A constraint that rules out third-party components. Some environments do not allow them. Then the maintenance list above is the budget you are signing.
Learning. Building a small authorization server once is the best way to understand one. Just do not point real users at it. What changes the answer is growth in the requirements: a second application that should share the sign-in, a mobile client, an API consumed by someone else, partners who need tokens. At that point you are no longer adding a login to an app, you are operating a token server, and the second row of the table above becomes a project.

Buying is not free of work either

A packaged server or a cloud service moves the maintenance, it does not remove it. You still configure it, upgrade it and watch what it does. And you take on vendor risk, which is real: IdentityServer4's end of life left many teams with an unpatched server in front of their login. Before you choose anything, check who maintains it, how recently it was updated and what happens to you if that stops.

For a .NET team that wants a self-hosted token server with the work above already done, IdentitySuite (which I build, so weigh this part accordingly) is one option. It is built on OpenIddict and ASP.NET Core Identity, and the settings files that ship with it include:

Passkey sign-in, switched on in the shipped templates, alongside authenticator-app two-factor authentication and recovery codes.
Sign-in with Google, Microsoft, Facebook, GitHub, LinkedIn and Apple.
Lockout after repeated failures and rate limiting per endpoint class, both enabled in the templates.
Built-in signing and encryption certificates that are rotated automatically as they near expiry, with an expiry alert, instead of keys you manage by hand.
A security audit log with sign-in successes and failures, lockouts, two-factor events, passkey events and token revocations. It does not remove the maintenance entirely: you still run it, configure it and keep it updated, and it is a younger product with a smaller ecosystem than the established ones. If you want to see what adopting it looks like, the Authentication Made Easy article adds authentication to a single-page app with it.

How to price the decision

I will not invent a number of person-months for you; it depends on your team and your requirements. The comparison is easier than it looks, though. List the capabilities above that you need, estimate the first build and the yearly upkeep for each in hours, and multiply by your own hourly cost.

Then compare that with the price of the alternative. IdentitySuite's Standard plan is €349 per year. As an illustration only, at an assumed €60 per hour that is under six hours of one developer's time. The question is whether you would spend more than that in a year on key rotation, upgrades, checking security guidance and reading audit logs, before writing any feature at all. Use your own rate; the shape of the answer rarely changes.

If you want to see what each plan includes, the pricing page has the details.

What Happens When Your Authentication Is Misconfigured

Stefano Pinato — Sun, 04 Oct 2026 19:00:26 +0000

Six settings that decide whether an attack works

TL;DR: Some of the most common weaknesses in a login system are not bugs in a framework, they are settings: a redirect URI that matches too loosely, a client that is allowed to skip PKCE, a token that stays valid for a day. This article walks through six of them — what each one lets an attacker do, how to check it on your own server in a few minutes, and what the settings files that ship with IdentitySuite do about it. One of the six, CORS, is not locked down by default, and I say so where it comes up.

Why configuration is the weak point

OAuth 2.0 and OpenID Connect are flexible on purpose. The same server can issue tokens to a browser app, a phone, a backend service and a TV, and each of those needs different rules. The protocol leaves those rules to the person configuring the server, and a server enforces only what it has been told to enforce.

The IETF's current security guidance, RFC 9700 (Best Current Practice for OAuth 2.0 Security, published January 2025), reads largely as a list of settings: match this exactly, require that, do not use the other. Four of the six topics below — redirect URIs, PKCE, token lifetimes and the implicit flow — are addressed directly in it. The other two, CORS and client secrets, are deployment mistakes rather than protocol ones.

If you configure OpenIddict yourself, the pitfalls article covers the same ground from the code side. Here the angle is the attacker's: what does each mistake buy them, and how do you find out whether you have it?

1. Redirect URIs that match too loosely

After you sign in, the authorization server sends the authorization code to the client's redirect_uri. If the server accepts anything that merely resembles the registered value — a prefix, a wildcard, a different case, any path under the same host — the attacker gets to choose where the code goes.

What the attack looks like. The attacker builds a link to your real login page with a redirect_uri pointing somewhere they control, or at a page on your own domain that forwards visitors elsewhere. The user signs in on your genuine page, and the code lands with the attacker. RFC 9700 requires authorization servers to compare redirect URIs against the registered ones with exact string matching, with one exception: the port of a loopback address in a native app.

How to check. Take a URI you have registered and request it with small changes: an extra path segment, different letter case, an added query string, another port, a subdomain, http instead of https. Every variant must be refused before the login page appears. Then read through the registered URIs of your production clients and look for localhost, plain http and anything that looks like a pattern.

What IdentitySuite does. The client form stores each redirect URI as a complete absolute URI, one entry per URI; there is no field for a pattern. Matching is done by OpenIddict, which compares the values as case-sensitive strings and relaxes only the port of a loopback address, and only for clients registered as native applications. That is the behaviour RFC 9700 asks for. What exact matching cannot do is tell you that a registered URI should not be there: a leftover https://localhost entry on a production client is matched exactly like any other.

⚠️ Open redirectors cancel exact matching

If a page on your client, correctly registered as a redirect URI, forwards the browser to whatever address a query parameter says, the code can still be carried out through it. RFC 9700 tells clients not to expose such redirectors. Exact matching on the server is only half of the defence.

2. PKCE supported but not required

PKCE ties an authorization code to the client instance that started the flow. The client sends a hash of a secret value when it begins (code_challenge) and the secret itself when it redeems the code (code_verifier). A server that supports PKCE will honour it when a client uses it. A server that requires it will refuse the request when the challenge is missing. Those are different security properties.

What the attack looks like. Authorization codes leak in more places than people expect: another app registered for the same custom scheme on a phone, a browser extension, a proxy log, a compromised hop in a redirect chain. Without PKCE, whoever holds the code can exchange it for tokens. With PKCE required, a stolen code is useless without the verifier. If PKCE is only optional, the attacker can craft the sign-in link themselves and leave the challenge out. RFC 9700 says public clients must use PKCE and recommends it for confidential clients too.

How to check. Send an authorization request that has everything except code_challenge:

https://id.example.com/connect/authorize?client_id=spa&response_type=code
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
    &scope=openid&state=abc123

You should get an error response, not a login page. If you get the login page, any code issued for that client can be redeemed by whoever holds it.

What IdentitySuite does. The settings files that ship with the product set RequireProofKeyForCodeExchange to true in the Development, Staging and Production templates, and the admin UI's single-page app, web and native client templates also add the PKCE requirement to the client itself. One caveat: the default of that option in the code is false. The protection comes from the settings file, so if you start from your own file rather than the shipped one, check the value. OpenIddict itself does not enforce PKCE unless you tell it to, either globally or per client.

3. Tokens that live too long and cannot be revoked

A bearer token works for whoever holds it. Its lifetime is the window an attacker has after a leak, and a self-contained JWT cannot be recalled before it expires. Refresh tokens matter even more: a refresh token that lasts weeks and can be reused indefinitely is a long-lived credential sitting on a device.

What the attack looks like. A token ends up in a log, a crash report or a browser profile that is later copied. With a 24-hour access token the attacker has a day; with a refresh token that never rotates, they can keep minting new access tokens until it expires. RFC 9700 points out that refresh tokens exist so the authorization server can issue access tokens with a short lifetime, and requires refresh tokens for public clients to be either sender-constrained or rotated.

How to check. If you use JWT access tokens, decode one and subtract iat from exp; then ask what you would do if that token leaked right now. Use a refresh token twice: after rotation the second use should fail, allowing for a short grace period that exists for concurrent requests. Finally revoke a token and call your API with it. If the call still succeeds, revocation is not doing what you think it does.

What IdentitySuite does. The shipped settings use an access token lifetime of 30 minutes, an identity token lifetime of 30 minutes, an authorization code lifetime of 5 minutes and a refresh token lifetime of 14 days. Access and refresh tokens are reference tokens: the client holds an opaque handle and the token itself stays in the database, so revoking one is a change to a database record. Access token encryption is on. OpenIddict rotates refresh tokens by default — each use redeems the old one and issues a new one — and IdentitySuite does not turn that off.

💡 What reference tokens cost

An API that receives an opaque token cannot validate it locally; it asks the authorization server through introspection, which is a database lookup per request. That is the price of being able to revoke instantly, and the article on protecting a Web API shows how the validation side looks. Thirty minutes is a default, not a recommendation: for a sensitive API, lower it. For background on the token formats themselves, see What are JWT tokens.

4. CORS that allows every origin

Cross-origin resource sharing tells a browser which other sites' scripts may read responses from your server. A wildcard origin is not an exploit on its own — browsers will not combine it with credentialed requests — but it widens what any web page can read from your server on behalf of a visitor. The dangerous variant is a server that echoes back whatever Origin it receives and allows credentials: any site a signed-in user visits can then read authenticated responses.

What it means for an identity server. Its discovery document and key set are public by design, and single-page apps legitimately call the token endpoint from the browser. The more realistic damage is the habit of copying a permissive policy onto the APIs and admin endpoints that sit next to it.

How to check. Send a request with an origin that should not be allowed and look at the response headers:

curl -si -H "Origin: https://evil.example" \
  https://id.example.com/.well-known/openid-configuration | grep -i "access-control"

Repeat it for the token endpoint and for any endpoint that uses cookies. You are looking at Access-Control-Allow-Origin and Access-Control-Allow-Credentials.

What IdentitySuite does. This is the one default I would not call locked down. The Cors section of the shipped settings has an empty AllowedOrigins list, and when that list is empty the server allows any origin. Credentials are not allowed by default, so the combination that makes a wildcard dangerous is absent. In production you should still list the origins you actually use:

"Cors": {
  "AllowedOrigins": [ "https://app.example.com" ],
  "AllowCredentials": false
}

5. Secrets where anyone can read them

OAuth divides clients into two kinds. A confidential client can keep a secret: a server-rendered web app, a backend service. A public client cannot: a single-page app, a mobile or desktop app. Anything you ship to a user's device is readable by that user, so a client secret inside a JavaScript bundle or an app package is not a secret.

What the attack looks like. Someone opens the bundle, finds the client_id and client_secret, and can now authenticate to your server as that client — wherever the server relies on the secret as proof of identity. The fix is not to hide the secret better. Public clients should not have one; they rely on PKCE instead.

How to check. Search your front-end build output, your mobile app package and your repository history for client_secret and for the secret values themselves. Then list the clients on your server and compare each one's type with where it actually runs.

What IdentitySuite does. The admin UI distinguishes public from confidential clients. The single-page app and native app templates create public clients with no secret and PKCE required; the machine-to-machine template creates a confidential one. The form cannot see your JavaScript bundle, though: if a confidential client's secret gets pasted into front-end code, nothing on the server will notice.

6. The implicit flow and the password grant still switched on

The implicit flow returns tokens directly in the redirect, in the URL fragment. It was invented when browsers could not make cross-origin requests to a token endpoint; they can now, and PKCE exists. The resource owner password credentials grant hands the user's actual password to the client.

What the attack looks like. Tokens in a URL end up in browser history, referrer headers, logs and extensions, and nothing binds them to the client that received them. RFC 9700 says clients should not use the implicit grant or any response type that issues access tokens in the authorization response, and that the password grant must not be used at all.

How to check. Fetch the discovery document and read two lists:

curl -s https://id.example.com/.well-known/openid-configuration
# look at: response_types_supported, grant_types_supported

If token, id_token token or password appears there, at least one client can be enabled to use them.

What IdentitySuite does. The shipped settings set AllowImplicitFlow and AllowPasswordFlow to false. There are two layers: the server-level switch decides whether a flow exists at all, and a per-client permission decides which clients may use it — OpenIddict rejects a request for a feature the client has not been granted. The admin UI still offers a legacy single-page app template that configures the implicit flow, for applications that cannot move yet; it needs the server-level switch on as well.

The six checks on one page

Setting	Quick check	IdentitySuite shipped settings
Redirect URIs	Request altered variants of a registered URI	Full URIs only, exact matching by OpenIddict. Review leftovers.
PKCE	Authorization request without `code_challenge`	Required server-wide in all three templates
Token lifetimes	Subtract `iat` from `exp`; reuse a refresh token; revoke and retry	30 min access, 14 days refresh, reference tokens, rotation on
CORS	Request with a foreign `Origin` header	Not restricted: empty list means any origin, credentials off. Set it.
Client secrets	Search bundles, packages and repository history	SPA and native templates are public, no secret
Implicit / password	Read the discovery document	Both off at server level

Defaults help, but they are not a review

A settings file is a starting point. Teams copy it between environments, edit it under pressure and forget what changed, so run these checks again after any change to the authorization server, not just once at launch. The six here are the ones I would look at first; they are not a complete list.

Everything above assumes the server you run is still receiving fixes. If you are on IdentityServer4, that assumption no longer holds, and this comparison of your options is the place to start. If you want the background on the protocol behind all of this, the OAuth 2.0 explainer covers the flow step by step.

Want to run these checks against a server of your own? Get started with IdentitySuite for free.

IdentityServer4 Is End-of-Life — Your Options in 2026

Stefano Pinato — Mon, 21 Sep 2026 20:13:41 +0000

Your options in 2026

TL;DR: IdentityServer4 has been out of support since December 2022 and its GitHub repository was archived in March 2025. If you are still running it in production, you are running unpatched, security-critical infrastructure. This article compares six real replacement paths — Duende IdentityServer, Open.IdentityServer, OpenIddict, Keycloak, a cloud identity provider, and IdentitySuite — on cost, effort, stack fit, and data control, with sourced numbers so you can make the call yourself.

What "end of life" actually means for a security-critical component

IdentityServer4's own archived repository states it plainly: the project "went out of support when .NET Core 3.1 end of support was reached (13th Dec 2022)." It was forked as Duende IdentityServer and, as the same notice explains, "contains multiple known security vulnerabilities and bugs, and has outdated documentation." The repository itself was archived on 6th March 2025 — read-only, no further commits, ever.

This is not a library that is merely "unmaintained" in the sense of slow releases. It is the authorization server sitting in front of your login, your tokens, and your session management — with known, unpatched vulnerabilities and no one watching for new ones.

⚠️ Why this is worse than a typical outdated dependency

An outdated logging library fails loudly. An outdated authorization server fails silently — it keeps issuing tokens, keeps authenticating users, and gives no indication that a known exploit for a redirect URI bypass or a token validation flaw applies to your exact deployment, because no one is publishing patches to compare against anymore.

The six options, compared

All prices and figures below are as verified in September 2026, sourced from each vendor's own pricing and product pages — check current figures before deciding, since commercial pricing changes.

Option	Cost	Effort to get productive	Stack	Data control
Duende IdentityServer	$5,750–$24,900/yr, or free Community Edition if you qualify	Low-medium — closest conceptual match to IS4	.NET	Full (self-hosted)
Open.IdentityServer	Free core; admin UI and add-ons £2,528–£8,932/yr	Medium — core is free, tooling is a la carte	.NET	Full (self-hosted)
OpenIddict (DIY)	Free (Apache-2.0)	High — you build and secure everything yourself	.NET	Full (self-hosted)
Keycloak	Free (open source)	Medium-high — capable, but a second stack to operate	Java / JVM	Full (self-hosted)
Cloud IdP (Auth0, Entra)	Free tier, then usage-based (e.g. Auth0 from $35/mo, scales with MAU)	Low — fastest to a working login	Vendor-managed	Limited — data lives with the vendor
IdentitySuite	Free (3 clients) / €349/yr / €1,499/yr — flat	Low — admin UI, email and theming included	.NET	Full (self-hosted)

Duende IdentityServer — the official successor

Duende IdentityServer is built by the original authors of IdentityServer4 and is the direct, spec-compliant continuation of that project. If you want the path with the least conceptual distance from what you already have, this is it — the configuration model, the extensibility points, and the mental model all carry over closely.

It is a commercial product. As of September 2026, published annual pricing runs Lite at $5,750 (1 production deployment, 2 client IDs), Standard at $12,500 (10 client IDs, server-side sessions), and Advanced at $24,900 (30 client IDs, SAML, automatic key management), with a Custom tier above that. There is also a free Community Edition — feature-equivalent to Standard, not a crippled trial — for organizations under $1M USD projected annual revenue and $3M USD in capital access, or non-profits with a published annual budget under $1M USD. When you outgrow those thresholds, you move to a paid tier on the same platform.

The honest trade-off: Duende gives you the framework, not a finished product. Admin UI, theming, and email templates are not included — you build them or buy them separately (commonly from third-party vendors in the ecosystem). For a team that wants to own that layer, this is a feature. For a team that just wants working authentication, it is additional scope.

Open.IdentityServer — the free, open-source fork

Open.IdentityServer is a separate project from Rock Solid Knowledge (RSK), a .NET consultancy with a long history in the IdentityServer ecosystem. It continues the Apache-2.0-licensed IdentityServer4 codebase as a free, open-source SDK — not a recompilation, but an actively maintained fork with new fixes and features. RSK is explicit that the project is not affiliated with or endorsed by Duende Software, which is a credible, honest disclosure rather than a red flag.

The free-forever claim is real, but it covers the protocol SDK only — there is no admin UI, email builder, or theme builder included. Those come from RSK's separate commercial add-ons: a standalone AdminUI license runs £2,528/yr (Enterprise, unlimited users and clients, one production environment) or £8,932/yr (Universal, multiple environments), and a "Supporter License" bundling AdminUI plus passkeys, SAML, SCIM, WS-Fed, key rotation and policy-based access control costs £5,750/yr for everything. Once you add a management UI to the free core, the total is comparable to — sometimes above — what a batteries-included commercial product costs.

It is a legitimate option if you specifically want an Apache-licensed, community-auditable continuation of the IS4 codebase and are prepared to assemble the rest of the stack yourself or pay for RSK's components.

OpenIddict — free, flexible, and entirely on you

OpenIddict is a free, Apache-2.0-licensed OAuth 2.0/OpenID Connect framework for .NET, and it is what IdentitySuite itself is built on. There is no license cost and no vendor to negotiate with. The trade-off is that OpenIddict is a toolkit, not a product: there is no admin UI, no user management screens, no email flows — you write all of it, and you are responsible for getting the security-sensitive parts right.

I covered exactly how much can go wrong in that process in a dedicated article — development certificates left in production, missing PKCE enforcement, loose redirect URI validation. None of these are bugs in OpenIddict; they are the cost of the flexibility it gives you. If your team has the time and the security expertise to configure it correctly and keep it that way, this is the cheapest option on the list in license terms. It is rarely the cheapest in engineering time.

Keycloak — powerful, free, and a different stack

Keycloak is a mature, free, open-source identity and access management platform with a large feature set: SSO, identity brokering, fine-grained authorization, and a large plugin ecosystem. For organizations that already run Java/JVM infrastructure and have operations capacity for it, it is a genuinely strong choice with no license cost.

For a .NET team, the honest downside is operational: you are adding a second runtime and deployment model to maintain, with upgrade cycles, resource requirements, and theming conventions that follow Java tooling patterns rather than the ones your team already uses day to day.

Cloud identity providers — fastest start, ongoing usage cost

Auth0 and Microsoft Entra External ID are the two most common cloud options. Auth0's current pricing (September 2026) includes a free tier up to 25,000 monthly active users, after which paid plans start at $35/month and scale with MAU and feature tier, up to custom enterprise pricing. There is no infrastructure to run, patch, or scale — you get a working login in hours, not weeks.

The trade-off is the one every per-MAU pricing model shares: cost grows with your user base, and your identity data lives in the vendor's infrastructure rather than yours. For products with a small, stable user count this is rarely an issue. For products expecting significant user growth, or with data residency requirements, it is worth modeling the cost curve before committing.

IdentitySuite — self-hosted, .NET-native, flat pricing

IdentitySuite is built on the same foundation as the DIY path above — OpenIddict and ASP.NET Core Identity — but ships the admin UI, email template builder, theme builder, and passkey support as part of the product, not as something you build or buy separately. It is self-hosted, so your data stays on your infrastructure, and licensing is flat rather than usage-based: free for up to 3 clients, €349/year (Standard) or €1,499/year (Enterprise), with no per-user or per-MAU cost.

The trade-off, stated plainly: it is a younger product than Duende or Keycloak, with a smaller ecosystem and community around it. If you need SAML, deep extensibility hooks accumulated over a decade, or a large plugin marketplace today, that maturity gap is real and worth weighing. What you get in exchange is a working authorization server with an admin UI on day one, for a .NET team that does not want to own the configuration surface described in the OpenIddict section above.

A framework for deciding

You want the officially-blessed successor and can absorb commercial pricing (or qualify for the free Community Edition) → Duende IdentityServer.
You want a free, Apache-licensed continuation of the exact IS4 codebase and are willing to assemble or buy the rest of the stack separately → Open.IdentityServer.
You have the engineering time and security expertise to own every configuration decision, and license cost is the priority → OpenIddict, direct.
Your organization already runs Java/Kubernetes infrastructure with ops capacity → Keycloak.
You want zero infrastructure to manage and a usage-based cost curve fits your growth plan → a cloud identity provider.
You are a .NET team that wants a self-hosted, batteries-included product at flat, predictable pricing → IdentitySuite. Whichever path you choose, the one option that is no longer on the table is staying on IdentityServer4. If you want the deeper background on the framework several of these options build on, What is OpenIddict? is a good starting point.

Ready to see the self-hosted, flat-pricing option in practice? Get started with IdentitySuite for free.

Machine-to-machine authentication — when your services need to talk without a user

Stefano Pinato — Mon, 14 Sep 2026 17:01:04 +0000

When your services need to talk without a user

You have two backend services. One needs to call the other securely — no browser involved, no user clicking a login button, no redirect flow. Just service A proving its identity to service B and getting access to what it needs.

This is machine-to-machine (M2M) authentication, and it is one of the most common scenarios in modern distributed systems. OAuth 2.0 has a grant type designed exactly for this: the Client Credentials flow.

What makes M2M different

Most OAuth 2.0 flows involve a user: someone clicks a button, authenticates, and grants consent. The resulting token represents that user's identity and permissions.

In M2M scenarios, there is no user. Service A is acting on its own behalf — not on behalf of any person. The token it receives represents the service itself, not a human identity. This means no login screen, no consent dialog, and no redirect. The exchange happens entirely between the service and the authorization server, programmatically and invisibly.

This is also a case where you need plain OAuth 2.0 — no OpenID Connect layer required, because there is no user identity to establish.

The flow in plain terms

The Client Credentials flow is the simplest OAuth 2.0 flow. It involves three steps:

Service A authenticates with the authorization server — using its own client ID and client secret, it requests an access token for a specific scope.
The authorization server verifies the credentials and issues a token — if the client ID and secret are valid and the requested scope is allowed, a token is returned. No user involved, no consent required.
Service A calls Service B with the token — the token travels in the Authorization: Bearer header, and Service B validates it before processing the request. > 💡 Token caching matters > > Unlike user tokens, service tokens can and should be cached. Requesting a new token for every API call adds unnecessary latency and load on the authorization server. Cache the token and refresh it only when it is about to expire.

Step 1 — configure the client in IdentitySuite

Before writing any code, register Service A as a client in IdentitySuite with the Client Credentials flow enabled, and define which scopes it is allowed to request. This is done through the admin UI — no code required.

Once registered, you will have a client ID and client secret for Service A, and a scope that Service B will use to validate incoming requests.

Step 2 — requesting a token from Service A

Service A needs to obtain a token before calling Service B. The cleanest way to handle this in .NET is to use a typed HttpClient with a delegating handler that automatically acquires and caches the token:

// appsettings.json
{
  "AuthorizationServer": {
    "Authority": "https://your-identitysuite-instance.com",
    "ClientId": "service-a-client-id",
    "ClientSecret": "service-a-client-secret",
    "Scope": "service-b-scope"
  }
}

// Program.cs — Service A
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient("ServiceB", client =>
{
    client.BaseAddress = new Uri("https://service-b.internal");
});

builder.Services.AddSingleton<TokenService>();

// TokenService.cs — acquires and caches the access token
public class TokenService
{
    private readonly IHttpClientFactory _factory;
    private readonly IConfiguration _config;
    private string? _cachedToken;
    private DateTime _tokenExpiry;

    public TokenService(IHttpClientFactory factory, IConfiguration config)
    {
        _factory = factory;
        _config = config;
    }

    public async Task<string> GetTokenAsync()
    {
        if (_cachedToken is not null && DateTime.UtcNow < _tokenExpiry)
            return _cachedToken;

        var client = _factory.CreateClient();
        var authority = _config["AuthorizationServer:Authority"];

        var response = await client.PostAsync($"{authority}/connect/token",
            new FormUrlEncodedContent(new Dictionary<string, string>
            {
                ["grant_type"]    = "client_credentials",
                ["client_id"]     = _config["AuthorizationServer:ClientId"]!,
                ["client_secret"] = _config["AuthorizationServer:ClientSecret"]!,
                ["scope"]         = _config["AuthorizationServer:Scope"]!
            }));

        response.EnsureSuccessStatusCode();

        var json = await response.Content.ReadFromJsonAsync<JsonElement>();
        _cachedToken = json.GetProperty("access_token").GetString()!;
        var expiresIn = json.GetProperty("expires_in").GetInt32();
        _tokenExpiry = DateTime.UtcNow.AddSeconds(expiresIn - 30); // 30s buffer

        return _cachedToken;
    }
}

Step 3 — calling Service B with the token

Once the token is available, attaching it to the outgoing request is straightforward:

public class ServiceBClient
{
    private readonly IHttpClientFactory _factory;
    private readonly TokenService _tokenService;

    public ServiceBClient(IHttpClientFactory factory, TokenService tokenService)
    {
        _factory = factory;
        _tokenService = tokenService;
    }

    public async Task<string> GetDataAsync()
    {
        var token = await _tokenService.GetTokenAsync();
        var client = _factory.CreateClient("ServiceB");

        client.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", token);

        return await client.GetStringAsync("/api/data");
    }
}

Step 4 — validating the token in Service B

Service B validates the incoming token using OpenIddict introspection, exactly as described in protecting a .NET Web API with tokens. The only difference is that the claims available in HttpContext.User will reflect the service identity rather than a user identity — there is no name or email, but there is a sub claim identifying the client, and the scopes granted to it.

// Program.cs — Service B
builder.Services.AddOpenIddict()
    .AddValidation(options =>
    {
        options.SetIssuer(builder.Configuration["AuthorizationServer:Authority"]!);
        options.AddAudiences(builder.Configuration["AuthorizationServer:ClientId"]!);

        options.UseIntrospection()
               .SetClientId(builder.Configuration["AuthorizationServer:ClientId"]!)
               .SetClientSecret(builder.Configuration["AuthorizationServer:ClientSecret"]!);

        options.UseSystemNetHttp();
        options.UseAspNetCore();
    });

builder.Services.AddAuthentication(OpenIddictValidationAspNetCoreDefaults.AuthenticationScheme);
builder.Services.AddAuthorization();

app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/api/data", () => Results.Ok("protected data"))
   .RequireAuthorization();

When M2M authentication is the right choice

The Client Credentials flow is the right tool whenever there is no human in the loop:

Microservices — service-to-service calls in a distributed architecture where each service needs to prove its identity to the others.
Background jobs and scheduled tasks — a worker process that calls an API periodically, without any user context.
Data pipelines and integrations — a system that ingests or exports data from an API on a fixed schedule.
Internal tooling — admin scripts or automation that need authenticated access to internal APIs. If a user is involved at any point in the flow — even indirectly — the Authorization Code flow with PKCE is more appropriate. The Client Credentials flow is specifically for service identities, not user identities.

The authorization server side

The code above assumes a running authorization server that supports the Client Credentials flow. I've been building IdentitySuite, a self-hosted OIDC/OAuth 2.0 identity server for ASP.NET Core, and it supports this out of the box — client registration, scope management, and token issuance are all handled through the admin UI, with no additional configuration required on the server side. The Client Credentials flow is enabled per client, so you have full control over which services are allowed to authenticate this way.

What are JWT tokens and why your app needs them

Stefano Pinato — Mon, 07 Sep 2026 18:01:08 +0000

What they are, how they work, and why your app needs them

You log into an application. A few seconds later, you are in — and the app knows who you are, what you are allowed to do, and keeps knowing it for the rest of your session. But how? The server did not ask you to log in again on the next page. It did not look you up in a database on every click. Something is carrying your identity around, and in most modern applications, that something is a JWT token.

This article explains what JWT tokens are, what they contain, and why they have become the standard mechanism for authentication in modern applications.

The problem JWT tokens solve

Before tokens, the most common approach was server-side sessions. When you logged in, the server created a session record in memory or in a database, assigned it an ID, and sent that ID to your browser as a cookie. On every subsequent request, the browser sent the cookie back, the server looked up the session, found your user data, and proceeded.

This works — but it has limitations. The server has to store and look up session data on every single request. If you have multiple servers behind a load balancer, they all need access to the same session store. If you are building a mobile app or a third-party API integration, cookies are awkward to work with. As applications became more distributed, sessions became a bottleneck.

The idea behind JWT tokens is different: instead of storing your identity on the server and handing you a key to retrieve it, the server gives you the identity data directly — packaged in a way that cannot be tampered with.

What is a JWT

JWT stands for JSON Web Token. It is a compact, self-contained string that carries information about a user — or about the permissions granted to an application — in a format that any system can read and verify independently.

A JWT looks like this:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTYiLCJuYW1lIjoiSmFuZSBEb2UiLCJlbWFpbCI6ImphbmVAZXhhbXBsZS5jb20iLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MTcwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

It is not encrypted by default — it is just encoded. Which means you can decode it and read what is inside. The three parts separated by dots are the header, the payload, and the signature.

What a JWT actually contains

The header describes the token itself — specifically, which algorithm was used to sign it. This tells the receiver how to verify the signature.

The payload is where the actual information lives. It is a JSON object containing a set of claims — statements about the user or the context of the token. A typical payload looks like this:

{
  "sub": "123456",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "role": "admin",
  "exp": 1717000000
}

Each field is a claim. Some are standardized — sub is the subject (the user identifier), exp is the expiration timestamp. Others like role are custom claims that your application defines based on its own needs.

The signature is what makes the token trustworthy. It is generated by the authorization server using a private key, and it covers both the header and the payload. If anyone modifies even a single character of the token, the signature becomes invalid.

💡 Encoded, not encrypted

The payload of a standard JWT is Base64-encoded, which means anyone who has the token can read its contents. Never put sensitive information — passwords, credit card numbers, personal data — inside a JWT payload. The signature guarantees integrity, not confidentiality.

How the signature makes it trustworthy

When your authorization server issues a JWT, it signs it with a private key that only the server holds. When an API receives that token, it verifies the signature using the corresponding public key — which it can obtain from the authorization server's discovery endpoint.

If the signature is valid, the API knows two things: the token was genuinely issued by the authorization server, and its contents have not been modified since. No database lookup required — the token is self-contained and self-verifiable.

This is why JWT tokens work so well in distributed systems. Any service that has the public key can independently verify any token, without coordinating with a central session store.

Why your app needs this

JWT tokens solve several practical problems at once:

Stateless authentication — the server does not need to store session data. Every request is independently verifiable.
Scalability — any instance of your API can validate any token, with no shared state between servers.
Cross-domain access — tokens travel in HTTP headers, making them easy to use across different domains and services.
Rich context — a single token can carry roles, permissions, and user data, reducing the need for additional lookups.
Standard interoperability — JWT is an open standard. Any framework, in any language, knows how to handle them.

The flip side

JWT tokens are not without trade-offs, and understanding them is important before relying on them in production.

The most significant limitation is revocation. Because a JWT is self-contained and stateless, there is no built-in way to invalidate it before it expires. If a token is stolen, or a user's permissions change, the token remains valid until its exp timestamp is reached. This makes token lifetime a critical security parameter — access tokens should be short-lived, typically between 5 and 15 minutes.

There are approaches to handle revocation — reference tokens, token introspection, blocklists — but they all introduce some degree of server-side state, partially trading away the stateless advantage. The right choice depends on your application's security requirements.

⚠️ Short lifetimes are not optional

A JWT that is valid for 24 hours is a significant security risk. If it is intercepted, an attacker has a full day to use it. Keep access token lifetimes short, and use refresh tokens to maintain sessions without compromising security.

Managing JWT tokens without the complexity

Handling JWT tokens correctly — signing certificates, token lifetimes, revocation strategies, claims configuration — requires careful decisions at every step. I've been building IdentitySuite, a self-hosted OIDC/OAuth 2.0 identity server for ASP.NET Core built on OpenIddict, that handles all of this out of the box, with secure defaults and a full admin UI to manage every aspect of your token configuration without writing a line of code.

OpenIddict and IdentitySuite — secure configuration without the complexity

Stefano Pinato — Mon, 27 Jul 2026 18:13:50 +0000

Closing out the series — part 1 covered what OpenIddict is, part 2 covered what commonly goes wrong. This time: how I ended up solving each of those pitfalls in IdentitySuite, the identity server I've been building on top of OpenIddict.

Secure configuration without the complexity

In the previous article, we looked at the most common mistakes developers make when configuring OpenIddict from scratch — development certificates in production, token lifetimes left at defaults, missing PKCE enforcement, loose redirect URI validation, and no revocation strategy. Each one is a real vulnerability, not just a best practice to follow when convenient.

In this article, I'll go through how IdentitySuite addresses each of those points — and in most cases, that answer requires no code at all.

Certificates — persistent, managed, monitored

The pitfall: development certificates are ephemeral. Every restart invalidates all active tokens, and they are not suitable for production under any circumstances.

IdentitySuite handles certificate management as a first-class concern, with two distinct modes depending on your deployment requirements.

Built-in certificates are the default mode. IdentitySuite generates RSA 4096 self-signed certificates automatically and manages their entire lifecycle — creation, storage, and rotation — without any manual intervention. When a certificate approaches expiry, the system rotates it automatically and keeps the previous certificate available for long enough to cover all tokens that were issued with it. No expired token is invalidated prematurely.

While self-signed certificates are not the recommended choice for high-compliance environments, they are a legitimate option for production — RSA 4096 provides strong cryptographic guarantees, and the fully automated lifecycle removes the operational risk of forgetting a manual rotation.

Custom certificates allow you to load your own certificates — from the filesystem or from the certificate store on systems that support it. This is the recommended path when your security policy requires certificates issued by a trusted CA or managed through your organization's PKI. In this mode, rotation is manual: you upload the new certificate when needed, and IdentitySuite handles the transition, keeping the previous certificate active until all tokens signed with it have expired.

In both modes, the Dashboard displays the expiry status of signing and encryption certificates in real time, with visual warnings when rotation is approaching. No scripts to write, no external monitoring to set up — the system surfaces the information where it is needed.

💡 What this means in practice

Certificates survive application restarts and are consistent across all instances of your deployment. In a load-balanced environment, every node uses the same certificate — tokens issued by one instance are valid on all others. And regardless of the rotation mode, no active token is ever invalidated early due to a certificate change.

Token lifetimes — explicit, configurable, visible

The pitfall: leaving token lifetimes at framework defaults means access tokens that are valid far longer than necessary, with no easy way to adjust them without touching code.

In IdentitySuite, every token lifetime is configurable from the admin UI. Access tokens, refresh tokens, authorization codes, identity tokens, device codes — each has its own field, with the current value always visible.

The defaults IdentitySuite ships with are deliberately conservative — short access token lifetimes, reasonable refresh token windows. You can adjust them at any time without a redeployment. Since token lifetimes are read at startup, changes take effect after the next process recycle — which in most hosting environments means a few seconds.

PKCE — enforced at the server level

The pitfall: OpenIddict supports PKCE but does not enforce it by default. A single missing method call leaves public clients vulnerable to authorization code interception.

IdentitySuite enforces PKCE at the server level for all authorization code flows by default — the configuration is applied globally and consistently, regardless of how individual clients are registered. For most deployments, this is the right choice and requires no additional setup.

If your scenario requires more flexibility — for example, when integrating legacy clients that do not support PKCE — the enforcement can be disabled through a configuration option. The default, however, is always the secure one: PKCE on, protection active from the first request.

The same requirement is visible and verifiable at the individual client level, so you always know exactly what security constraints apply to each registered application — without having to cross-reference multiple configuration files.

Redirect URIs — exact matching, no exceptions

The pitfall: registering redirect URIs that are too broad, or accepting wildcards and pattern matching, creates open redirect vulnerabilities that can be exploited to capture authorization codes.

In IdentitySuite, redirect URIs are registered per client through the admin interface. The validation model enforces exact URI matching — what you register is exactly what will be accepted, nothing more. There are no wildcards, no path prefixes, no pattern matching.

Adding or removing redirect URIs requires no code changes and no redeployment. Client configurations are stored in the database and take effect immediately, which is particularly useful during onboarding of new client applications.

Scopes and audiences — consistent by design

The pitfall: in a raw OpenIddict setup, scopes and audiences must be configured consistently across three separate places — the server registration, the API resource definitions, and each client registration. A mismatch at any point produces tokens that either fail validation or grant access they should not.

IdentitySuite structures this as a clear hierarchy. At the server level, you define which scopes are globally available. Each API scope is then associated with one or more API resources — the actual services that will validate tokens. Finally, each client declares exactly which identity scopes and API scopes it is allowed to request.

Because every level references the one above it, the configuration is always coherent end-to-end. There is no way to assign a scope to a client that has not been defined at the server level, and no way for a token to reach an API resource it was not intended for.

💡 Why this matters

Scope and audience misconfiguration is one of the most common sources of frustration when setting up an authorization server from scratch. IdentitySuite resolves it structurally — the hierarchy enforces consistency, so there is no configuration to get wrong.

Token revocation — available when you need it most

The pitfall: skipping token revocation means that in the event of a security incident, compromised tokens remain valid until they naturally expire — with no way to stop them.

IdentitySuite includes a token revocation system built directly into the Dashboard. A single action revokes all active tokens across all clients — useful in emergency scenarios such as a suspected credential leak or a Data Protection key rotation.

Per-client revocation is also available, allowing you to terminate all sessions for a specific application without affecting others. Both actions are audited, so there is always a record of when revocation happened and who triggered it.

⚠️ Emergency revocation

When you revoke all tokens alongside a Data Protection key rotation, IdentitySuite handles the post-revocation session cleanup automatically — including the antiforgery cookie invalidation that would otherwise leave the admin UI in a broken state.

What you actually write

To put this in perspective: getting OpenIddict to a production-ready state from scratch requires writing and maintaining a significant amount of security-critical configuration code. Certificates, lifetimes, PKCE enforcement, redirect URI validation, scope definitions, revocation endpoints — each one is a decision point where a mistake has consequences.

With IdentitySuite, your Program.cs looks like this:

var builder = WebApplication.CreateBuilder(args);
builder.AddIdentitySuiteServices();

var app = builder.Build();
await app.SetupIdentitySuiteDbAsync();
app.UseIdentitySuiteServices();
app.Run();

Everything covered in this series — certificates, token lifetimes, PKCE, redirect URIs, scopes, audiences, revocation — is handled internally by those three method calls. The design philosophy is deliberate: ship with secure, production-ready defaults so you can get a working, secure environment up and running immediately, without writing a single line of security-critical code.

At the same time, the system remains highly configurable. All the settings discussed in this article are manageable through the admin UI at runtime — no code changes, no configuration file edits required. For teams that need deeper customization, a full set of options is available to tailor every aspect of the system to their specific requirements.

Wrapping up the series

Over three articles, we've covered what OpenIddict is, where its configuration complexity lies, and how IdentitySuite addresses each of those points in a structured and auditable way.

If you're building a .NET application that needs OAuth 2.0 or OpenID Connect, and you want the reliability of OpenIddict without the configuration surface, IdentitySuite is worth a look. It's free to run forever for small deployments (1 client / 100 users), with paid plans for larger setups.

Happy to answer questions about any of the decisions covered in this series, OpenIddict in general, or IdentitySuite specifically.

The pitfalls of configuring OpenIddict from scratch — what can go wrong

Stefano Pinato — Wed, 22 Jul 2026 21:21:09 +0000

Part 2 of the series — in part 1 we covered what OpenIddict is. This time: what goes wrong when configuring it, and why.

What can go wrong — and why it matters more than you think

In the previous article, we established what OpenIddict is and why it has become the go-to choice for .NET developers who need a standards-compliant authorization server. The framework is solid, well-maintained, and flexible.

That flexibility, however, comes at a cost. OpenIddict does not make decisions for you — it gives you the tools and expects you to use them correctly. And in the security domain, incorrect configuration is not just a bug: it is a vulnerability.

This article covers the most common mistakes developers make when setting up OpenIddict from scratch, and what the actual consequences are when those mistakes reach production.

Using development certificates in production

OpenIddict makes it very easy to get started locally. Two method calls and you have working signing and encryption certificates:

options.AddDevelopmentEncryptionCertificate()
       .AddDevelopmentSigningCertificate();

These methods generate ephemeral certificates that live only in memory. Every time the application restarts, new certificates are generated — which means every token signed before the restart becomes invalid immediately. Users get logged out, API calls start failing, and refresh tokens stop working.

More critically, development certificates are not suitable for production from a security standpoint. They offer no guarantee of key strength, no rotation policy, and no audit trail. They exist purely to reduce friction during development.

⚠️ Real-world consequence

Development certificates in production means every application restart invalidates all active sessions. In a load-balanced environment with multiple instances, tokens signed by one instance cannot be validated by another. The result is constant, unpredictable authentication failures.

The correct approach is to provide persistent certificates — loaded from the filesystem or the Windows certificate store — that survive restarts and are shared across all instances of your application. This requires understanding certificate formats, key storage, and rotation strategies before you write a single line of configuration.

Token lifetimes that are too long — or not set at all

OpenIddict allows you to configure the lifetime of every token type: access tokens, refresh tokens, authorization codes, identity tokens. If you do not set these explicitly, the defaults apply — and while the defaults are reasonable, they may not be appropriate for your threat model.

The problem developers run into most often is access tokens with lifetimes that are far too long. An access token that is valid for 24 hours gives an attacker a 24-hour window to use a stolen token without any way to invalidate it, unless you have also set up token introspection or reference tokens.

// Setting explicit lifetimes is not optional in production
options.SetAccessTokenLifetime(TimeSpan.FromMinutes(15))
       .SetRefreshTokenLifetime(TimeSpan.FromDays(14))
       .SetAuthorizationCodeLifetime(TimeSpan.FromMinutes(5));

Short access token lifetimes force clients to refresh frequently, which gives you more opportunities to detect and revoke compromised sessions. Authorization codes should be especially short-lived — they are single-use credentials that should expire in seconds, not minutes.

💡 The balance to find

Very short lifetimes improve security but increase the frequency of token refresh operations, which adds load to your server and latency for your users. There is no universal answer — the right values depend on your application's sensitivity and usage patterns.

Not enforcing PKCE for public clients

PKCE (Proof Key for Code Exchange) is a mechanism that prevents authorization code interception attacks. It is mandatory for public clients — browser-based applications and mobile apps that cannot securely store a client secret.

OpenIddict supports PKCE, but it does not enforce it by default for every client. If you register a public client without requiring PKCE, that client can complete an authorization code flow without it. An attacker who intercepts the authorization code — through a malicious redirect, a browser extension, or a misconfigured redirect URI — can exchange it for tokens directly.

// This enables PKCE support but does not enforce it
options.AllowAuthorizationCodeFlow();

// This makes PKCE mandatory for all authorization code requests
options.AllowAuthorizationCodeFlow()
       .RequireProofKeyForCodeExchange();

The difference between these two lines is small in code but significant in practice. Per-client enforcement requires additional configuration at the client registration level, which adds another surface for misconfiguration if not handled carefully.

Loose redirect URI validation

Redirect URIs are one of the most critical security boundaries in OAuth 2.0. After a user authenticates, the authorization server sends the authorization code to the redirect URI registered for that client. If an attacker can influence where that code is sent, they can capture it.

OpenIddict performs redirect URI validation, but the quality of that validation depends entirely on how you register your clients. Common mistakes include registering URIs that are too broad, allowing trailing wildcards, or accepting localhost URIs in production configurations.

⚠️ What a misconfigured redirect URI looks like

Registering https://app.example.com/ as a redirect URI and then accepting any path under that origin is an open redirect vulnerability. An attacker crafts a link that redirects the authorization code to a path they control under your domain. The fix is always exact URI matching — no wildcards, no pattern matching, no exceptions.

Scope and audience misconfiguration

Scopes and audiences define what a token is valid for. A token issued with the wrong audience will be accepted by resource servers it was never intended to reach. A token with overly broad scopes gives the bearer more access than they should have.

Getting this right requires understanding the relationship between client registrations, scope definitions, and resource server validation — three separate concepts that need to be configured consistently. A mismatch at any point in the chain produces tokens that either do not work at all or work in ways you did not intend.

Skipping token revocation

By default, JWT access tokens are self-contained and stateless. Once issued, they are valid until they expire — there is no built-in mechanism to invalidate them early. This is fine for short-lived tokens, but becomes a problem when you need to respond to a security incident, a user logs out, or an account is compromised.

OpenIddict supports reference tokens, which store the actual token payload in the database and issue only an opaque handle to the client. This makes revocation straightforward — you delete the record and the token stops working immediately. But reference tokens require token introspection at every API call, which adds a database lookup to each request.

Choosing between JWT and reference tokens — and setting up revocation correctly for either — is a decision that has to be made deliberately, based on your application's requirements. Skipping it because it seems complex is a common shortcut with real consequences.

The underlying pattern

Looking at these pitfalls together, a pattern emerges: none of them are caused by bugs in OpenIddict. They are all the result of decisions — or the absence of decisions — during configuration. OpenIddict is a general-purpose framework, and general-purpose frameworks cannot make security decisions on your behalf.

This is not a criticism of the library. It is simply the nature of building something flexible enough to serve a wide range of use cases. The trade-off is that every team using OpenIddict needs to develop enough expertise to configure it correctly — or rely on something that has already made those decisions in a secure and consistent way.

Introducing IdentitySuite 3.0

Stefano Pinato — Tue, 14 Jul 2026 09:43:00 +0000

I've been writing a short series on OpenIddict basics while preparing this release — IdentitySuite 3.0 is our biggest visual and customization update yet.

What's New in IdentitySuite 3.0

IdentitySuite 3.0 is our most visually ambitious release yet. We've reimagined how developers and designers customize authentication and account management pages, introducing a modern Theme Builder with new templates, gradient support, image backgrounds, and a centralized image library shared across each client.

🚀 Highlight

New Theme Builder with 4 templates

Gradient and image backgrounds

Centralized Image Library per client

New social login providers: GitHub, Apple, LinkedIn, Instagram

Live preview with desktop/mobile emulation

Automatic section highlighting while editing

1. A Completely Redesigned Theme Builder

The new Theme Builder introduces a more intuitive and powerful way to customize every visual aspect of your authentication and account management pages. With four new templates and dozens of configurable properties, IdentitySuite 3.0 gives you full control over layout, spacing, typography, backgrounds, and branding.

Four New Layout Templates

Centered Form — Classic layout with the form centered and the logo above.
Form Left — Form on the right, brand panel on the left.
Form Right — Form on the left, brand panel on the right.
Centered Layout — Logo and title above the form, subtitle below.

Each template unlocks different customization options inside the Theme Builder, such as Page Container, Brand Panel, Card Header, and Card Body.

Gradient & Image Backgrounds

Version 3.0 introduces full support for gradient backgrounds and image backgrounds across multiple sections, including Page, Page Container, Brand Panel, and Card Body. This allows you to create visually rich and modern layouts with minimal effort.

Live Preview with Automatic Highlighting

The preview area now includes desktop and mobile emulation, and automatically highlights the section you are editing with a red outline. This makes it easier to understand exactly which part of the page is being modified.

💡 Pro Tip — Default Values

The Default Values accordion allows you to define global parameters such as background, color, border-radius, border-width, and typography. When you click Apply, these values are automatically propagated to all compatible elements, instantly updating the entire theme preview. You can then refine individual components using their specific settings for precise visual control.

2. New Social Login Providers

IdentitySuite 3.0 expands its authentication capabilities with four new social login providers: GitHub, Apple, LinkedIn, and Instagram. Combined with the existing Google, Facebook, and Microsoft providers, this update offers more flexibility and a smoother onboarding experience for end users.

3. Centralized Image Library

Each client now includes a centralized Image Library used for logos, background images, and brand assets. Images can be uploaded, reused, or removed directly from the Appearance panel or the Email Builder, ensuring consistent branding across all pages and email templates.

The Theme Builder integrates seamlessly with the Image Library, allowing you to select logos and background images while customizing the Brand Panel or Page Container.

For a complete overview of the new Theme Builder, including templates, layout controls, gradient backgrounds, and image management, check out the Theme Builder documentation, and browse real examples in the new IdentitySuite UI Gallery.

4. Improved Branding Controls

Brand Title, Brand Subtitle, and Logo Source have been enhanced with new typography, spacing, alignment, and shadow options. Logo rendering now supports object-fit, position, margin, and custom sizing, giving you complete control over brand presentation.

5. Enhanced Account Management Customization

Account pages now support deeper customization through dedicated sections for Page, Card, Card Header, Card Body, Nav Menu, and Nav Button. Backgrounds, spacing, typography, and hover/selected states can be configured independently for a polished and consistent user experience.

Upgrading from 2.x

Upgrading to 3.0 is straightforward: update your NuGet packages (IdentitySuite and IdentitySuite.EntityFrameworkCore) to version 3.0.0, enable Apply migrations in your Database settings, and start your application — the required migrations are applied automatically on startup, no manual database work needed.

Existing client themes remain fully compatible with the new theming system, so no action is required after upgrading. If you'd like to adopt the new Theme Builder defaults on an existing client, you can reset the theme at any time from Configuration → Theme Editor.

If your project overrides IdentitySuite's controller endpoint delegates, note that their signatures have changed in 3.0 — see the migration guide for details.

Ready to Explore IdentitySuite 3.0?

The fastest way to get started is through our example projects repository — ready-to-run sample applications and pre-built client configurations for several common scenarios, so you can have a working setup without writing configuration from scratch:

https://github.com/spin973/IdentitySuite

IdentitySuite's core identity server — OIDC/OAuth 2.0 flows, user and client management, full configuration — is free with no time limit for deployments up to 1 client and 100 users. Premium features like the Theme Builder shown in this article, along with the Dashboard and Email Template Builder, are available as a full 30-day preview on the Free plan, so you can try them before deciding whether to upgrade. Paid plans start at €349/year, with a 14-day no-questions-asked refund.

Full documentation: identitysuite.net/documentation

What is OpenIddict: the .NET framework developers choose for OAuth 2.0 and OpenID Connect

Stefano Pinato — Fri, 10 Jul 2026 06:35:09 +0000

I've been writing a short series on OpenIddict basics while preparing IdentitySuite's v3.0 release — here's part 1.

The .NET framework developers choose for OAuth 2.0 and OpenID Connect

At some point in every .NET developer's journey, the same question comes up: how do I handle authentication properly? Not just a login form — but token issuance, authorization flows, secure API access, and all the moving parts that modern applications require.

If you have been researching this topic, you have probably come across OpenIddict. This article explains what it is, what it actually does, and why so many developers in the .NET ecosystem rely on it.

What is OpenIddict?

OpenIddict is an open-source framework for ASP.NET Core that allows you to add a fully compliant OAuth 2.0 and OpenID Connect authorization server to your application. In plain terms: it is the component responsible for issuing and validating the tokens that your applications and APIs use to authenticate users and authorize requests.

It is not a hosted service, a SaaS product, or a cloud platform. It is a library you add to your .NET project, giving you complete control over where it runs and how it is configured.

OpenIddict is maintained by Kévin Chalet and has been actively developed for years. It is certified by the OpenID Foundation, which means it has passed formal conformance tests against the OpenID Connect specification — not a minor detail when security is involved.

💡 OpenID Foundation Certification

Certification means that OpenIddict's implementation has been independently verified to comply with the OpenID Connect specification. For developers, this translates to one less thing to worry about: the protocol behavior is correct by design.

How it fits into the .NET ecosystem

One of the reasons OpenIddict is popular in the .NET world is that it does not try to replace what already exists — it complements it.

OpenIddict integrates naturally with ASP.NET Core Identity, Microsoft's user management system. Identity handles the user store: creating accounts, hashing passwords, managing roles and claims. OpenIddict sits on top of it and handles the protocol layer: deciding when to issue a token, what claims to include, and how to respond to authorization requests.

For persistence, OpenIddict uses Entity Framework Core, which means it works with the same database you are probably already using — SQL Server, PostgreSQL, or MySQL. Applications, tokens, and authorizations are stored as regular EF Core entities, queryable and manageable like any other data in your system.

This tight integration with the existing .NET stack is intentional. Rather than introducing new abstractions and paradigms, OpenIddict speaks the same language as the rest of your application.

What OpenIddict actually handles

To understand what OpenIddict does, it helps to look at what an authorization server is responsible for. When a user logs into your application, or when one service needs to call another securely, a series of standardized exchanges takes place. OpenIddict implements all of them.

Concretely, it exposes and manages the following:

Authorization endpoint — where users are redirected to authenticate and consent
Token endpoint — where authorization codes or credentials are exchanged for tokens
UserInfo endpoint — where applications retrieve profile information about the authenticated user
Introspection endpoint — where resource servers validate tokens without parsing them directly
Revocation endpoint — where tokens can be explicitly invalidated
Discovery endpoint — the /.well-known/openid-configuration document that client applications use to configure themselves automatically

It also supports all the major OAuth 2.0 grant types: Authorization Code (with and without PKCE), Client Credentials, Refresh Token, and Device Authorization.

To give you a concrete sense of what this looks like in code, here is a minimal example of how OpenIddict is registered in an ASP.NET Core application:

services.AddOpenIddict()
    .AddCore(options =>
    {
        options.UseEntityFrameworkCore()
               .UseDbContext<ApplicationDbContext>();
    })
    .AddServer(options =>
    {
        options.SetAuthorizationEndpointUris("/connect/authorize")
               .SetTokenEndpointUris("/connect/token")
               .SetUserinfoEndpointUris("/connect/userinfo");

        options.AllowAuthorizationCodeFlow()
               .AllowRefreshTokenFlow()
               .RequireProofKeyForCodeExchange();

        options.AddDevelopmentEncryptionCertificate()
               .AddDevelopmentSigningCertificate();

        options.UseAspNetCore()
               .EnableAuthorizationEndpointPassthrough()
               .EnableTokenEndpointPassthrough();
    })
    .AddValidation(options =>
    {
        options.UseLocalServer();
        options.UseAspNetCore();
    });

This is a working starting point — but it is also just the beginning. A production-ready configuration requires handling certificates properly, configuring token lifetimes, securing endpoints, registering client applications, and more. The flexibility of OpenIddict means all of this is possible, but it also means the responsibility falls on the developer to get it right.

⚠️ Flexibility comes with responsibility

OpenIddict gives you all the building blocks. How you assemble them — and whether the result is secure and standards-compliant — depends on the decisions you make during configuration. This is not a criticism of the library; it is simply the nature of a general-purpose framework.

Why developers choose it

Several factors explain why OpenIddict has established itself as a reference choice in the .NET space:

Open source with a permissive license. OpenIddict is released under the Apache 2.0 license, which means you can use it freely in commercial projects without licensing fees or usage restrictions.

Active and transparent development. The project is actively maintained, with a public roadmap, regular releases, and a responsive issue tracker. When a security vulnerability is discovered or a new specification is published, updates follow.

Standards compliance, verified. As mentioned, OpenIddict holds official OpenID Connect certification. This is not self-declared — it is the result of passing a formal test suite administered by the OpenID Foundation.

No external dependencies beyond the .NET stack. Unlike some alternatives that require specific infrastructure or cloud services, OpenIddict runs wherever .NET runs. On-premises, in Docker, on Azure, on a Raspberry Pi — the deployment model is entirely yours to decide.

A strong and growing community. Stack Overflow, GitHub Discussions, and various .NET communities have built up a solid body of knowledge around OpenIddict. Finding answers to common configuration questions is increasingly straightforward.

Wrapping up

OpenIddict is a mature, certified, and well-maintained framework that brings OAuth 2.0 and OpenID Connect to the .NET ecosystem without forcing you outside the tools you already know. It handles the protocol complexity so you can focus on your application — provided you configure it correctly.

And that last part — configuring it correctly — is where things get interesting. In the next article in this series, we will look at the most common mistakes developers make when setting up OpenIddict from scratch, and why getting those details wrong can have real security consequences.