Okay.
Welcome to section nine summary.
And in this section we've taken a look at setting up ASP.Net identity.
And we saw how easy that is to do nowadays a couple of lines of code.
And what we have really is an identity system integrated with Entity Framework on our application.
And we've got the method to log in to register and to issue tokens inside a cookie, which then gets
passed backwards and forwards with every API request to our back end.
And then on our back end, we can check to make sure that the user has that authentication cookie before
we let them proceed to retrieve data or do something from certain endpoints.
We also took a look at forms in react, specifically react hook form.
I think that's the most popular forms solution for react nowadays.
Very popular, very lightweight and very performant in how it's used as well.
And we also took a look at form validation with Zod that allows us to easily validate our client side
fields before we send those requests to the server.
Don't forget similar things that we've looked at in this section we've done on the client side as well
as the API side.
Now, there's no such thing as client side security.
So if you're only going to do one thing, you would do it on the API side.
But obviously for the experience of the user, it's better if we do it on both sides.
But it's not security on the client side, it's only on the API.
The reason being, of course, is the client downloads our full application JavaScript onto or into
their browser, which means they can access all of the code that we're using in our client side application.
That's just a fact.
And that just means there's no client side security as such.
There's only client side hiding of things in the user interface.
So some frequently asked questions then always get asked this is it secure?
Well, yes.
Really.
The cookie that we're sending back is HTTP only, which means it cannot be accessed from JavaScript
code.
We cannot even access it from our own JavaScript application.
So if we can't access it, then malicious JavaScript cannot access it either.
There's just no way to get access to that cookie.
So it also uses the secure flags and samesite flags in the cookie as well.
So as far as the cookie goes, that's as secure as we can make the cookie.
And then we're using pretty much the built in defaults from ASP.Net identity as well.
So there's not much more we can do.
The concern is that we're storing hashed passwords in the database.
So if our database did get compromised then that would be a concern.
And at some future point, if our database did get compromised, then we'd have to assume that the passwords
can be un hashed.
Well, there's no way to un hash something, but there are techniques that hackers can use to eventually
work out what the original password was, but that should give you enough time to notify the users that
their passwords have been compromised.
And that's really the only major risk inside our application.
So if you wanted to mitigate that risk, then you would really look at removing the authentication side
and use a storage side from our application itself and using a third party identity provider.
And what do big companies use for their authentication system?
Do they use ASP.Net identity?
Well, it's highly unlikely because this is really designed the way that we're using it just to secure
a web API for a single page application, and it's really just a single server solution.
It doesn't cover things like single sign on, and it doesn't rely on the standards like OAuth 2.0 and
OpenID connect, which big companies would rely on, and they would typically use identity providers
like Azure, AD, Ping Identity, Okta, to name a few of them for handling authentication and token
management for their applications.
And it also provides things like single sign on as well.
And depending on the size of the business, maybe they've got custom built systems for internal use
as well.
But in our scenario, if we wanted to go to the next level up, then we would use something like Azure
AD or any OAuth 2.0 identity provider.
But we're not covering that on this training course.
We're just making a self-contained application that covers everything, including identity, on our
single server based application.
So coming up next, then now we've got our identity in place.
It's really time that we started to take a look at payments.
And we'll take a look at that next.