{"id":36877,"date":"2017-01-23T11:36:46","date_gmt":"2017-01-23T19:36:46","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/webdev\/?p=8945"},"modified":"2017-01-23T11:36:46","modified_gmt":"2017-01-23T19:36:46","slug":"asp-net-core-authentication-with-identityserver4","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/asp-net-core-authentication-with-identityserver4\/","title":{"rendered":"ASP.NET Core Authentication with IdentityServer4"},"content":{"rendered":"

This is a guest post by Mike Rousos<\/em><\/p>\n

In my post on bearer token authentication in ASP.NET Core<\/a>, I mentioned that there are a couple good third-party libraries for issuing JWT bearer tokens in .NET Core. In that post, I used OpenIddict<\/a> to demonstrate how end-to-end token issuance can work in an ASP.NET Core application.<\/p>\n

Since that post was published, I’ve had some requests to also show how a similar result can be achieved with the other third-party authentication library available for .NET Core: IdentityServer4<\/a>. So, in this post, I’m revisiting the question of how to issue tokens in ASP.NET Core apps and, this time, I’ll use IdentityServer4 in the sample code.<\/p>\n

As before, I think it’s worth mentioning that there are a lot of good options available for authentication in ASP.NET Core. Azure Active Directory Authentication<\/a> is an easy way to get authentication as a service. If you would prefer to own the authentication process yourself, I’ve used and had success with both OpenIddict<\/a> and IdentityServer4<\/a>.<\/p>\n

Bear in mind that both IdentityServer4 and OpenIddict are third-party libraries, so they are maintained and supported by community members – not by Microsoft.<\/p>\n

<\/a>The Scenario<\/h2>\n

As you may remember from last time<\/a>, the goal of this scenario is to setup an authentication server which will allow users to sign in (via ASP.NET Core Identity<\/a>) and provides a JWT bearer token that can be used to access protected resources from a SPA or mobile app.<\/p>\n

In this scenario, all the components are owned by the same developer and trusted, so an OAuth 2.0 resource owner password flow<\/a> is acceptable (and is used here because it’s simple to use in a demonstration). Be aware that this model exposes user credentials and access tokens (both of which are sensitive and could be used to impersonate a user) to the client. In more complex scenarios (especially if clients shouldn’t be trusted with user credentials or access tokens), OpenID Connect flows such as implicit<\/a> or hybrid<\/a> flows are preferable. IdentityServer4 and OpenIddict both support those scenarios. One of IdentityServer4’s maintainers (Dominick Baier) has a good blog post on when different flows should be used<\/a> and IdentityServer4 quickstarts include a sample of using the implicit flow<\/a>.<\/p>\n

As we walk through this scenario, I’d also encourage you to check out IdentityServer4 documentation<\/a>, as it gives more detail than I can fit into this (relatively) short post.<\/p>\n

<\/a>Getting Started<\/h2>\n

As before, my first step is to create a new ASP.NET Core web app from the ‘web application’ template, making sure to select “Individual User Accounts” authentication. This will create an app that uses ASP.NET Core Identity to manage users. An Entity Framework Core context will be auto-generated to manage identity storage. The connection string in appsettings.json points to the database where this data will be stored.<\/p>\n

Because it’s interesting to understand how IdentityServer4 includes role and claim information in its tokens, I also seed the database with a couple roles and add a custom property (OfficeNumber<\/code>) to my ApplicationUser<\/code> type which can be used as a custom claim later.<\/p>\n

These initial steps of setting up an ASP.NET Core application with identity are identical to what I did in my previously with OpenIddict, so I won’t go into great detail here. If you would like this setup explained further, please see my previous post<\/a>.<\/p>\n

<\/a>Adding IdentityServer4<\/h2>\n

Now that our base ASP.NET Core application is up and running (with Identity services), we’re ready to add IdentityServer4 support.<\/p>\n

    \n
  1. Add \"IdentityServer4\": \"1.0.2\"<\/code> as a dependency in the app’s project.json file.<\/li>\n
  2. Add IdentityServer4 to the HTTP request processing pipeline with a call to app.UseIdentityServer()<\/code> in the app’s Startup.Configure<\/code> method.\n
      \n
    1. It’s important that the UseIdentityServer()<\/code> call come after registering ASP.NET Core Identity (app.UseIdentity()<\/code>).<\/li>\n<\/ol>\n<\/li>\n
    2. Register IdentityServer4 services in the Startup.ConfigureServices<\/code> method by calling services.AddIdentityServer()<\/code>.<\/li>\n<\/ol>\n

      We’ll also want to specify how IdentityServer4 should sign tokens. During development, an auto-generated certificate can be used to sign tokens by calling AddTemporarySigningCredential<\/code> after the call to AddIdentityServer<\/code> in Startup.ConfigureServices<\/code>. Eventually, we’ll want to use a real cert for signing, though. We can sign with an x509 certificate by calling AddSigningCredential<\/code>:<\/p>\n

      \n
      services.AddIdentityServer()\n  \/\/ .AddTemporarySigningCredential() \/\/ Can be used for testing until a real cert is available<\/span>\n  .AddSigningCredential(new<\/span> X509Certificate2(Path.Combine(\"<\/span>.\"<\/span><\/span>, \"<\/span>certs\"<\/span><\/span>, \"<\/span>IdentityServer4Auth.pfx\"<\/span><\/span>)))<\/pre>\n<\/div>\n
      Note that you should not load the certificate from the app path in production; there are other AddSigningCredential<\/code> overloads that can be used to load the certificate from the machine’s certificate store.<\/p>\n
      As mentioned in my previous post<\/a>, it’s possible to create self-signed certificates for testing this out with the makecert<\/code> and pvk2pfx<\/code> command line tools (which should be on the path in a Visual Studio Developer Command prompt).<\/p>\n