In the last couple of months in the Penzle LLC we are considering changing our current Identity Provider (IdP) for a new one. We were waiting for the .NET 8 final release, counting to be able to use from it its new Authentication and Authorization features.

However, after some thought, we’ve decided not to use .NET 8 for this and to go with a different solution. In my next blog post, I am going to talk about why we made this decision, what are the limitations regarding .NET 8’s Authentication and Authorization and what other alternatives you might look at.

Understanding .NET 8’s Authentication and Authorization Enhancements

.NET 8 brought some improvements to its existing authentication and authorization capabilities, with an eye on modernization and simplification of these very important aspects of web development. The changes in this regard are interesting when working with Single Page Applications (SPAs). See them in action.

Bearer Token Authentication Handler

The new feature in .NET 8 handles the use of token-based authentication, especially appropriate for SPAs. It handles creation as well as validation of tokens, essentially how cookie-based authentication is being done, but on tokens. Here’s a more specific example:

As you can see from above example, the /login endpoint will authenticate the user and creates a session with a bearer token. Accessing the /user endpoint needs to be protected with that in mind, it requires to be authenticated as a user containing the bearer token.

Identity API Endpoints

In .NET 8, there will now be API endpoints for ASP.NET Core Identity, not only to manage users programmatically but do authentication as a whole, making ASP.NET Core Identity awesome to work with SPAs. This is such a break from the previous Razor Pages approach. An example of how this will look like:

From this example, the method is used to register the necessary services to enable the Identity API endpoints. The MapIdentityApi method maps these endpoints into the application, allowing operations like registration, login, and user management through API calls.

These improvements in .NET 8 give a more flexible and modern way of doing the authentication and authorization. Specifically for the SPAs, these are the kind of benefits appropriately fitting to the trend in the industry evolving towards an API-centric architecture. While this is not a full replacement of OpenID Connect solutions, they provide feature-rich ways to base most modern web application’s authentication and authorization needs.

Why .NET 8 Can’t Fully Replace OpenID Solutions

Despite the significant improvements in .NET 8, it doesn’t entirely replace OpenID solutions like IdentityServer or OpenIddict. Here are the key reasons.

Comprehensive Standards Compliance

The OpenID solutions come up with fully-fledged compliance with the OpenID Connect and OAuth 2.0 standards. They facilitate plenty of options in order to handle several authentication and authorization scenarios that are not at all well-covered by the inbuilt features enumerated in .NET 8.

Integration with External Authentication

.NET 8 is an internal authentication facilities focused largely. The solutions based on OpenID have a strong story of integration with many external authentication providers, especially for the social identity consumer and enterprise identity systems. This is of a high importance to the modern applications.

Enhanced Security Features

This is complemented by advanced security settings and configurations that are often associated with the OpenID solutions, beyond the reach of .NET 8. This includes consent frameworks as well as finer access control mechanisms.

Scalability and Flexibility

OpenID solutions are designed to support large-scale and flexible scaling with the demanding needs of applications and organizations. OpenIDs offer infrastructure for many users with varied authentication scenarios that need management that is part user-data management and part-directory.

Community and Ecosystem

OpenID solutions have a strong ecosystem and community and accompany plentiful resources, plugins, and support. It is very helpful when faced with special requirements to implement or keeping up-to-date security practices.

Limitations for Complex Scenarios

.NET 8 also brings remarkable advances in the authentication and authorization area like we said above, mainly in SPA development. But spoken generally about complex scenarios, comprehensive standards compliance, integration of external authentications or advanced security features, OpenID solutions like IdentityServer, or OpenIddict still make sense. They offer scalability, flexibility, and community support most applications would generally require, especially those provided on an enterprise level.

Adapting Identity Management in .NET 8 with IdentityServer or OpenIddict

.NET 8 is still compatible with Identity Server and OpenIddict despite ecosystem changes. It would still be possible for .NET 8 users who use Identity Server or OpenIddict to continue using it because its advanced features like OpenID Connect and OAuth 2.0 compatibility are still supported.

As a note, just keep in mind that based on what we can se now Microsoft plans on deprecating the reliance on Duende’s Identity Server by their SPA templates in .NET 8 itself, which means they are going to continue making progress towards an even more self-contained solution within the very ASP.NET Core Identity framework.

Speaking about complexity of these systems, in .NET 8 even the setup of authentication and authorization will be made easier, especially in the context of SPAs. While solutions Identity Server and OpenIddict provide are comprehensive and robust, they introduce a level of complexity which may well be undue for simpler applications or those not requiring the full range of features these platforms offer.

.NET 8 enhances the in-built ASP.NET Core Identity system and introduces new API endpoints for common identity tasks, hence reducing the need for external dependencies which potentially can simplifies development process of some type of applications.

However, if it comes to handling complex scenarios with more advanced identity management features, .NET 8 along with Identity Server or OpenIddict appears an option viable and powerful enough.

Final words

Having dived into the various in-depth details and analysis of the authentication and authorization improvements in .NET 8, especially in how they work with ASP.NET Core Identity, it is evident that employing these additions is highly dependent on your application’s requirements at different levels as well as its intricacy.

For Single SPA Applications

If your project is a simple Single Page Application (SPA) that has basic security requirements involving authentication and authorization of the identity for accessing data, .NET 8 provides a robust solution. The token-based authentication, tailored for a SPA, makes .NET 8 a very good choice for this use case. Benefit from a coherent, well integrated system within the .NET environment that reduces the need of external dependencies.

For Complex Scenarios

Otherwise, if your application’s architecture is more complex involves with intricate scenarios of authentication, integration with third-party services or high customization and flexibility required. In such cases, it would be more appropriate to use either the Backend for Frontend (BFF) pattern or involvement of external identity providers. Such approaches offer more flexibility and a chance to customize the authentication experience on your fine-grained needs, even if they might bring more complexity or require additional integration endeavors.

Although it is probable that .NET 8 greatly enhances the auth experience for most of the other developers, it is always good to see what your application needs specifically as well as your long-term objectives. In some cases, .NET 8 built-in features will be enough but for more sophisticated scenarios looking further and considering combined used of .NET 8 features together with other solutions like sidecar pattern may be the best path.

Ultimately, the choice should present a balance of simplicity and functionality as well as the possible future scalability based on your application needs or requirements.

The landscape of OpenID solutions is dynamic and rich, you can check some of next:

Keycloak: Developed by Red Hat, Keycloak is a widely-used solution for identity and access management. It supports OpenID Connect, OAuth 2.0, and SAML 2.0, making it versatile for different authentication scenarios.

Gluu Server: Gluu is a comprehensive identity and access management platform. It provides support for OpenID Connect, OAuth, UMA, SAML, FIDO2, and more. Gluu is known for its scalability and robustness, suitable for enterprise-level deployments.

OpenIddict: is willing to offer a versatile solution in order to implement the OpenID Connect client as alternative of Identity Server, server and token validation support within any ASP.NET Core 2.1 (and higher) application. It also fully supports applications based on the classic ASP.NET 4.6.1 (and higher), through a native Microsoft.Owin 4.2 integration.

OpenIddict supports fully the implicit/code/hybrid flows, the client credentials/resource owner password grants and it even includes support for the device authorization flow. Also has native support for Entity Framework Core, Entity Framework 6 and MongoDB out of the box. If a custom store is needed to work with other providers, one can be implemented.

Cheers! 👋

---

Follow me on LinkedIn: www.linkedin.com/comm/mynetwork/discovery-see-all?usecase=PEOPLE_FOLLOWS&followMember=admir-live