While there are standards like OAuth2 and OpenID Connect, the standards leave a lot of room for interpretation and freedom to the implementor. So every token server implementation is somewhat biased to how they work and what their focus is. While they are technically using the same protocol, there are major differences in the structure of the token, what type of tokens you can get, etc.
And as biased as the implementations are, so is this article. It is by far not covering a complete list of alternatives, but it is about alternatives that are either a good fit for .NET developers or offer a good ready-to-run product for certain scenarios.
Library or Product
In the identity space, we have a lot of different offerings. They range from libraries where you have to add and implement a lot of functionality by yourself to fully managed products where even the hosting is done for you.
While libraries usually give you the most flexibility, the cost of implementation is higher than with products or SaaS offerings. Besides the client integration, you also need to build the server and integrate it into your codebase. On the other hand, products and SaaS offerings are mostly ready to run, and you are able to integrate them very quickly, which gives you a short “time to first token”. This can give you a boost in development since you don’t need to spend a lot of time implementing your token server. But with products, and especially SaaS offerings, you have less flexibility, and you have to rely on extensions points given by the product.
The following paragraphs discuss my current view on three candidates from the identity space which can be a viable alternative to IdentityServer:
- OpenIddict
- Keycloak
- Azure AAD B2C
OpenIddict
OpenIddict is an open-source .NET library that helps you implement a security token service (STS). Therefore, it is the most “comparable” alternative to IdentityServer. Both are not ready-to-run products, but they are libraries for developers to use. OpenIddict can not only be used in ASP.NET Core applications but also in classic .NET Framework applications.
Similar to IdentityServer, OpenIddict focuses on client authentication and token issuing and does not handle user authentication – this needs to be implemented by you independent of the library. Both expect that you are authenticating and signing in the user. This gives you the flexibility to use whatever user store you have or like to. And it also lets you implement complex custom login flows.
Compared to IdentityServer, OpenIddict is even more “bare metal” and has even less functionality out of the box. For example, IdentityServer gives you client credential flow out of the box with just configuration needed. In OpenIddict, you also need to provide additional code for the token-endpoint in order to have a working client credential flow.
This is a tabular overview of OpenIddict based on some of the typical questions and requirements we see in customer projects:
Type | Library | |
License | Apache 2 | |
Language | C# / .NET | |
Protocols | OAuth, OpenID Connect | |
Flows & Grant Types | All + Custom grant types | |
Database Backend | Entity Framework Core only | |
Extensibility | .NET | |
Multi-Tenancy | Needs to be implemented by your self | |
Multi-factor-authentication | n/a | |
Admin UI | No, but there is a module for Orchard | |
Admin REST API | n/a | |
User Self-Service portal | n/a | |
Custom Themes | n/a | |
Pricing | No upfront or licensing costs | |
Support | Only via Github Issues |
Keycloak
Keycloak is an open-source Java-based identity and access management (IAM) solution. In contrast to IdentityServer and OpenIddict, it is a ready-to-run product that you can spin up in a couple of minutes using Docker. Since Keycloak is an IAM solution, it also handles the authentication of users and lets the administrator control which applications and APIs a user can use and access. In addition, applications can off-load their authorization to Keycloak, allowing administrators to configure permissions for users in applications and on resources. Besides providing an admin UI, Keycloak also comes with an admin REST-API enabling developers to create custom UIs and automate workflows.
Keycloak lets you integrate upstream identity providers like social logins and generic OpenId Connect (OIDC) and SAML-based identity providers. It also integrates with LDAP and Kerberos and can therefore be used to “modernize” legacy environments.
Since Keycloak is a product, it lacks some of the flexibility you have with a library. While there are some extension points available (using Java and Javascript), not everything can be fully customized. E.g., custom grant types are not supported today, or complex login flows beyond the configurable login flows that are provided by Keycloak are not possible.
Here is my overview for Keycloak:
Type | Product | |
License | Apache 2 | |
Language | Java | |
Protocols | OAuth, OpenID Connect, SAML, User-Managed Access (UMA) for authorization | |
Flows & Grant Types | Does not support Device Authorization and Custom grant types.
Has support for Token Exchange | |
Database Backend | Embedded, Oracle, Microsoft SQL Server, MySQL, PostgreSQL | |
Extensibility | Java / Some parts can be extended with JavaScript | |
Multi-Tenancy | Needs to be implemented by structuring your Keycloak installation, e.g. using realms or groups | |
Multi-factor-authentication | – All apps that support TOTP (e.g. Google Authenticator, Microsoft Authenticator, DUO Authenticator, etc)
– WebAuthn | |
Admin UI | Yes | |
Admin REST API | Yes | |
User Self-Service portal | Yes | |
Custom Themes | Yes | |
Pricing | No upfront or licensing costs | |
Support | – Paid product Red Hat Single Sign-On available.
– Community support via mailing list or forum |
Azure Active Directory (AAD) B2C
Azure Active Directory B2C is Microsoft’s Software-as-a-Service (SaaS) identity and access management for customer-facing apps offering. Since it is a SaaS offering it is kind of comparable to Keycloak. The major difference to Keycloak is that Azure B2C runs only in the Azure cloud, and there is no on-premises offering. Azure B2C authenticates users and clients and comes with a minimal authorization part based on roles. Azure B2C lacks a fine-grained authorization on a resource level like it is possible with Keycloak.
Again, being a SaaS offering there are minimal extension points. Azure B2C allows the usage of WebHooks to customize the registration and login flow. Besides WebHooks, login and registration flows can be configured by the administrator. Upstream identity providers like social logins and generic OpenId-Connect-based identity providers can be integrated, too.
With the Microsoft Graph API, developers can create custom Admin UIs or automation workflows. It also allows creating custom code to import and export users.
The pricing is based on monthly active users. The first 50.000 monthly active users are free. After that, you pay for every monthly active user. A user counts as “monthly active” as soon as he authenticates with your Azure AD B2C tenant.
Type | SaaS Product | |
License | n/a | |
Language | n/a | |
Protocols | OAuth, OpenID Connect, SAML | |
Flows & Grant Types | Does not support Resource Owner Flow, Device Authorization and Custom grant types | |
Database Backend | n/a | |
Extensibility | Very limited with WebHooks | |
Multi-Tenancy | Yes | |
Multi-factor-authentication | – All apps that support TOTP (e.g. Google Authenticator, Microsoft Authenticator, DUO Authenticator, etc)
– WebAuthn
– SMS
– Phone Call | |
Admin UI | Yes | |
Admin REST API | Yes | |
User Self-Service portal | Yes | |
Custom Themes | Very limited | |
Pricing | Pay per user with first 50.000 monthly active users free | |
Support | Yes via support ticket in Azure Portal. |
Summary
In this article, I have shown you three possible alternatives to IdentityServer. As already said, there are more alternatives on the market. But before switching to a different product/library, you should have a closer look at each of them and create prototypes to see if they fulfill your requirements. All products have their differences, and you should check which solution fits best for your needs. As always: the devil is in the detail, and some differences will only appear to you once you start integrating the solution.