Thoughts about email verification process in web applications

I tried to talk about the title without code or drawing in this article. I thought this is be quite nice and fine topic to talk about.

If we don’t use OAuth(Google, apple login) or even though we have OAuth already in our application, if we want to implement our own signup for particular users, we would have to implement email verification in our web application.

One can ask, why should I?

The typical answer of the question will be like this. It is our obligation to protect our app and future users from the matters that a malicious user abuse other’s email in a bad purpose. But this is not the only reason we should verify emails.

Good users could also possibly do mistake and make a typo in their email when they sign up. And after that if they forget their password, how can we help them? The occasion will be quite difficult to both the user and the app provider.

So we decide to implement email verification for users and ourselves. After we decide to implement email verification, the next question will be this. Should I implement email verification before sign up or after?

Well, this point is I want to talk about this post.

Since I first decide to implement that before signup and change to after, I want to describe my first implementation.

Let’s say we give JWT token after both sign up and email verification.

1. verification before signup

In this case, user is not our member yet even if they did verification. So user don’t have their id value or token.

/email/send-code/:email

so api endpoint for send code is look like this.

Get Wsxcxx’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Then it is very bad now. Any user can possibly be spamming to our endpoint by random email and we need to send spam to random email.

And also we can think about another bad scenario.

Let’s say a user verify email well. But suddenly that user don’t want to sign up. Then we should delete the verified mark in our database. Using TTL(time to live) will be an option of this. But suddenly user decides to sign up our application again within verify mark of TTL.

Now this part is important. Should the user do verification again or they don’t need to verify? My answer is they should do verify process again.

Because we don’t know whether user is the same user who verified their email or not.

Then this also have own problem. We need to depend on client(front-end or mobile) logics. Why do we?

Since verification mark is still alive in our database(or cache or whatever), if someone send api call to our signup endpoint with request body of verified email, they can signup. So we need to prevent the signup button clicked by the user who didn’t complete email verification in client. But it is not good solution, as api endpoint is alway open even though we block the button.

2. verification after sign up

After signup, user who didn’t even verify their email, have their own id because they are our half-member now. I prefer to use uuid for user id instead of auto-increment, since it make hard someone predict next user’s id and it is also easy to shard the data set across multiple database.

So when they want to get code, we can ask them both their uuid and email. So our endpoint which is open, now quite safe from spamming mail to random email. Why it is safe? When the user ask for our code, first we will check their email by uuid or vice versa. If there is no such uuid, we just response with 400 status code and don’t send the email to code.

If you don’t like my idea of only uuid, you can implement access token for only send code, but I thought it is too much.

Of course, a malicious user who sign up with other person’s email also can’t get code, so they can’t get our JWT token. And they also need to do at least sign up before they spamming code to random email.

So we don’t depend on client logic anymore in security perspective . For the users who didn’t verify their email after sign up, all we need to do when they login is redirecting them to the page for code verification.

Thank you for reading my article and have a good day!