Do you choose the best authentication method for every situation?

Authentication and authorization are complicated, and it is risky to try and implement them yourself. Use this rule as a guide on choosing the right service or framework for your situation.

Choosing the right authentication and authorization approach for your situation can be tricky. It is a multi-faceted problem with many variables, and what seems like the right choice in one situation may not be in the other.

Start with the questions

• Scope - Is it an enterprise application for internal users or a consumer application for external use?
• Scope - Do you need to share the identity across multiple applications?
• Volume - Do you have an estimate for how many users you need to support?
• Complexity - do you need to execute arbitrary logic (see below) as part of your authentication process?

Without the answers to these questions, it will be difficult to choose the right option. With the answers to these questions, you can use the tips and flow chart below as a guide to help you choose the right solution.

'Complexity' in authentication

Most applications require some form of authentication, and it's often as simple as providing a secure way for users to log in and ensure that unauthenticated users don't get access to protected resources. However, it's not uncommon to require some logic to be executed as part of the authentication process. Some examples might include:

• Querying an application to get a list of a user's roles
• Calling an API to check a conditional access policy
• Registering a user with an application during sign-up
• Integrating a technology that is not included out of the box (e.g. WebAuthN)
• Non-standard integration with an upstream identity provider

Note that some of the options listed below support or include the features listed above, and these may be configurable directly rather than needing additional code or logic to support. These usually come with additional costs. When you need one of these that is not provided "out-of-the box", you need to build this yourself. Most of the options listed here provide a way to inject custom arbitrary logic into the authentication process, but they have different ways of achieving this and varying limitations.

Narrow your options

Each project is different, and you will need to consider your individual needs and circumstances when choosing how to implement identity and authentication in your solution. There are countless options available for authentication, but the chart below can provide a guide for some of the major decisions, and help you narrow down to some of the relevant options. Use this to get started and be sure to consider all the other information in this rule before making a decision.

flowchart

 Start(["Start"]) --> CustomLogic{"Need Custom/\nComplex Logic?"}

 CustomLogic -->|"Yes"| IdentityServer(["IdentityServer"])
 CustomLogic -->|"No"| AppType{"Application Type?"}

 AppType -->|"Internal (Intranet)"| Kerberos{"Need Kerberos/\nAD Integration?"}
 AppType -->|"External (B2B/B2C)"| Hosting{"Hosting?"}

 KerberosHosting{"Hosting?"} -->|"On-Premises"| SingleApp{"SSO?"}
 KerberosHosting -->|"Cloud"| Ecosystem{"Existing Ecosystem/\nPreference?"}

 Kerberos -->|"No"| KerberosHosting
 Kerberos -->|"Yes"| OnPremAD(["On-Premises Active Directory"])

 Hosting -->|"On-Premises"| Kerberos
 Hosting -->|"Cloud"| Ecosystem

 Ecosystem --> Entra(["Entra ID"])
 Ecosystem --> Auth0(["Auth0"])
 Ecosystem --> WorkOS(["WorkOS"])
 Ecosystem --> BetterAuth(["Better Auth"])
 Ecosystem --> OtherIDP(["Other Cloud IDP"])

 SingleApp -->|"Yes"| IdentityServer
 SingleApp -->|"No"| NETCORE(["ASP.NET Core Identity"])

Figure: Authentication Selection

Your situation is unique, and every application's requirements are different. These tips can help you identify options to consider for your solution.

Additional considerations

In addition to the main points discussed above, the following considerations could also be relevant to your decision.

❗ Always important

• Scalability: Depending on the expected user base and request volume, scalability can be a concern. Some solutions might offer better scalability options than others
• Cost: The costs associated with different solutions can vary. It's essential to consider both initial setup costs and ongoing operational costs
• Maintenance & Support: How easy is it to maintain the solution? Is there good community or official support available? This can be crucial for troubleshooting and ensuring the system remains operational

⚠️ Important - but depends more on your needs

• Regulatory & Compliance Needs: Depending on the industry, there might be specific regulatory or compliance requirements related to authentication. For example, financial or healthcare industries might have stricter requirements
• User Experience: The ease of use for end-users can be a factor. Some solutions might offer a smoother user experience, fewer login prompts, or better integration with other services
• Flexibility & Extensibility: How easy is it to extend or modify the authentication process in the future? This can be crucial if there's a need to add new features or integrations later on
• Security Features: Beyond MFA, what other security features do the solutions offer? This can include things like anomaly detection, risk-based authentication, or integration with threat intelligence services

While there are too many options to cover them all, this chart will help you narrow your choice to a few key options. Some detail about these options is provided below.

1. ASP.NET Core Identity (simple and free)

ASP.NET Core has some built-in identity functionality that allows you to create users and roles, and manage the security of your web applications. It is extremely capable and can be used to support a broad number of scenarios. However, it is intended for use in simple web applications, and while it can be extended to support other clients, you will need to build and wire up a lot of the UI for these scenarios yourself.

Identity Endpoints were introduced in .NET 8 and have continued to evolve in .NET 9 and .NET 10, allowing you to support even more scenarios (like using API endpoints to exchange a username and password for an access token).

However, the most important consideration is that this approach is intended for use in a single, standalone application.

Your identity store will be limited to this one application, so your users will not be able to share this identity across multiple applications.

✅ Advantages:

• Free
• Easy to set up and use
• Supports OAuth2/OIDC providers

❌ Disadvantages:

• It is recommended by Microsoft that for advanced requirements you don't use this on its own - so need to add one of the below
• Does not scale across multiple applications - so need to add one of the below
• For anything other than an ASP.NET Core Web app (e.g. Angular, React, or mobile), you have to build all UI yourself, such as: sign up, log, password reset, etc.
  • Note: You will need to build this UI yourself anyway if using Identity Endpoints.

Use this option if...

• You need to add identity to a simple ASP.NET application

2. IdentityServer (full control)

Identity Server is a source-available, OIDC compliant solution from Duende that is built on top of ASP.NET Core. It is licensed under the Duende Software License, which is free via the Community Edition for qualifying small companies (less than $1M projected annual revenue and less than $3M in capital). Production use by larger organizations requires a paid license (Starter at $1,500/year, Business at $9,000/year, or Enterprise at $20,000/year). It has extensive support for a number of authentication and authorization scenarios and supports multiple external identity providers out of the box (meaning it can easily integrate with Microsoft, Google, etc. accounts). IdentityServer extends ASP.NET Core Identity to natively support multiple client types (e.g. web, mobile, machine-to-machine, etc.) and can be used as a single identity across multiple applications.

IdentityServer provides unmatched flexibility and control over your authentication process. While some other options provide ways to execute custom logic as part of a login process, for anything beyond the most basic of scenarios, IdentityServer will be orders of magnitude easier to implement.

By running your own IdentityServer, you can provide and manage your own SSO IDP across multiple applications.

✅ Advantages:

• Free via Community Edition for small companies (under $1M revenue / $3M capital); paid tiers from $1,500/year
• Allows you to define custom authentication logic (see 'Complexity' in authentication above)
• Supports multiple applications/identity consumers
• Supports multiple clients and client types
• Fully OIDC compliant

❌ Disadvantages:

• Learning curve
• Requires additional hosting resources
• Requires additional skill set
• Requires ongoing maintenance
• Annual license fee for larger organizations ($1,500-$20,000+/year depending on tier)

Use this option if...

• You need to inject custom logic into your authentication flow, or:
• You have compliance requirements that prohibit you from using a cloud IDP

3. OpenIddict (extend to build your own auth)

OpenIddict is an open-source framework designed for ASP.NET Core that facilitates the implementation of OpenID Connect (OIDC) servers. Whereas IdentityServer provides a full solution, OpenIddict provides a foundation upon which you can build your own IdentityServer-like product.

Out of the box, it provides support for all of the core OIDC functionality (i.e. granting and validating tokens), but does not provide any UI or user management, or any way to manage clients, resources, scopes etc.

Because of this, it provides even more flexibility than IdentityServer; but this comes at the cost of taking on a significant implementation overhead yourself (it's like saying buying a bunch of car parts provides more flexibility than buying a car).

✅ Advantages:

• FOSS
• Fully OIDC compliant
• Enables you to build your own identity solution without having to rebuild the fundamentals

❌ Disadvantages:

• You have to do nearly everything yourself
• Significant maintenance overhead
• Requires significant security expertise

Use this option if...

• You are time rich and money poor, and/or:
• You can commit substantial well-skilled (in security and development) human resources to building and maintaining it, and/or:
• You are intending to build your own authentication product

4. Active Directory (for Internal Enterprise Applications)

Active Directory has been the de facto enterprise identity store for most of the world for decades. While most organizations are moving to the cloud these days, many still use AD as it provides a lot of additional capability and is integrated with most of their existing enterprise applications. AD supports multiple authentication protocols, including:

• LDAP/LDAPS: simple to use but old tech, requires multiple queries to check permissions, roles not natively supported, and need to be managed by groups.
• Kerberos: Excellent experience for users as it provides a silent and transparent login. But can only be used for on-premises, domain-joined computers.
• ADFS/SAML: Modern application authentication against AD is done via ADFS with SAML. This is often extended through third-party tools such as Okta to support applications that use JWT and claims.
• Proprietary Microsoft: Basic, NTLM, etc.

✅ Advantages:

• Already in place in most enterprise organizations
• Users do not require an additional identity
• Can make the application compliant with the organization's existing security policies

❌ Disadvantages:

• Not suited to external use
• Not natively supported off-premises
• No MFA included

Use this option if...

• Your application, domain controllers, and clients are all on the same network, and:
• You already have AD in place and have a security policy that states that all your users must authenticate against your centralized corporate identity, and/or:
• You want to enable pass-through/silent authentication for your users

5. Microsoft Entra ID (previously Azure AD) (for Internal Enterprise Applications)

Microsoft Entra is Microsoft's cloud-based identity and network/access management platform and provides strong identity features such as MFA and self-service password recovery, as well as access policies and anomaly detection. Being cloud-based, it can authenticate users anywhere in the world (rather than just on-premises on corporate computers).

✅ Advantages:

• Many organizations already using it
• Extends existing enterprise identity to the cloud (i.e. is supported off-premises)
• Can be used to ensure compliance with existing company security policies
• MFA support included

❌ Disadvantages:

• Can be costly for features not in the free tier
• Requires a skilled Azure SysAdmin to manage

Use this option if...

• You want to support internal/enterprise users, and:
• You already have Azure set up, and/or:
• Your users require access from off-site, and/or:
• You need to enforce MFA

6. Microsoft Entra External ID (previously Azure AD B2C) (simple Auth as a Service)

Microsoft Entra External ID has replaced AAD B2C. It's part of the Microsoft Entra family and includes all the benefits it provides, as well as enabling consumer-friendly features. These include integration with external identity providers and more flexible/customizable login flows. It is well-tailored to support authentication, and while it can be extended to support additional capabilities, this requires custom development.

✅ Advantages:

• Inexpensive and generous free tier
• Native support for multiple external auth providers
• MFA support included
• Relatively straightforward to set up
• Ongoing security maintained by Microsoft

❌ Disadvantages:

• Very limited flexibility
• Can support roles and other extended functionality, but requires significant development

Use this option if...

• You want to support MFA, and/or:
• Your users are external/consumers, and:
• You anticipate a high volume of users, and/or:
• You only require simple authentication and limited or no authorization

7. Auth0 (sophisticated Auth as a Service)

Auth0 is a commercial identity product aimed at developers. It is cloud-hosted and offers out-of-the-box functionality for user signup and login, self-service password recovery, OIDC compliance, external auth integration, and other consumer and user-friendly features. MFA is supported out of the box, and significant sophisticated functionality is available on the paid tiers.

✅ Advantages:

• Good free tier
• Very easy to set up and use
• MFA support included
• Supports multiple external auth providers
• Significant extensibility

❌ Disadvantages:

• Free tier is more limited in volume than competition (e.g. Microsoft Entra External ID)
• Free tier only includes the basic functionality (same as Microsoft Entra External ID)
• Free tier only supports 2 social identity providers

Use this option if...

• You want to enforce MFA, and/or:
• Your users are external/consumers, and/or:
• You require authorization or complex authentication

8. Okta (for Commercial Enterprise Applications $)

Okta is a commercial identity product aimed at enterprises. Many enterprise-centric software products, for example, Salesforce, have Okta connectors. Okta is intended to bridge the gap between enterprise authentication (such as AD) and modern software and SaaS products.

✅ Advantages:

• Integrates with anything
• Very well supported in the enterprise
• Can simplify integration with AD

❌ Disadvantages:

• Expensive for production use (Integrator Free Plan available for development/testing)
• Primarily suited to workforce/enterprise identity (for consumer-facing scenarios, Okta offers Customer Identity Cloud, powered by Auth0)

Use this option if...

• Your application is for internal/enterprise users, and:
• You already have Okta in place, and/or:
• Your application is a product that you intend to commercialize (Okta is prevalent in the enterprise and having an Okta connector is a good selling point)

9. Keycloak (Open-Source IAM Solution)

Keycloak is an open-source identity and access management solution created in 2014. Governed by the Cloud Native Computing Foundation (CNCF) as an incubating project since April 2023, it provides enterprise-grade authentication and authorization capabilities through OIDC/OAuth 2.0/SAML SSO, identity brokering, and social logins.

✅ Advantages:

• CNCF ecosystem integration with native Kubernetes Operator support and Prometheus monitoring
• Persistent user sessions in v26 ensure seamless authentication during migrations/restarts
• Multi-site deployment optimizations for global enterprise configurations
• Red Hat downstream support with commercial SLAs available through Red Hat build of Keycloak
• Extensible architecture supporting LDAP/Active Directory federation and third-party integrations

❌ Disadvantages:

• Complex clustering requiring Kubernetes/OpenShift operational expertise
• Limited mobile SDKs necessitating third-party libraries like AppAuth
• Community-driven support without guaranteed 24/7 incident response (commercial support available via Red Hat)

Use this option if...

• You require CNCF-aligned IAM with Envoy service mesh compatibility
• Your team manages Kubernetes environments via Helm/Operators
• Protocol flexibility (SAML/OIDC hybrid flows) is critical
• You need open-source solutions with enterprise upgrade paths
• Data sovereignty and multi-cloud deployments are priorities
• You don't need enterprise level support

10. Better Auth (TypeScript-first open-source auth)

Better Auth is a comprehensive, framework-agnostic authentication framework for TypeScript that emerged in 2024 as the spiritual successor to NextAuth.js / Auth.js. In 2025, Auth.js (formerly NextAuth.js) was handed over to the Better Auth team for ongoing maintenance, consolidating the JavaScript/TypeScript open-source auth ecosystem under one roof. Better Auth has become one of the most widely adopted authentication solutions in the TypeScript ecosystem, backed by Y Combinator, Peak XV (formerly Sequoia), and a $5M seed round. It is self-hosted by default, fully open-source (MIT), and built from the ground up with end-to-end TypeScript type safety in mind.

Unlike IdentityServer (which targets .NET), Better Auth is designed for JavaScript and TypeScript stacks, including Next.js, SvelteKit, Nuxt, Astro, Express, Hono, and more. It also provides plug-and-play integrations for mobile and desktop: the official @better-auth/expo plugin adds authentication to Expo (React Native) apps for both iOS and Android, while the @better-auth/electron plugin (added in v1.5) handles the full OAuth flow for Electron desktop apps, including opening the system browser, exchanging authorization codes via custom protocol, and managing cookies securely. It ships with email/password auth, 2FA (TOTP/SMS), organisation/team management, and an extensible plugin system out of the box, without requiring third-party packages for common scenarios. If you are coming from NextAuth.js, an official migration guide is provided.

Better Auth includes 40+ pre-configured social login providers out of the box, including Google, GitHub, Apple, Discord, Microsoft, Facebook, Twitter/X, GitLab, Spotify, Twitch, LinkedIn, Slack, Dropbox, and more. Any OAuth2 or OIDC-compliant provider can also be added through the Generic OAuth plugin.

Better Auth uses traditional cookie-based server-side session management, where the session is stored in the database and a secure, httpOnly cookie is sent to the client. This means tokens are never exposed to the browser, reducing the attack surface for XSS and token theft compared to JWT-in-localStorage approaches. This architecture aligns well with the Backend for Frontend (BFF) security pattern and is well-suited for modern full-stack frameworks like Next.js, SvelteKit, and Nuxt where the server and client work closely together.

The project is actively maintained with frequent releases (v1.5 shipped 600+ commits, 70 new features, and 200 bug fixes), a growing community, and stewardship of the Auth.js project.

✅ Advantages:

• Free and open-source (MIT)
• Native TypeScript with full end-to-end type safety and inferred types
• Framework-agnostic: works with Next.js, SvelteKit, Nuxt, Astro, Express, Hono, and more
• 40+ built-in social login providers (Google, GitHub, Apple, Discord, Microsoft, Facebook, Twitter/X, LinkedIn, Slack, and more) plus Generic OAuth for any custom provider
• Built-in 2FA (TOTP/SMS), organisation management, passkeys, magic links, and session management out of the box
• Server-side session management with secure, httpOnly cookies (no tokens exposed to the browser), aligning with BFF security principles
• Extensible plugin ecosystem (admin panel, API keys, multi-tenancy, SAML SSO, seat-based billing, etc.)
• Better Auth team now maintains Auth.js/NextAuth.js, providing a clear migration path from NextAuth
• Native Drizzle/Prisma integration with automatic schema generation
• Plug-and-play mobile and desktop support: official Expo (React Native) plugin for iOS/Android and Electron plugin for desktop apps
• Actively maintained with frequent releases and a growing community

❌ Disadvantages:

• JavaScript/TypeScript ecosystem only, not suitable for .NET or other non-JS stacks
• Self-hosted by default: you manage your own deployment, scaling, and updates
• No fully hosted tier yet (you still run your own server), though paid Infrastructure add-ons provide a dashboard, abuse protection, and enterprise features
• Newer project (2024) with a smaller community than Auth0, IdentityServer, or Entra, though growing rapidly
• SCIM directory sync requires the paid Infrastructure tier; stateless sessions without a database are not yet supported

Use this option if...

• You are building a TypeScript or JavaScript application (Next.js, SvelteKit, Nuxt, etc.), and:
• You want a self-hosted, open-source solution with full control, and/or:
• You are migrating from NextAuth.js and need a more feature-rich successor, and/or:
• You need built-in 2FA or organisation management without additional configuration, and/or:
• You want server-side session management with secure httpOnly cookies

11. WorkOS (B2B SaaS Auth as a Service)

WorkOS is a commercial, cloud-hosted identity platform designed primarily for B2B SaaS applications that need enterprise-grade authentication. Its flagship product, AuthKit, provides a hosted authentication UI and API covering the full range of modern auth needs — from simple email/password to Enterprise SSO — with a developer-first approach and one of the most generous free tiers available.

WorkOS is particularly well-suited to SaaS products that need to support enterprise customers with SSO requirements. It offers per-connection SSO pricing and a built-in Admin Portal that lets customers self-serve their own identity configuration, removing support burden from your team.

✅ Advantages:

• Very generous free tier: first 1 million MAUs free
• Supports Email/Password, Social Auth (Google, Microsoft, Apple, GitHub, and more), Magic Auth (passwordless), MFA (TOTP + SMS), and Passkeys out of the box
• Enterprise SSO (SAML/OIDC) and Directory Sync (SCIM) for B2B enterprise customers
• Built-in Admin Portal for self-serve enterprise identity configuration
• Role-Based Access Control (RBAC) and Just-in-Time (JIT) user provisioning included
• SDKs for many platforms including .NET, Node.js, Python, Ruby, Go, PHP, and more
• Pre-built hosted UI (AuthKit) — fast to integrate, no auth UI to build yourself
• Organization-based model maps naturally to multi-tenant B2B SaaS

❌ Disadvantages:

• Fully managed cloud only — no self-hosting option
• Enterprise SSO is priced per connection per month, which can become expensive at scale
• Primarily designed for B2B/workforce scenarios — less optimised for pure B2C/consumer apps
• Commercial product with proprietary licensing — not open source

Use this option if...

• You are building a B2B SaaS product that needs Enterprise SSO for enterprise customers, and/or:
• You want a cloud-managed solution with a generous free tier (up to 1 million users), and/or:
• You need a self-serve Admin Portal so enterprise customers can configure their own SSO/SCIM, and/or:
• You want minimal operational overhead with SDKs across multiple languages including .NET

12. Roll your own - a solution looking for a problem :-)

It is entirely possible to create a users table and a roles table in your database and create and manage users yourself.

✅ Advantages:

• Developers feel like they're ninjas for a little while
• Can be a quick and dirty solution to the absolute most basic situation

❌ Disadvantages:

• You have to "reinvent the wheel"
  • Identity
  • Roles
  • Email verification
  • Login/Signup/Password reset
  • Claims management
• Significant risk
• High maintenance overhead
• Masses of technical debt

Use this option if...

• You want a side project to learn more about how you might roll your own, but of course, you never intend to put it into production :-)

Sample decision - External Applications

External applications are B2B or B2C applications that are intended for consumption outside of your organization.

Example template to customer

✅ Figure: Good example - The chosen solution meets the requirements and is highlighted as per [Do you manage up?](/do-you-manage-up)

Sample decision - Internal Applications

For internal applications (referred to as "intranet applications" by Microsoft), the requirements might be different to externally facing applications. For example, they are more likely to be hosted on-premises (rare these days), or may need to use Windows Integrated Authentication (also rare these days, but provides a wonderful UX).

Example template to customer

✅ Good example - The chosen solution meets the requirements without adding unnecessary additional costs

Notes:

• All of the following options assume you are building an ASP.NET Core application, although the commercial options listed here provide libraries for most development languages, frameworks, and platforms.
• The information here is relevant as provided, but consider other factors that may impact your decision too. For example, cost may be a factor and saving money may be more important than the added benefits of higher-cost options. Additionally, your situation may not fit neatly into one of the scenarios we have listed and may span multiple scenarios, in which case you may need to pick the option which caters to the broadest set of requirements (avoid 'mix and match').