00:00 So now we want to actually verify that a user owns the e-mail address before we allow them to sign up. The easiest way for us to walk through this is to walk through a flow diagram. So here we have the user, server, and verification and e-mail client. The user is going to come to our sign-up form, they're going to submit their e-mail address.

00:18 Then the server is going to say, okay, you want to sign up for an account with this e-mail address. So I'm going to create a verification that's going to have some special and secret information. Then I'm going to use that to create a redirect URL that's going to tell the user that they need to go and check their e-mail address,

00:38 and also provide them a input wherein they can enter a secret code that can only be generated if you have that secret information in the verification. So I'm going to redirect the user over to that verify URL, but I'm also going to send a code to their e-mail address that they provided for me.

00:58 That code is only possible to be generated by this verification. It's a time-based one-time password, T-O-T-P. What that means is that the password is only valid for a certain period of time.

01:16 This is the sort of thing that you get with a one-time password or Google Authenticator, or those one-time password generators. Those will roll over every 30 seconds. For an e-mail verification, that's totally not going to work. Some e-mails take longer than 30 seconds,

01:33 which is silly, but that's the world we live in. So what we do here is we set the period to be for 10 minutes, or 30 minutes, or something like that to give the user some time. But we don't store the code itself as part of the verification.

01:50 We store the secret for generating and verifying those codes. So we send the code over to the e-mail client. The user will check their e-mail clients and get that code that we sent to them, that will be valid for 10 minutes, and then they submit the code. Then the server will verify that code with the verification.

02:09 If it is correct, if it's valid, then it will redirect the user with a cookie that has been signed. It doesn't matter whether it's decodable, because the user is the one who submitted the e-mail. But by signing it,

02:25 we ensure that whatever contents of that cookie there are, we can verify we were the one who created it. So once we have verified that the user does have ownership of the e-mail, we can stick that e-mail in their cookie, and then they can go through the onboarding process,

02:43 but they don't submit their e-mail again as part of the onboarding process. We get that out of the cookie. So that way, we have a special verification cookie, a place where we put stuff that is going to be useful for the verification process for a user including the onboarding e-mail that they already verified.

03:02 So then the user can fill out the rest of the form for onboarding and we can create their account from there. So that's the verification flow. That's how all of this is going to work, and you're going to be building all of that stuff. It's going to be pretty fun. So one thing I want to mention about this is rate limiting.

03:20 So the thing is that the code that we sent to the user is only six digits long. So I mean, there are a lot of possible codes there. What is that? 999,999 possible codes. So a computer has no problem just submitting a bunch of those,

03:40 and they have a 50 percent chance of getting it halfway through. So the pretty good chance if they happen to know that somebody is trying to sign up, that they could just make a bunch of requests and try to get it. In fact, they could just say, hey, I want to sign up with this account,

03:59 president at whitehouse.gov, and then they start making a bunch of requests to try and guess whatever code we sent to the president. So that's why rate limiting is so important. So we actually implemented that already, and so this will not be feasible.

04:15 It is very unlikely that a user or a adversary would be able to guess the password. Because of the rate limiting we have set up for our app, and we can just add verify to the paths that are rate limited very specifically,

04:33 and then we have less of a problem there. So I think that's everything that you need to know about this verification flow. We will be using this to verify the user's e-mail, but it's a very similar flow to verify two-factor auth code, which we'll be doing a little bit later.

04:51 We'll use the same flow for resetting the user's password as well and changing the user's e-mail. All of this stuff is useful, and so the verification process will work for all of those things using time-based one-time passwords. So have a good time with that,

05:08 and yeah, we'll see you in the exercises.