We've just updated our To Do List database to store Identity data. Let's pause for a second to check out the changes in MySQL Workbench. Or, check out the contents of the most recent migration file, which should be called something similar to
20230102230735_AddIdentity.cs and be located in the
ToDoList/Migrations/ directory. We'll see many new tables created for Identity-related data! What we're seeing here is Identity's model.
Each table focuses on different data that Identity uses to track its users, roles, claims, logins, and tokens:
aspnetuserscorresponds to the
aspnetrolescorresponds to the
aspnetroleclaimscorresponds to the
aspnetuserclaimscorresponds to the
aspnetuserloginscorresponds to the
aspnetuserrolescorresponds to the
aspnetusertokenscorresponds to the
We only have an
ApplicationUser : IdentityUser model explicitly in our To Do list app. We also haven't updated our
ToDoListContext with the above entities either! So how do these entities get added to our database? It happens implicitly so long as we've configured Identity to work with EF Core and our To Do List database context! (Of course, we still need to create a migration and update the database.)
In fact, we only created the
ApplicationUser model in our application so that we have the option to customize it with custom user data.
Because all of the Identity entities are added to our database implicitly, the docs make sure to clearly explain the Identity model and the purpose of each. First, check our the following table from the MS docs that explains each entity type:
While the table does a good job listing what each entity represents, some of these could use more explanation.
Let's start with user. A user is someone who uses our website. They've created an account and their user information is saved and managed with Identity. We'll ask our users to provide their email and password to create a unique user account. Then when users log in, they will provide their email and password, and Identity will use that information in order to verify the user's identity.
A role is a category, like "manager" or "admin", that we can give to certain users. We can then set up different permissions (using authorization) for each role, which will determine what that role can do in our website. The user role model is meant to associate users with roles.
A claim is a name-value pair that represents who a user is. Claims can be created from any user or identity data, and this data can be issued from ASP.NET Core identity or another trusted identity provider. There's a model for both user claim and role claim, which means we can create claims based on user data or role data. We won't be creating claims, but letting Identity generate claims instead.
A user login is the model that tracks users with logins using third-party providers, like Google or Facebook.
A user token is the model that associates a token with a user for token-based authentication.
We won't be creating or managing roles, claims, logins, or tokens in the simple implementation of authentication that we'll add to our To Do List app. We'll stick to creating users, and using email and password credentials to authenticate. This means that we'll only end up using the
aspnetusers table in our database, which corresponds to the
ApplicationUser class in our To Do List models.
There are further exploration opportunities to implement other authentication schemes that do end up using the other tables in our database. An authentication scheme is a method of authentication. For example, Identity, cookies, and JWT Bearer are all different authentication schemes we can use in ASP.NET Core apps. To learn more about further exploration opportunities, visit the lesson Further Exploration with Identity.
It's also helpful to take a look at the relationships between each Identity entity. The MS docs has a handy list that clearly explains the relationships in the Identity model:
Again, we'll only be using the
Users model — the
ApplicationUser model in our To Do List app.
Identity is responsible for providing a
ClaimsPrinciple when a user logs in to our To Do List website. The
ClaimsPrinciple contains information about the user's claim, their identity as verified by ASP.NET Core Identity.
ClaimsPrinciple is just one class of many within the
System.Security.Claims namespace. This namespace has other classes that describe claims in general. As we'll see when we update our views and controllers, we'll access certain class properties and methods from the
System.Security.Claims namespace (among others) in order to determine a few things:
ApplicationUserobject for the logged in user? We will need the
ApplicationUserobject when we want to associate To Do List models (like
Category) with a specific user.
The namespaces and classes that support authentication in ASP.NET Core applications can be overwhelming to navigate and understand. That's because there are many different authentication schemes that we can implement in our ASP.NET Core applications. It's not so important to understand the classes or namespaces, but instead the tools and concepts that impact our To Do List application:
aspnetuserstable in our To Do List database to save user data, like their email and password. The
aspnetuserstable corresponds to the
ApplicationUsermodel in our project.
ClaimsPrinciplefor the user, which contains a claim about the user's identity as verified by ASP.NET Core Identity.
ClaimsPrinciplethat Identity generates to get information about the logged in user in order to conditionally display information in our website, or associate our To Do List models (like
Category) with specific users.