There are many ways to do authentication in ASP.NET Core 2.0, and it is sometimes hard to figure out how to set it up. This course aims to simplify that by providing walk throughs of setting up different kinds of authentication and authorization.
ASP.NET Core 2.0 has changed the way you add authentication and authorization to your applications, and it can be a bit hard to figure out how to do it. This course, ASP.NET Core 2 Authentication Playbook, tries to make this easier by showing you step by step walkthroughs of how you set it up. You will learn how to set up several different kinds of authentication, ranging from local logins to Azure AD. You will also get to see how you can add authorization to your application to make sure that you not only know who the user is, but also can control what he or she is allowed to do. Finally, we will cover using social identity providers like Facebook and Twitter, and the process of letting 3rd party identity providers handle the problems involved in storing user credentials. Each module is aimed to be self contained, and show one particular thing, making it easy to figure out what parts you want to explore. By the end of this course you’ll learn everything you need to know to authenticate and authorize users for your ASP.NET Core applications.
Course Overview Hi everyone. My name is Chris Klug, and welcome to my course ASP. NET Core 2. 0 Identity Management Playbook. Setting up authentication is something that most of us need to do on a semi-regular basis, but it's generally not something we do every day. So I think a lot of us tend to forget how to go about doing it. This course will walk you through setting up authentication in ASP. NET Core 2. 0 using a variety of different authentication providers. It will also cover how you can do authorization since authentication is rarely used without some form of authorization as well. Some of the major topics that we will cover include authenticating users using local logins, making sure that we can use their own custom authentication if we want to do that; using social identity providers like Facebook and Twitter, letting third party identity providers handle the problems involved in storing user credentials; integrating with Azure AD, allowing businesses to control authentication and authorization across the entire company in an easy way; and setting up authorization, making sure that once we know who the user is we can control what he or she is allowed to do. By the end of this course, you will know everything you need to know to authenticate and authorize users for your ASP. NET Core applications. Before beginning this course, you should be familiar with ASP. NET Core MVC and have a basic understanding of authentication and authorization. I hope you'll join me on this journey to learn about authentication with the ASP. NET Core 2. 0 Identity Management Playbook course at Pluralsight.
Using Local Logins Even though social identity providers and centralized authentication systems are becoming more and more common, using local logins is still a very common practice especially when it comes to line-of-business apps and internal systems. So I felt like this would be a good starting point for this course. But what does it mean for us developers to use local logins? Well, first off, we need some form of user store or service where we can store our user's credentials. Then we need a sign-in form where the users can sign in. And if we want the users to be allowed to create new accounts, we need a sign-up form as well. And if we allow the users to sign in to our application, we probably need to give them a way to sign out. And, finally, after the user has signed in we need to create an authenticated session with the user. This is done by issuing a secure cookie with the user's authentication information. That cookie is then passed to the server on every request and used to create an authenticated user context. But let's skip the slides and head over to Visual Studio to see how to set this whole thing up.
Using Social Logins More and more systems are moving towards outsourcing their authentication using social identity providers like Twitter, Facebook, Microsoft, and Google. This means that we developers can ignore the hassles and dangers of storing our users' credentials, and instead let someone else handle that while we focus on giving value to our users. But what is really included in setting up an application to use a social identity provider like Facebook? Well, first of all we need to register the application with the provider. We need to let them know that our application intends to rely on them to perform the authentication of our users. Then we need to set up our application to redirect our users to the identity provider with the correct information and also handle the returned authentication token when they come back to our application. Luckily this flow is mostly standardized now, and most providers use either OAuth or OpenID Connect. And once the user has been authenticated, we need to turn that authentication into a locally authenticated cookie-based authentication session. And finally, if we're going to let users sign in to our application, we should probably give them a way to sign out as well. However, most of these steps are actually handled for us by the system. All we need to do is to configure the system with the correct values. So let's go ahead and have a look at what that looks like.
Supporting Multiple Social Login Providers In the previous module, we made it possible for users to sign into our application using a single social login provider, in this case, Facebook. But very often you want to give the users the ability to choose what provider they want to use instead of just offering a single one, so in this module we'll have a look at how we can support more than one social login provider, and we'll do that by adding Twitter authentication to the application from the previous module. So yeah, this module actually builds on top of the previous module. Even if the goal is to make each module stand alone, having to repeat all the code from the previous module just felt unnecessary. So if you haven't seen that module yet, I suggest going back and having a look at that before you go ahead and look at this one. So, what do we need to do to add another identity provider? Well, just as with the previous module, we have to register our application with a provider and handle the OAuth and OpenID Connect redirects and callbacks, but we also need to give the user a view where he or she can select which one of the available providers should be used. So let's go ahead and add Twitter support to our application.
Requesting Extra User Information While Using Social Logins Social logins are awesome. They remove pretty much all of the problems caused by storing our user's credentials on their own. But very often you realize that you actually need more information about the user than the claims provided by the identity provider gives you, and the solution to that is to add an extra step to the signup flow and collect that extra information that's needed, so that's what we'll be looking at in this module. And just as with the previous module, this one builds on top of the code that we wrote in the previous two modules, so if you haven't seen those, I suggest you go back and do that and then come back and watch this; otherwise, it might get a bit hard to follow along. So, how does setting up that extra signup step work? Well, first of all, we need to have the user signing in using a temporary sign-in before they're let into the system, so that means an extra cookie needs to be handled. Then we need to create some form of user information store where we can store the provided information using the value of the identity provider's name identifier claim as the key. And to collect that extra information, we need to create a form for the user to fill out during signup. And finally, we need to convert that temporary session into a real session when the information has been collected. So let's go ahead and see what that looks like.
Authenticating Users Using Azure AD When it comes to authenticating users online, using local logins or social identity providers is nice and easy, but often companies like to store their users in an Active Directory and prefer to have applications integrate with that instead of building something custom. So in this module, we'll have a look at how we can support that scenario using Azure Active Directory. If you want to use an on-premise Active Directory instead, the integration should be pretty much identical as long as your AD supports ADFS 2016. So let's have a look at what we'll be doing in this module. The first thing we need to do is to set up an Active Directory tenant in Azure and some users. This step is obviously only relevant if you're starting out with a new AD. If you already have one in place, you can just go ahead and skip this, of course. Then we need to register the application in the AD, telling it that this application should be allowed to use the AD to authenticate users. And when the AD is up and running and configured, we need to set up our application to do the right open ID connect redirects, as well as handle the authentication token when the user comes back from having been authenticated. And once we have the authentication token, that needs to be turned into a local cookie-based authentication session. And finally, we need to give the user a way to sign out as well, and not just sign out from the local cookie-based authentication. We need to make sure that we sign out the user from any session that the AD might have with the user as well. But let's not spend any more time talking about it. Let's just head over to the Azure portal and set up a new AD.
Authenticating Users Using OpenID Connect and IdentityServer Outsourcing our authentication needs to third-party providers is great, but sometimes there are reasons for not doing this, and at those times setting up your own standards compliant identity provider is a really good alternative to rolling your own solution. But building one of those is hard, very hard, but you don't have to because someone else already has. It's called IdentityServer and is an open source identity provider that supports a lot of different authentication scenarios. So in this module, we'll look at how we can use IdentityServer to authenticate our users using OpenId Connect. However, I do want to mention that this is not a course about IdentityServer, so the part about setting that up is fairly basic. But let's have a look at what's involved in setting up a solution like this. The first thing we need to do is install IdentityServer, it can either run as part of your application or stand alone. I prefer having it as a standalone application, as it makes it easier to integrate more applications with it in the future. And then we need to configure the IdentityServer to our needs. It supports a lot of scenarios, so we need to tune it to what we need. Then we need to change our focus to our application and set up the correct OpenId Connect redirect and callbacks. And once the user has been authenticated, we need to set up a cookie-based local authentication session. The IdentityServer only authenticates the user, keeping him or her signed in is up to us and is done using a cookie-based solution. And finally, we need to give the user a way to sign out as well. In this case, we need to make sure that we sign out the user not only from the local cookie-based session, but also from any current session that he or she has with the IdentityServer. But that's enough talk, let's just go ahead and get started.
Doing Claims Transformation Sometimes we have more claims for a user than we want to put in an authentication cookie. Or we might have claims that change extremely frequently making storing them in a cookie less than perfect. Or we might have some other reason why we don't want to store all the user's claims in the authentication cookie. By the way, we can use claims transformation to modify the user's claims on incoming requests. This allows us to store a minimal amount of information in the authentication cookie, and add the rest as the request comes into the server, and that's what we're going to be looking at in this module. But before we get started, I just want to mention that this module uses the application that was set up in the module Using Local Logins, so it might be a good idea to have a look at that first, but if you feel comfortable with cookie authentication in ASP. Net Core, you probably don't need to. And with that disclaimer out of the way, let's have a look at what we need to do to get claims transformation going. So first of all, we need some form of authentication in our application, and in most cases, that will be cookie authentication. And then we need some form of user profile service or repository where we can get hold of the claims we want to add to the user context. And once we have a way to get hold of the user information we need, we can go ahead and create a claims transformation service that will be responsible for doing the actual transformation of the user's claims. And finally, we need to add that service to the dependency injection so that the ASP. NET Core authentication system can find it. And that's actually it, so let's have a look at the code for that.