ASP.NET Identity 2 Fundamentals - ablealias/asp.net GitHub Wiki

ASP.NET Identity 2 Fundamentals

ASP.NET Identity is a modern user management library for ASP.NET, replacing the previous ASP.NET membership and simple membership libraries. This course will teach you the basics of claims-based identity, how the ASP.NET Identity library works, and how to integrate the library with an ASP.NET application. And it offers a wide range of functionality along with integration with modern security frameworks.

Introduction to ASP.NET Identity and Claims Based Identity

Before we begin, we need to cover off some of the core concepts that ASP.NET Identity implements and clarify some of the key phrases that will be used throughout this course. The first one is identity. So a user within a system has two different kinds of data, identity data and application data. Identity is all about who the user is and what they are, such as name, email address, and date of birth. Much of this data would typically be the same for a user, no matter what application they are in. Also, an identity does not necessarily need to be issued by your own application. For instance, if you allow users to login using an external identity provider, such as Google or Facebook, it will be their systems sending you the user's identity. Application data, on the other hand, is always specific to an individual application. This will be data such as a user's permissions within that application, their usage data and their saved documents. So what is part of a user's identity? Identity can be data that a user users to authenticate, such as their username and password or information about the external identity provider they used to authenticate, such as open ID. Identity can also be personal information, such as their given name, date of birth, email address, and telephone number. And finally, what the user is can also be part of their identity. This will be information such as their role within an organization.

The next concept is claims based identity. Claims are how we represent identity data within our application. For instance, I would have a claim with a type of first name and a value of scott. When we refer to a claim, we are talking about a single piece of a user's identity. These claims are issued by an identity provider, which could be your own application or an external identity provider such as Google, and by trusting the identity provider we trust the claims it issues about the user. This concept plays a big part when using external identity providers and federation services. And the final thing I want to cover before we start is the different layers where identity is used. The first place is the identity management layer. This is purely where the identity data is stored and accessed. This can include functionality, such as registration and password verification. Next is authentication. The process of verifying a user, of verifying who they are. An example of this is logging into a system using a username and password. The authentication process will typically use the identity management layer, creating a claims based identity within the application upon successful authentication. The final part is authorization, which is the process of verifying what a user is allowed to do. For example, are they allowed to access the resource they are requesting? Authorization typically requires the request to have first been authenticated so that it can use a user's claims to look up who is making the request and then look up what their permissions are.

ASP.NET Identity

So what is ASP.NET Identity? Well there's a clue in the name, it's all about the identity of your users. And to be specific, it's concerned with the storage and management of those identities. It is implemented in your identity management layer and is otherwise known as an identity store or user store. An identity store is different from your usual database in that it is only concerned with identity data. No application data allowed. This allows it to serve identities to multiple applications or to a central authentication service. As an identity management library we get access to functionality such as password hashing, which allows the secure storage of passwords; user lockout, which provides us with some protection against brute force attacks; two factor authentication, which allows us to add extra steps to authentication besides the conventional username and single password. There's also support for external logins, which allows us to associate locally stored identity information with that sent by an external identity provider such as Google; and tokenization, which allows us to create and verify tokens used to reset or confirm identity information such as password and email respectively. And if you don't like any of the default implementations in the library, you can just swap them out. ASP.NET Identity is highly extensible, allowing for any of these components to simply be switched out for your own implementation without breaking any other functionality. So if you don't like their password hasher, just swap it out for your own. ASP.NET Identity is all about common functionality found in almost every application that has the concept of users and a login form. That's most modern web applications. Since this is such a common piece of functionality, why implement it yourself over and over again? You could take that one step further. If you are creating a web application that manages finances or dieting, do you really need to dive into the domain of identity storage and management? Or would it be better to let an existing library take care of it for you? Personally I would prefer not to create some of this functionality myself, due to how time consuming it can be and the high risks involved in getting it wrong. I would much rather use a library, such as this, that has been peer reviewed and created by professionals who are paid to this kind of work all day long.