WEBVTT 00:00.000 --> 00:00.270 Okay. 00:00.270 --> 00:02.010 Welcome to section nine summary. 00:02.010 --> 00:07.410 And in this section we've taken a look at setting up ASP.Net identity. 00:07.410 --> 00:12.180 And we saw how easy that is to do nowadays a couple of lines of code. 00:12.180 --> 00:19.200 And what we have really is an identity system integrated with Entity Framework on our application. 00:19.200 --> 00:24.900 And we've got the method to log in to register and to issue tokens inside a cookie, which then gets 00:24.900 --> 00:29.430 passed backwards and forwards with every API request to our back end. 00:29.430 --> 00:34.680 And then on our back end, we can check to make sure that the user has that authentication cookie before 00:34.680 --> 00:40.830 we let them proceed to retrieve data or do something from certain endpoints. 00:40.860 --> 00:44.760 We also took a look at forms in react, specifically react hook form. 00:44.760 --> 00:48.600 I think that's the most popular forms solution for react nowadays. 00:48.600 --> 00:54.570 Very popular, very lightweight and very performant in how it's used as well. 00:54.570 --> 01:00.930 And we also took a look at form validation with Zod that allows us to easily validate our client side 01:00.930 --> 01:03.690 fields before we send those requests to the server. 01:03.720 --> 01:08.570 Don't forget similar things that we've looked at in this section we've done on the client side as well 01:08.570 --> 01:09.740 as the API side. 01:09.770 --> 01:12.470 Now, there's no such thing as client side security. 01:12.500 --> 01:16.670 So if you're only going to do one thing, you would do it on the API side. 01:16.700 --> 01:20.810 But obviously for the experience of the user, it's better if we do it on both sides. 01:20.810 --> 01:24.500 But it's not security on the client side, it's only on the API. 01:24.530 --> 01:31.700 The reason being, of course, is the client downloads our full application JavaScript onto or into 01:31.700 --> 01:37.430 their browser, which means they can access all of the code that we're using in our client side application. 01:37.430 --> 01:38.420 That's just a fact. 01:38.420 --> 01:41.360 And that just means there's no client side security as such. 01:41.390 --> 01:45.320 There's only client side hiding of things in the user interface. 01:45.320 --> 01:50.030 So some frequently asked questions then always get asked this is it secure? 01:50.060 --> 01:50.960 Well, yes. 01:50.960 --> 01:51.380 Really. 01:51.380 --> 01:57.020 The cookie that we're sending back is HTTP only, which means it cannot be accessed from JavaScript 01:57.020 --> 01:57.320 code. 01:57.320 --> 02:01.340 We cannot even access it from our own JavaScript application. 02:01.340 --> 02:05.810 So if we can't access it, then malicious JavaScript cannot access it either. 02:05.840 --> 02:08.270 There's just no way to get access to that cookie. 02:08.300 --> 02:14.270 So it also uses the secure flags and samesite flags in the cookie as well. 02:14.270 --> 02:17.510 So as far as the cookie goes, that's as secure as we can make the cookie. 02:17.510 --> 02:21.770 And then we're using pretty much the built in defaults from ASP.Net identity as well. 02:21.770 --> 02:23.570 So there's not much more we can do. 02:23.600 --> 02:27.320 The concern is that we're storing hashed passwords in the database. 02:27.320 --> 02:31.340 So if our database did get compromised then that would be a concern. 02:31.340 --> 02:38.000 And at some future point, if our database did get compromised, then we'd have to assume that the passwords 02:38.000 --> 02:40.040 can be un hashed. 02:40.040 --> 02:45.380 Well, there's no way to un hash something, but there are techniques that hackers can use to eventually 02:45.380 --> 02:50.420 work out what the original password was, but that should give you enough time to notify the users that 02:50.420 --> 02:52.580 their passwords have been compromised. 02:52.580 --> 02:56.930 And that's really the only major risk inside our application. 02:56.930 --> 03:04.730 So if you wanted to mitigate that risk, then you would really look at removing the authentication side 03:04.730 --> 03:10.820 and use a storage side from our application itself and using a third party identity provider. 03:10.940 --> 03:14.930 And what do big companies use for their authentication system? 03:14.930 --> 03:17.000 Do they use ASP.Net identity? 03:17.030 --> 03:21.220 Well, it's highly unlikely because this is really designed the way that we're using it just to secure 03:21.220 --> 03:25.870 a web API for a single page application, and it's really just a single server solution. 03:25.870 --> 03:31.630 It doesn't cover things like single sign on, and it doesn't rely on the standards like OAuth 2.0 and 03:31.630 --> 03:37.570 OpenID connect, which big companies would rely on, and they would typically use identity providers 03:37.570 --> 03:45.670 like Azure, AD, Ping Identity, Okta, to name a few of them for handling authentication and token 03:45.670 --> 03:48.340 management for their applications. 03:48.400 --> 03:53.320 And it also provides things like single sign on as well. 03:53.350 --> 03:57.760 And depending on the size of the business, maybe they've got custom built systems for internal use 03:57.760 --> 03:59.110 as well. 03:59.440 --> 04:04.090 But in our scenario, if we wanted to go to the next level up, then we would use something like Azure 04:04.120 --> 04:08.500 AD or any OAuth 2.0 identity provider. 04:08.500 --> 04:10.960 But we're not covering that on this training course. 04:10.960 --> 04:16.810 We're just making a self-contained application that covers everything, including identity, on our 04:16.810 --> 04:19.570 single server based application. 04:19.570 --> 04:22.480 So coming up next, then now we've got our identity in place. 04:22.480 --> 04:25.000 It's really time that we started to take a look at payments. 04:25.000 --> 04:27.190 And we'll take a look at that next.