Okay.
Welcome to section nine.
And in this section we're going to cover identity.
We're going to set up authentication and authorization in our application and allow the users to log
in and register of course.
So coming up in this section then we're going to take a look at setting up ASP.Net identity, something
that has been made a lot more simple than it used to be since about dotnet eight, not surprisingly,
integrates very well with Entity Framework, and it's going to provide the set of tables that we need
to manage our users, our roles, and our claims in our application.
We're also going to take a look at forms in react.
We haven't done much with forms yet, but now we're going to start to look at things like logging in
and registering.
We're going to need to take more information from the user, and the way that we do that is to use forms,
of course, and we don't want to stick with just using react for that, because the code that we write
becomes very verbose very quickly.
So we're going to use a package to help us.
The most popular way to do this just now is to use react hook forms.
So that's what we'll implement.
And we're also going to take a look at form validation as well, so that we can stop the user from sending
a network request to our API if they haven't provided the information that we're looking for of course.
So what is ASP.Net identity.
And there's that term ASP again.
And just a reminder that stands for Active Server pages which no longer exist.
But the branding has.
And Microsoft just continued to use it to identify web based aspects of.
Net.
So what is it then?
Well, it's a membership system for.
Net and it provides us a number of different features to help us manage users in our application.
And because our users are going to log in with a password, we need to be able to compare their password.
But we don't want to store their password in clear text.
So when a user does register with a password, then we'll send up the password as a string of text over
Https, of course.
But when it gets to our server and we need to store that in a database, then it's going to be hashed.
And hashing is a one way operation.
And the hash version of that is going to be stored in our database.
And it's going to be salted as well.
So if everybody in our application used the same password of let me in, everybody would have a different
hash stored in the database.
So it makes it that little bit harder.
If our database was compromised for the evil hacker to work out what that password would be.
Not impossible, of course, but it would slow them down.
So then we need to be able to validate that password.
So again, as a user logs in and provides their password they send up the password.
But then that password is hashed using the same algorithm that was hashed the first time for that user.
And then it's compared against the hashed value that's stored in the database.
And if they match, of course, we let them proceed to the next step.
ASP.Net identity also handles user storage.
And as mentioned, we're going to be using the Entity Framework integration for this.
So when we implement this with not too many lines of code, by the way, we're going to have another
six tables in our database all to deal with handling users in our application.
And we also get roles with this.
So if we want an admin user that can only do admin related things, then we have that functionality
as well.
And since dotnet eight Microsoft introduced ASP.Net identity endpoints.
And these are really designed for Spars like our react application.
And with just a couple of lines of code, then we get a full identity system configured for us, including
the controller endpoints for all of these different types of request.
So by adding these lines of code, just a few of them.
Then automatically we have effectively an API controller that can handle registering of users logging
in.
The refresh refers to token refresh.
If we were using JWT tokens, which we're not going to, but if we were then we would have a refresh
token endpoint.
Also, we've got endpoints for confirming email and sending confirmation email forgot, password reset,
password managed two factor authentication, manage info and update the user's info as well.
And all of those endpoints are provided for us with just a couple of lines of code.
And Microsoft specifically recommend using this to secure a web API that's in use for single page applications.
So we're going to follow their recommendations and do just that.
So as with any identity system, the one we choose does come with pros and cons.
And there's compromises and benefits to be gained from whichever one you choose to pick.
I've made the choice for this application to go for ASP.Net identity integrated with our application.
And let's just take a look at the pros and cons of this choice.
So the first pro is it's integrated with dotnet.
We've got a.
Net application.
And in my mind it makes sense to simply use a dotnet provided authentication system.
So it's ideal for our application in that respect.
It's also highly customizable and we can create our own custom user stores.
We can create additional claims.
We can extend our user model if we need to take more information than just an email address and password,
then we could do so very easily.
We can also take advantage of its built in features things like password hashing, role based access
control.
It also comes with a secure defaults.
When we use this, we don't need to spend hours upon hours tweaking things to make it secure.
Obviously, with an identity system, you would hope that it comes secure out of the box, and you don't
need to spend hours tweaking it to make it secure.
And it also comes with roll and claims management as well.
So it's very simple for us to integrate a roll based authentication system into our application.
Some of the cons then.
Well, it is tightly coupled with nets.
Of course it's a.
Net system.
So if we did need this to work with other non-microsoft tech stacks then we would need to use something
else.
Also, we might have scalability challenges as the way that we're going to implement this is really
a single server solution where we're coupling this with our web application itself.
And if we did need a multiple server solution or something like single sign on, this would not be suitable.
We'd need to use something like Identity Provider or Keycloak or Auth0.
Any one of those would be a better option for that.
But that's not something that we need to worry about with our application.
And as I mentioned, it's not suitable for distributed apps, anything that's more than a single server,
then this is no good.
We'd need an identity provider at that point.
And this is not that.
And whilst customizable, is a feature of ASP.Net, identity customization can become complex for certain
types of scenarios.
Multi-tenant support custom authentication flows that would be challenging and time consuming.
So at that point we would be looking at a different system for authentication, something like Azure,
something like Keycloak, something like Identity Server.
Any of those would be more suited for that task.
So let's take a look at the identity flow that we're going to implement in our application.
So we start off with our user.
Our user goes to a login form, provides their username and password.
And that information is sent to the API server.
From there the API server is going to validate their password.
And if they get their password correct, then the API server the way that we're going to implement this
is going to issue a cookie to their browser.
That cookie is going to sit inside their browser.
And any time that we make an API request to our web API server, then that cookie is going to be sent
to the server for requests that require authentication and also requests that do not require authentication.
When we're using cookies, it's sent with every request.
So just a few features of cookie authentication.
That's the method that we're going to use.
As I mentioned, it's sent with every single request to the API server whether or not authentication
is required.
It is HTTP only, the cookie that is provided from ASP.Net identity.
There is no access from JavaScript code.
So our react application that we're developing, we cannot access that cookie from our client side code.
Now that in itself does provide some challenges for us, not insurmountable challenges.
But we do need to be aware of that, and we cannot at any point, check the user's browser to see if
they are authenticated.
We need another way to identify from our client side app if they are authenticated.
Also, with regards to cookies, cookies are only available in browsers.
They're not available in mobile apps.
If we did need to support a mobile app, then this system that we are using does provide a way to issue
a token instead of a cookie, but we wouldn't be able to issue a cookie to a mobile app.
But we're not creating a mobile app, so it's not something that I'm concerned about.
And for a single page application, which we are concerned about, then using the approach that I'm
going to demonstrate is Microsoft's recommendation for single page applications, at least ones where
we're integrating identity with the back end API itself.
So that's what's coming up.
And let's begin.