Authlete vs. Duende IdentityServer
Authlete is a hosted OAuth/OIDC protocol engine: you build the authorization-server endpoints and it handles protocol logic and token storage as a REST API, with strong financial-grade (FAPI) certifications and token-based pricing. Duende IdentityServer runs the whole identity server in-process in your own ASP.NET Core host, with no per-request external dependency, tokens stored in your infrastructure, and licensing tiers based on functionality and client IDs. Choose Authlete for protocol-logic-as-a-service in polyglot or heavily regulated environments. Choose Duende IdentityServer to keep the whole token server inside your .NET system.
Authlete occupies a distinctive position in the identity landscape: it is a hosted protocol engine. You build and host the authorization-server endpoints yourself, in your own infrastructure and language of choice, and those endpoints call Authlete's REST API, which handles the OAuth/OIDC protocol logic and token lifecycle. User authentication and user data stay entirely on your side; Authlete never sees credentials. It is best known for financial-grade identity: FAPI 1.0 and 2.0 certified, with deep support for open-banking profiles worldwide.
Duende IdentityServer puts the boundary elsewhere: everything runs in-process, in a dedicated ASP.NET Core identity host that is separate from the applications and APIs it secures. Protocol logic, token issuance, and token storage all live in your own infrastructure, with no per-request dependency on an external service.
The two share more than the architecture diagram suggests. In both models you own the host, the endpoints' address, and the entire user-authentication layer. The difference is where the protocol logic runs.
This comparison was made on August 24, 2026, against Authlete 3.0. Both products are actively developed and their functionality changes regularly, so the comparison may not be fully accurate at the time of reading.
How Do Authlete and Duende IdentityServer Compare?
| Capability / Specification | Authlete | Duende IdentityServer |
|---|---|---|
| Operating model | Hosted protocol engine: your endpoints call Authlete's REST API | Fully in-process in your ASP.NET Core identity host |
| Deployment options | Shared cloud, dedicated cloud, or self-managed backend | Self-hosted in your infrastructure, any cloud or on-premises |
| Runtime dependency | Per-request calls to the Authlete API (or your self-managed Authlete deployment) | None; protocol logic runs in your process |
| Token storage | In Authlete's database | In your own operational store |
| User authentication / user data | Always yours; Authlete stores no users by design | Always yours; ASP.NET Identity or User Management |
| Language / SDKs | Polyglot: Java, .NET, TypeScript, Go, Ruby, PHP SDKs for building your endpoints | .NET / ASP.NET Core |
| FAPI (financial-grade) | FAPI 1.0 and 2.0 certified; UK/Brazil/Australia/KSA open-banking profiles | FAPI 2.0 certified at the product level and supports the building blocks (PAR, JAR, mTLS, DPoP, CIBA). Because conformance depends on configuration, each production deployment certifies separately. See the OpenID certification listings |
| CIBA | Certified (FAPI-CIBA) | Native support (included in Standard and Advanced) |
| PAR / DPoP / mTLS | Supported | Native support |
| Dynamic Client Registration (RFC 7591) | Supported | Native support (included in Standard and Advanced) |
| Verifiable Credentials (OID4VCI) | Supported (3.0) | Not currently a product feature |
| SAML 2.0 | Not offered (OAuth/OIDC only) | SAML 2.0 add-on (included in Advanced; add-on for Standard) |
| MFA / passwordless | Out of scope by design; your authentication layer | User Management (passkeys, TOTP, OTP) |
| Configuration management | Management console, APIs, Terraform provider | Code and/or EF configuration stores |
| OpenTelemetry observability | Your endpoints are yours to instrument; the Authlete backend is a service | Native support end to end (metrics, traces, and logs) |
| Pricing model | Subscription based on Monthly Active Tokens | Licensing tiers based on functionality and client IDs; commercial license (free for dev/test; Community Edition for qualifying organizations) |
While the feature matrix outlines the protocol differences, the next table provides a clearer picture of how Authlete's service-oriented logic maps to Duende's in-process model.
How Do Authlete Concepts Map to Duende IdentityServer?
| Authlete | Duende IdentityServer | Notes |
|---|---|---|
| Service | Your issuer / identity host configuration | One Authlete Service corresponds to one Duende issuer |
| Client | Direct mapping; config exportable via Authlete's APIs | |
| Scopes (service configuration) | Duende splits API scopes from identity resources | |
| Your endpoint implementations calling Authlete APIs | Duende's built-in protocol endpoints | The endpoint plumbing you wrote becomes framework-provided |
| Ticket (two-step authorization API) | Handled internally by the endpoint pipeline | No equivalent needed |
| Service / organization access tokens (API credentials) | Not needed | No external API to authenticate against |
| Token database (at Authlete) | Your operational store ( | Tokens move into your infrastructure |
| Your user-authentication layer | Unchanged, plus | The part you already own carries straight over |
| Management console / Terraform provider | Code, EF stores, Configuration API (DCR) | Config-as-code either way |
When Is Authlete the Right Fit for You?
Authlete fits when you operate in regulated, financial-grade environments and want the protocol internals externalized and maintained by specialists, with certifications for the exact open-banking profile your regulator requires. It is a good choice when your organization is polyglot, because the endpoint layer can be Java, Go, or TypeScript just as easily as .NET.
Duende IdentityServer fits when your development team is more .NET focused and you want the whole token server (protocol logic, token issuance, and token storage) running in-process in your own infrastructure. There is no per-request dependency on an external API, token data never leaves your systems, and licensing tiers based on functionality and client IDs rather than scaling with monthly active tokens. The financial-grade building blocks (PAR, JAR, mTLS, DPoP, CIBA) are native.
How Do You Migrate to Duende IdentityServer?
A migration from Authlete has an unusual head start: there is no user migration at all, because your users were never in Authlete, and your login UI and authentication layer carry over unchanged. The work is in the plumbing:
- Export service and client configuration via Authlete's management APIs (or your Terraform state) and map it to Duende clients and resources.
- Rotate client secrets as part of the move.
- Replace your endpoint implementations (the code calling Authlete's APIs) with Duende's built-in endpoints, and wire your existing authentication layer into the identity host.
- Let live tokens expire. Authlete-issued tokens don't migrate; clients re-authenticate against the new issuer.
See the migration approaches post for the general patterns.