Amazon Cognito vs. Duende IdentityServer
Amazon Cognito is AWS's managed identity service. Duende IdentityServer is an identity server you run in your own ASP.NET Core host. Cognito gives you user pools, a hosted login, and deep AWS integration with no infrastructure to manage, priced per monthly active user. Duende gives you full ownership of the token server, the login experience, and the data, with licensing based on functionality and client IDs. Choose Cognito when you want AWS to handle identity for you. Choose Duende when you want identity to be part of your own system.
Amazon Cognito has two main building blocks. User pools are OIDC-compliant identity providers that store users, issue JWTs, and handle authentication (including MFA and social login). Identity pools are a separate service that exchanges IdP tokens for temporary AWS credentials via STS, which is how you grant authenticated users access to AWS resources like S3 or DynamoDB. Most teams start with user pools; identity pools come in when you need fine-grained AWS resource access.
Duende IdentityServer is a standards-based identity server that runs in a dedicated ASP.NET Core host, separate from the applications it secures. It supports OpenID Connect, OAuth, and SAML, and includes a first-party user management layer with passkeys, TOTP, OTP, and recovery codes. You own the code, the data, and the user experience. Nothing runs outside your infrastructure.
Neither approach is universally better. They optimize for different things.
This comparison was made on August 24, 2026. 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 Amazon Cognito and Duende IdentityServer Compare?
| Capability / Specification | Amazon Cognito | Duende IdentityServer |
|---|---|---|
| Operating model | Fully managed SaaS (AWS) | Self-hosted in an ASP.NET Core identity host you own |
| Login UI | Managed Login (hosted, configurable) | You build the UI (full control) in your identity host |
| Extensibility | Lambda triggers (JavaScript/Python/etc.) | |
| User store | Cognito user pool (managed directory) | Your database (for example ASP.NET Identity) or Duende User Management |
| MFA / passwordless | TOTP, SMS/email OTP, passkeys (WebAuthn) | User Management (passkeys, TOTP, OTP, recovery codes) |
| Social / enterprise connections | Built-in social (Google, Apple, Facebook, Amazon) + SAML/OIDC federation | |
| SAML 2.0 | Inbound federation only (as IdP to SPs: limited) | SAML 2.0 add-on (included in Advanced; add-on for Standard) |
| CIBA | Not supported | Native support (included in Standard and Advanced) |
| FAPI (financial-grade) | Not supported | FAPI 2.0 certified; PAR, DPoP, mTLS native |
| Sender-constrained tokens (DPoP / mTLS) | Not supported | Native DPoP and mTLS support |
| Server-side sessions | Platform-managed sessions | Native support (included in Standard and Advanced) |
| OpenTelemetry observability | CloudWatch metrics and logs | Native support (metrics, traces, and logs) |
| Signing key management | Managed by the platform | Automated, rolling zero-downtime key rotation (Standard and Advanced) |
| AWS integration | Deep (IAM, STS, API Gateway, Bedrock) | Cloud-agnostic; integrates via standard protocols |
| Data residency | AWS region(s) you choose | Wherever you deploy |
| Pricing model | Per monthly active user (tiered; free tier: 50K MAU) | Licensing tiers based on functionality and client IDs; commercial license (free for dev/test; Community Edition for qualifying organizations) |
| Token issuer | | Your issuer, in your infrastructure |
While the matrix compares product capabilities, the table below bridges the terminology gap by mapping familiar Cognito concepts to their Duende IdentityServer equivalents.
How Do Amazon Cognito Concepts Map to Duende IdentityServer?
If you know Cognito, most concepts have a direct home in Duende IdentityServer.
Cognito's architecture separates the protocol engine (exposed as an API) from the login UI. The managed login can be styled with CSS but not structurally customized, so teams that need anything beyond basic branding (multi-step flows, conditional UI logic, or a fully branded experience) end up building their own UI against Cognito's authentication API. In that sense the model resembles Duende IdentityServer, where you also build the interactive pages yourself. The difference is starting point: Duende ships UI templates and quickstarts you can adapt, whereas Cognito provides only the API surface.
| Amazon Cognito | Duende IdentityServer | Notes |
|---|---|---|
| User pool | Your issuer / identity host | One user pool corresponds to one Duende issuer you deploy and own |
| App client | Client with the matching grant types | App client settings map to grant types and scopes |
| Resource server + scopes | The resource server you protect in Cognito corresponds to an API resource | |
| Groups / custom attributes | Claims emitted via | Group membership and attributes become claims. Defaults ship for ASP.NET Identity and User Management; write a custom one only when you need to shape claims beyond what they emit |
| Lambda triggers (pre token generation) | | Lambda extensibility becomes C# extensibility. Defaults ship for ASP.NET Identity and User Management; write a custom one only when you need to shape claims beyond what they emit |
| Lambda triggers (pre/post auth) | Middleware, event handlers, custom validators (C#) | Same idea, different mechanism |
| Identity pool (federated identities) | Out of scope (AWS credential brokering, not token issuance) | Identity pools are an AWS-specific concept for STS credentials |
| Social / SAML / OIDC federation | External providers + your user store / ASP.NET Identity | Social and enterprise become external providers |
| Managed Login (hosted UI) | Your own login pages in the identity host | You own the UI and branding |
| MFA (TOTP, SMS, passkeys) | Passkeys, TOTP, OTP, recovery codes | |
| Endpoints (/oauth2/authorize, /oauth2/token) | | Standard OpenID Connect and OAuth endpoints |
When Is Amazon Cognito the Right Fit for You?
Cognito fits when you are already building on AWS and want identity as a managed service: no servers to run, deep integration with IAM, API Gateway, and other AWS services, a hosted login UI, and the free tier covering up to 50,000 monthly active users. For AWS-native teams that want to move fast and don't need financial-grade protocol features, it can be the simplest path to production.
Duende IdentityServer fits when you want the token server to be part of your application landscape: your code, your database, your UI, your deployment pipeline, and predictable licensing tiers based on functionality and client IDs instead of per-user pricing that grows with scale. It suits teams that already work in .NET and want their identity host to be a first-class, version-controlled, testable part of the system, with data staying in their own infrastructure. It is also the better fit for regulated environments that require FAPI compliance, DPoP, PAR, or CIBA, none of which Cognito offers natively.
On capabilities that people sometimes assume are cloud-only: multi-factor and passwordless are covered by Duende User Management, including passkeys and WebAuthn, TOTP, and email or SMS OTP. What differs is scope. Cognito also offers AWS credential brokering (identity pools), risk-based adaptive authentication, and seamless integration with AWS services. With Duende, those are either out of scope (identity pools are AWS-specific) or things you assemble and run, which is the control some teams want and the overhead other teams would rather avoid.
How Do You Migrate to Duende IdentityServer?
Cognito does not export password hashes, so a single-cutover migration means asking users to reset passwords. The lower-risk path is to federate first: add Cognito as an upstream OIDC provider to your Duende identity host, point applications at Duende one at a time, and migrate users on your own schedule. Cognito's "migrate user" Lambda trigger works in the opposite direction (migrating into Cognito), so it does not help here. The migration approaches post covers the general patterns.