ASP.Net Core Identity is too magical. Will rolling authentication ourselves finally catch up to us? There are as many ways to set up authentication as there are to build the application itself. Core Identity is the officially encouraged method of authenticating users in ASP.NET Core. As you might have guessed, we’re not fans of the heavy handed, black box approach needed to make Core Identity “Just work”.
Some responsibilities change with Core Identity out of the picture. We become responsible for validating user credentials which are stored in Redis. ASP.NET continues to handle the messy parts like cookie encryption and determining whether a user is currently authenticated.
Configure Cookie Based Authentication in ASP.NET Core
First, the Authentication Service is configured to support cookie based authorization. This is done when the ASP.NET application starts up:
Log In a User Without ASP.NET Core Identity
We are responsible for authenticating the user’s credentials. Doing it ourselves means we can more easily support different authorization methods without worrying about whether Core Identity supports them:
Read a Signed In User’s Claims
An authenticated user isn’t very interesting if we can’t find out who they are. The User Identity contains all the information supplied when they were originally signed in:
Only Allow Authenticated Users On A Page
There is not much point in having authenticated users if we can’t restrict access to pages. An attribute makes this quick to do in ASP.NET:
The examples above may look like a lot of code, but it is still better than using Core Identity! With any luck, we’ll never have to look at this code again.
Our production environment consists of more than one webserver. If we want to store session data for users, we will need distributed session. Next, we’ll try using Redis as a distributed session store.