Drag your IdentityServer deployments, apps, APIs and identity providers onto the canvas to draw your identity and access management (IAM) architecture, and see which Duende plan and add-ons match it.
Step 1 of 5
How many of each do you have? Zero is fine.
Websites and server apps
Server-rendered sites, back-office portals and other apps with a backend.
Single page apps
Browser apps that run in JavaScript, such as React, Angular or Blazor WebAssembly.
How many SPAs use the BFF?
Mobile and desktop apps
Apps installed on a phone, tablet or computer.
Services and machines
Background jobs, workers and devices that sign in without a user.
APIs your apps call
APIs that only validate tokens don't count toward your license.
How many of them?
Third-party API consumers
Apps from partners or other companies that call your APIs.
SAML Service Providers
Apps that sign users in with SAML 2.0.
MCP clients
AI agents and tools that connect through the Model Context Protocol.
Production deployments
How many production IdentityServer deployments you run, even if you list fewer URLs.
External identity providers
For example Microsoft Entra ID, Okta or Google.
How many tenants?
This is what we will draw. You can change anything afterward.
Drag the background to pan. Over the canvas, the mouse wheel zooms and Shift + wheel pans sideways. On a trackpad, two fingers pan and pinch zooms. The page scrolls as usual elsewhere.
Editing works best on a larger screen.
Summary of what counts for licensing. Switch to Architecture to edit.
The plan that matches the components on your canvas.
Talk to an Expert
This diagram and plan suggestion are a non-binding estimate. Your actual licensing is confirmed by Duende, based on your Order and the license agreement. See the license agreement. The planner doesn't calculate prices; see the pricing page. Plan data from duendesoftware.com/pricing, built . Bundled rules 2026-10-15.
An identity and access management (IAM) architecture shows who signs in, to what, and which system decides. In a Duende setup that system is IdentityServer, the identity provider at the center of the diagram.
Four kinds of parts sit around it:
A BFF keeps tokens on the server, so browser code never handles them. The single-page app behind it counts as a BFF frontend, and the BFF host is the part that registers with IdentityServer.
Single sign-on (SSO) happens at IdentityServer. A user signs in once, and each Connected App that trusts it can reuse that session. One SSO architecture can serve many apps without a separate login for each.
The protocols have separate jobs. OpenID Connect handles sign-in and tells an app who the user is. OAuth 2.0 handles API access and lets an app call an API with an access token. SAML 2.0 connects enterprise service providers and upstream SAML identity providers that expect it.
An IAM architecture diagram makes these links visible. In this planner the same diagram also drives the estimate above: Connected Apps, BFF frontends and production deployments are counted from what you draw.
To draw one, start with IdentityServer, then add the apps that sign in and the APIs they call. Add upstream identity providers last. They change how users arrive, and the apps still receive tokens from IdentityServer.
Draw yours above, or start from a template: SPA + BFF, Federation hub or Multi-tenant SaaS.
A Connected Application (Connected App) is any application or service registered with your Duende IdentityServer instance that relies on it for identity, access, or federation. Connected Apps are the unit we use to measure usage for licensing. Each Connected App has its own registration that defines how it interacts with IdentityServer and what it is allowed to do.
Connected Apps fall into these categories:
Each separate registration counts as a separate Connected App, including when the same application is registered under more than one protocol.
Each separate registration or configuration in IdentityServer counts as one Connected App. Some common examples:
A deployment is a single authority that supports OpenID Connect, OAuth, or SAML, hosted at a single URL. It may span multiple physical or virtual nodes to support load balancing and failover, while still counting as one deployment for licensing purposes.
Self-hosted means you are running Duende IdentityServer on your own infrastructure - whether that's your own data center or a cloud subscription you own. Standard licenses cover this model but do not permit redistribution to infrastructure owned by your business customers.
Redistribution is a separate license type designed for customers who want to bundle Duende IdentityServer as part of a product that they distribute to customers. Note that a redistribution license is tied to a specific product and cannot be used as a general-purpose identity provider for applications outside of that product.
If you plan to ship Duende IdentityServer as part of a product to your customers, you will need a redistribution license. Self-hosted and redistribution licenses are priced separately. See the self-hosted pricing and redistribution pricing pages.
The planner applies the published plan limits to the architecture you describe and assumes the latest IdentityServer. It can't see your Order or negotiated terms, and it never calculates prices. Your Order and the license agreement decide what is licensed.
More answers are in the full FAQ.
Decode SAML requests and responses (POST or Redirect binding) and inspect assertions, conditions and signatures.
Fetch and explore an OpenID Connect discovery document and its endpoints.
The OpenID Connect and OAuth 2.0 framework for ASP.NET Core, from the team that built this tool.
