Authentication in ASP.NET Core 2.04 min read

As you might know the .NET Core 2.0 was release recently and with it come many improvements and changes. In this post I will point out a couple of changes from a security and authentication perspective. 


If you have previously used any form of authentication in ASP.NET Core 1.0, you would know that in order to configure your preferred mechanism you have to call one of the middle-wares available. For example if you wanted to use cookie authentication (local) this is how it would look like:

This basically means that you are letting ASP.Net know that you want to use cookie authentication with a specific login/access denied path. Also you want to enable automatic authenticate which means the middleware will run on every inbound request, look for a cookie and if one is present it will validate it, and if valid create an identity from it and add it to the current user.

I will not go through more details as it is not the purpose of this post but you can find all the details on Microsoft Official Documentation. Same thing is true if you wanted to use JWT bearer or any other form of authentication.

Remember that you can use multiple middle wares in conjunction to support more complex scenarios.

However, this has changed quite a bit in version 2.0 in a sense that all of these has been combined into a single service which you will need to configure. Also they have moved from Microsoft.AspNetCore.Http.Authentication namespace to Microsoft.AspNetCore.Authentication.  Also instead of calling context.Authentication.Authenticate|Challenge|SignInAsync you will call them on context directly like context.Authenticate|Challenge|SignInAsync.

That said if you just change your framework you will get a compile error which is awesome:

To achieve the above scenario you will need to first configure the service:

It is very similar to how you used to configure your cookie authentication middle ware, except that you now have to define a default scheme in the constructor of the service. In above we’ve configured the default to be CookieAuthenticationDefaults.AuthenticationScheme.

There is a catch here, and that is just be defining the service configuration your application will not use authentication, you will need add app.UseAuthentication(); at the top of the Configure() method.


You still can use your older code for authorisation though:

And in your controller:

Active vs Passive

With the new version there is only one active authentication scheme at a time, because of the fact that it is not a single service. But first let me give a bit of history on what is active vs passive.

Well authentication middleware has the concept of passive vs. active. Active middleware always look at every incoming request and attempt to authenticate the call and if successful they create a principal that represents the current user and assign that principal to the hosting environment. Passive middleware, on the other hand, only inspects the request when asked to.

Are you wondering what is the benefit of this? Well you won’t get complex scenarios where one of the middleware is failed but you cannot prevent others to get invoked.

Two Factor Authentication (2FA) is now added

ASP.NET Identity has now support for two factor authentication using Time-based One-time Password Algorithm (TOTP), and in fact that is now its default option. That means you can use the authenticator app using a QR Code which is preferred over SMS 2FA which was available in version 1.0.

Also the ASP.NET Core web app templates support authenticators, but do not provide support for QRCode generation. QRCode generators ease the setup of 2FA.

Spread the love

6 Replies to “Authentication in ASP.NET Core 2.04 min read

  1. Great. This article is about .net core 2.0 and the UseJwtBearerAuthentication is linked to the page that does not work for .net core 2.0.


    1. That link is only a reference to the concept. the post is about how to migrate.


  2. In you example, if I set the options.LoginPath of the AddCookie to something else like “/Account/Singin/”, it ignores it and continue redirecting to the default “/Account/Login/”. Any idea why and how to fix it?


    1. Try this:

      services.ConfigureApplicationCookie(options => options.LoginPath = "/Account/Signin");


  3. What advantages do you feel 2FA with QR Code has over 2FA with sms/email? Also, most of the applications have 2FA with sms, so do you feel 2FA with QR Code is a game changer and many are going to follow suit?


    1. The point is not about using QRCode, it is about how they will authenticate and how safe it is. This approach is preventing attacks like SIM swapping. I would say the usage of Authenticator applications such as Microsoft or Google Authenticators is going to be dominating the SMS and Email as they are more error prone.


Leave a Reply