by Nate Barbettini | June 2, 2016 |

ASP.NET has always been a solid choice for building large-scale enterprise applications, owing to the power and maturity of the platform (and Microsoft’s enterprise support). However, because it is tightly coupled to Windows, it couldn’t get the same reach as frameworks based on cross-platform technologies like Java and Node. That’s all changing, thanks to Microsoft’s cross-platform efforts with .NET Core.

ASP.NET Core 1.0

The cross-platform rewrite known as ASP.NET Core 1.0 runs on Windows and Linux (today!), and brings us modern concepts like a middleware-first application pipeline and integrated dependency injection to ASP.NET. These additional features add more power to a stack that already has the Promised Land™ that is async/await, LINQ, and dynamics.

As always, change has pros and cons. The new direction of ASP.NET Core 1.0 is exciting, but the sheer number of breaking changes means that a lot of code needs to be rewritten to be compatible with new projects. It’s the early days, and the open-source community is working hard to produce code for the new platform. Six to twelve months from now, there will be a huge amount of code and numerous packages available for ASP.NET Core… But what if you’re building a new project on Core today?

User management and authentication is one of the biggest hurdles in designing a new application. It’s a cross-cutting concern that touches the database, business logic, and presentation layers, and has broad implications for scalability and maintainability. Put simply, it’s one part of your application you need to nail down solid.

Let’s take a look at what’s available today for user management and authentication/authorization in ASP.NET Core.

Authentication and Authorization in ASP.NET Core

There are already a few solutions available for ASP.NET Core projects. In no particular order:

ASP.NET Core Identity

ASP.NET Core Identity (formerly known as Identity 3.0) is the next evolution of ASP.NET Identity 2.0. The Identity team has addressed many of the complaints with the previous version, and the initial results look very promising.

The primary goals of the Core Identity framework are to:

  • Act as an abstraction layer between your application and the user/role data store
  • Provide a lot of boilerplate plumbing and logic out of the box
  • Communicate with external login providers like Facebook and Google

In the default configuration, ASP.NET Core Identity comes paired with Entity Framework Core and SQL Server for data persistence. If SQL Server doesn’t float your boat, you can use a different EF-compatible database provider like SQLite or Postgres. Or, you can plug in an entirely separate provider for your own data store that isn’t based on Entity Framework, such as MongoDB. The beauty of the Core Identity framework model is that it exposes a set of interfaces that you can implement to plug in your own data store and behavior.

ASP.NET Core Identity is a great halfway point between a build-your-own system and a hosted user management solution (more on this later). It’s a powerful framework that includes a lot of built-in functionality, and has good extension points when you need to add your own behavior or services. It works well with Facebook, Google, and a few other external login providers out of the box with minimal configuration.

If you’re using SQL Server, you shouldn’t need to write much custom code at all; if you want a different data store, be prepared to write at least a little plumbing code. Currently, both Core Identity and Entity Framework Core are in the release candidate stage, which means they are very close to being production-ready.

Thinktecture IdentityServer4

Thinktecture’s IdentityServer3 was a popular open-source authentication and authorization solution for ASP.NET 4.x, and IdentityServer4 will not only be continuing that legacy, but will be the ASP.NET team’s de facto choice for implementing OAuth 2.0 and token authentication functionality on ASP.NET Core.

It’s not quite fair to put IdentityServer and ASP.NET Core Identity head-to-head because the comparison is a little more apples-to-oranges. Core Identity is focused on abstracting user management and persistence, while IdentityServer is an OAuth 2.0 and OpenID Connect server that can sit on top of a number of persistence layers, including ASP.NET Core Identity.

IdentityServer functions as a security token service for implementing token authentication and OAuth 2.0 flows. It’s a powerful and well-documented solution and has a lot of community support. IdentityServer4 (with .NET Core support) is currently in beta but is already being used in some applications.

If you need to support token authentication or OpenID Connect in your application, IdentityServer is a great (but somewhat complex) choice that you can use alongside (or instead of) a user management solution like ASP.NET Core Identity.

OpenIddict

OpenIddict is a newer open-source project that aims, like IdentityServer, to bring token authentication and OpenID Connect support to ASP.NET Core. In contrast to IdentityServer, it’s directly tied to ASP.NET Core Identity for its user management and persistence layer.

OpenIddict lacks some of IdentityServer’s complexity – and depending on your project needs, that might be a good thing! The goal of OpenIddict is to be a simple and easy-to-use solution. If you’re already using ASP.NET Core Identity, you can wire up OpenIddict with some boilerplate code and get OpenID Connect and token generation working quickly.

There isn’t much documentation available yet, outside of some sample code, but this project looks like a promising choice for ASP.NET Core applications that will be using ASP.NET Core Identity and need OAuth or OpenID Connect.

Build-Your-Own User Management

If your application requirements don’t easily fit into one of the pre-built solutions, or you want complete control over your infrastructure, it’s possible to roll your own authentication and user management. You’ll need:

  • A database or persistence layer for user data
  • A password hashing and salting mechanism
  • An email service (if you need to send verification or password reset emails)
  • A token generation mechanism (if you’re supporting OAuth)
  • Integrations with any social login providers you need to support

The flexibility to build exactly what you need with a homebrew solution is balanced by the cost of maintaining and securing what inevitably becomes a complex system. Just one piece of the puzzle — password hashing — should be continually re-evaluated as new threats emerge and computing performance starts overtaking weaker hashing mechanisms. Upkeep and bug fixes can end up being a lot of work.

With solid open-source code coming out of both Microsoft and the community at large, build-your-own is probably unnecessary for all but the most bespoke applications.

User Management as a Service

The recent trend in software development has been towards composable microservices and API services that act as the small, distinct building blocks of a larger application. Some providers (including Stormpath!) offer user management and authentication APIs in a service-oriented, API-friendly way.

A big advantage to this approach is that you don’t have to be a security expert to have strong user security. Plus, you don’t have to worry about setting up and maintaining the infrastructure required to handle user authentication and persistence. Instead, you can focus on your application and business logic concerns, and let the API services handle the rest.

On top of that, the more functionality you can outsource to an API service, the less you have to build in-house. Many hosted user management offerings have support for features like:

On the flip side, this does mean additional external dependencies for your application. If the APIs you rely on go down, your application becomes degraded or goes down completely. For a security-critical concern like authentication, you’ll also need to make sure that your user data is being transported and stored securely. Here at Stormpath, we have high availability guarantees and some of the strongest security in the industry.

With the proper planning, using a hosted user management service can be an excellent way to build and ship large-scale ASP.NET Core applications more quickly, with less time spent on reinventing the wheel and more spent on your core business logic.

User Management Is Hard

No matter how you build or compose your system, deploying user management and authentication isn’t an easy task. If you’re interested in a hosted user management service, check out Stormpath’s open-source ASP.NET Core integration:

I hope this post helps you understand the current lay of the land when it comes to user management in ASP.NET Core. If you have any questions, leave me a comment below, or reach out to me on Twitter at @nbarbettini!