1 00:00:00,000 --> 00:00:01,000 [Maximilian Schwarzmuller] So we got 2 00:00:01,000 --> 00:00:04,000 that user signup implemented, but as mentioned, 3 00:00:04,000 --> 00:00:09,000 that isn't really the authentication process yet. 4 00:00:09,000 --> 00:00:12,000 Instead, we want to make sure that users, for example, 5 00:00:12,000 --> 00:00:16,000 can't visit /training if they didn't just log in, 6 00:00:16,000 --> 00:00:19,000 so if they're not authorized. 7 00:00:19,000 --> 00:00:22,000 And therefore we need to answer one important question, 8 00:00:22,000 --> 00:00:26,000 how exactly does authentication work? 9 00:00:26,000 --> 00:00:29,000 What do we have to do as a next step? 10 00:00:30,000 --> 00:00:35,000 Well, in the end, authentication is a two part process, 11 00:00:35,000 --> 00:00:39,000 and the first part is that we must be able to log users in, 12 00:00:40,000 --> 00:00:44,000 which in the end means that we wanna be able to verify 13 00:00:44,000 --> 00:00:47,000 user credentials, email and password, 14 00:00:47,000 --> 00:00:48,000 check if they're valid, 15 00:00:48,000 --> 00:00:50,000 if they match the ones that were used 16 00:00:50,000 --> 00:00:53,000 during account creation and, 17 00:00:53,000 --> 00:00:55,000 and that's very important, 18 00:00:55,000 --> 00:00:57,000 we want to then mark a user 19 00:00:57,000 --> 00:01:02,000 who did provide valid credentials as authenticated. 20 00:01:02,000 --> 00:01:05,000 We need some way of remembering 21 00:01:05,000 --> 00:01:10,000 that this user who just sent this request is authenticated 22 00:01:10,000 --> 00:01:14,000 and should be granted access to protected resources, 23 00:01:14,000 --> 00:01:17,000 because that's the second part, 24 00:01:17,000 --> 00:01:21,000 that we have certain resources that should be protected 25 00:01:21,000 --> 00:01:24,000 and that should only be made accessible 26 00:01:24,000 --> 00:01:28,000 to authenticated users, to users who logged in 27 00:01:28,000 --> 00:01:31,000 and who are marked as authenticated. 28 00:01:32,000 --> 00:01:34,000 Now let's start with that first part, 29 00:01:34,000 --> 00:01:39,000 logging users in and marking them as authenticated. 30 00:01:39,000 --> 00:01:44,000 It all starts with a client, a user visiting our website, 31 00:01:44,000 --> 00:01:47,000 who in the end sends a request to our server, 32 00:01:47,000 --> 00:01:52,000 a request where they filled out that authentication form 33 00:01:52,000 --> 00:01:54,000 to either create a new user 34 00:01:54,000 --> 00:01:57,000 or to log in with an existing user 35 00:01:57,000 --> 00:01:59,000 and either way, they send some credentials 36 00:01:59,000 --> 00:02:03,000 along with that request, because they submitted that form. 37 00:02:03,000 --> 00:02:07,000 So they sent an email and a password to the server. 38 00:02:07,000 --> 00:02:10,000 On that server, we then verify those credentials, 39 00:02:10,000 --> 00:02:13,000 either because we just create a new user 40 00:02:13,000 --> 00:02:16,000 and we check whether we have a valid email, 41 00:02:16,000 --> 00:02:19,000 a valid password and the user doesn't exist yet 42 00:02:19,000 --> 00:02:22,000 or because the user tried to log in, 43 00:02:22,000 --> 00:02:24,000 we take a look at the existing users 44 00:02:24,000 --> 00:02:26,000 that we stored in the database 45 00:02:26,000 --> 00:02:27,000 and we check 46 00:02:27,000 --> 00:02:29,000 whether that email password combination 47 00:02:29,000 --> 00:02:32,000 that was submitted is valid. 48 00:02:33,000 --> 00:02:36,000 If we consider it valid, so if we determine 49 00:02:36,000 --> 00:02:39,000 that the user did provide correct credentials, 50 00:02:39,000 --> 00:02:43,000 we create a so-called authentication session, 51 00:02:43,000 --> 00:02:46,000 which in the end is simply a database entry 52 00:02:46,000 --> 00:02:51,000 that's stored in a dedicated table on the server, 53 00:02:51,000 --> 00:02:52,000 that's how we remember 54 00:02:52,000 --> 00:02:56,000 that a certain user is now considered to be authenticated, 55 00:02:56,000 --> 00:02:59,000 we store a new entry in a table. 56 00:03:00,000 --> 00:03:02,000 Now that entry, in a table, 57 00:03:02,000 --> 00:03:07,000 will in the end have an ID, a so-called session ID, 58 00:03:07,000 --> 00:03:10,000 and we then send back that ID, 59 00:03:10,000 --> 00:03:13,000 typically in a cookie, to the user. 60 00:03:13,000 --> 00:03:16,000 So the response to that authentication request, 61 00:03:16,000 --> 00:03:18,000 to that login request, 62 00:03:18,000 --> 00:03:20,000 contains such, a session cookie, 63 00:03:20,000 --> 00:03:23,000 a cookie with such a session ID, 64 00:03:23,000 --> 00:03:25,000 if the credentials were valid 65 00:03:27,000 --> 00:03:31,000 and the client, the browser, will then automatically store 66 00:03:31,000 --> 00:03:35,000 that session cookie, that's the first part. 67 00:03:36,000 --> 00:03:38,000 Now that we have this cookie, 68 00:03:38,000 --> 00:03:40,000 and now that we remembered on the server 69 00:03:40,000 --> 00:03:44,000 that this user is considered to be authenticated, 70 00:03:44,000 --> 00:03:46,000 we can move on to the second part, 71 00:03:46,000 --> 00:03:49,000 which is about accessing protected resources. 72 00:03:50,000 --> 00:03:53,000 Because let's now say a user who just logged in 73 00:03:53,000 --> 00:03:56,000 and who has that cookie now sends a request 74 00:03:56,000 --> 00:04:00,000 to some route that should be protected 75 00:04:00,000 --> 00:04:03,000 and we'll write some code that will protect the route, 76 00:04:03,000 --> 00:04:06,000 and you will see how that works in that section. 77 00:04:07,000 --> 00:04:09,000 What's important about that request 78 00:04:09,000 --> 00:04:14,000 is that the browser will automatically add cookies 79 00:04:14,000 --> 00:04:18,000 that belong to our website to those requests, 80 00:04:18,000 --> 00:04:22,000 so that session cookie will automatically be attached 81 00:04:22,000 --> 00:04:25,000 to that request and will be sent to the server. 82 00:04:26,000 --> 00:04:28,000 On the server, we can then take a look 83 00:04:28,000 --> 00:04:32,000 at that session cookie and verify its validity. 84 00:04:32,000 --> 00:04:35,000 So if it in the end contains a session ID, 85 00:04:35,000 --> 00:04:40,000 we also have in our database, if it's a valid session id. 86 00:04:40,000 --> 00:04:42,000 And therefore those session IDs 87 00:04:42,000 --> 00:04:45,000 also aren't just some kind of numbers, 88 00:04:45,000 --> 00:04:48,000 but instead more complex strings 89 00:04:48,000 --> 00:04:50,000 that can't be easily made up. 90 00:04:52,000 --> 00:04:54,000 Now, once we determined that we got a request 91 00:04:54,000 --> 00:04:58,000 with a valid active session cookie, 92 00:04:58,000 --> 00:05:01,000 we sent back the requested resource. 93 00:05:01,000 --> 00:05:05,000 So for example, the page content the user wanted to see, 94 00:05:05,000 --> 00:05:07,000 or if the cookie doesn't look all right, 95 00:05:07,000 --> 00:05:10,000 if the session expired or something like that, 96 00:05:10,000 --> 00:05:12,000 we send back an error, 97 00:05:13,000 --> 00:05:16,000 that's in the end how authentication works 98 00:05:16,000 --> 00:05:19,000 and that's what we'll now implement over the next lectures.