Email verification is contentious, it increases friction and adds yet another step to onboarding. However, when done right, email verification can lead to better communication with users, avoid fake accounts / negative externalities, and maintain high marketing reputation.
\nIn this post, we’ll break down why email verification is important and how to implement the right verification flow for your application.
\nThe main reason for adding email verification is to have a direct channel to users.
\nCompany emails aren’t the most exciting topic. I have a stack of AWS marketing emails collecting dust in my inbox. I’m simply not excited about AWS re:Invent or their latest product launch. However, many years ago, I was an avid League of Legends player and whenever new patch notes hit my inbox, I would spend hours reading through every change.
\nCompany content is in the same boat. Creating engaging content is one of the best ways to build a community of users that love your product. Plus, there are plenty of valid use cases for company communication, such as sending billing documents or password reset instructions.
\nEmail verification helps weed out fake accounts. Generally, fake accounts are meant to abuse a certain feature or product of the application. This can lead to rising server costs and skew data analytics. Adding in the additional friction in email verification can be a low-cost way of reducing the risk for product misuse.
\nIn particular, some fake accounts might have real email addresses attached. An attacker could sign up with the email john@fbi.gov or susan@irs.gov. The last thing you want to do is badger John and Susan with company content.
\nAnother reason to add email verification is to prevent attackers from hijacking accounts during automatic account linking.
\nFor example, if a user already has an account using Google Sign-In, an attacker can sign up with the same email on Email-password Sign-In. Most systems today will automatically link the two accounts since they share the same email address and give the attacker access to the original account.
\nTo solve this, the system must first verify the email-password account before linking it to the Google Sign-In account.
\nIf a product is shipped but users don’t discover it, was it really worth it?
\nCompanies can email users to celebrate feature updates, product launches, and case studies. But without proper email verification, companies can end up sending hundreds of emails that hard bounce - the email doesn’t exist.
\nEmail Service Providers (ESPs) don’t take kindly to accounts that see high levels of hard bounces. They automatically assume that the account is a spammer and blacklist the account. That blocks everything from company updates to more vital operations like sending password reset instructions.
\nImplementing a perfect email verification flow is a delicate balance between friction and user verification.
\nThe first question to ask is, “Does universal email verification make sense for my application?”
\nIn some cases, like building a financial application, having every user verify their email is critical. They’re likely already expecting detailed verification and have the patience to take the extra step of hunting through their inbox to complete verification.
\nOn the other hand, more trivial applications like image editing, might not have the same luxury. Most users are looking to access the product as quickly as possible, and throwing up an email verification barrier is bound to result in lower conversions or increased churn.
\nSay we still want to set up email verification - we’ll need to figure out what actions trigger an email verification. We could require email verification as soon as a user signs up, or perhaps when the user comes back for the second session.
\nShifting the onboarding friction from email verification to a later time can make the process much more natural for users. For example, a social media platform can minimize friction during the sign up process so that a user can immediately start to consume content. Later, when the user wants to post content, the platform can verify emails to minimize spam.
\nWe can also segment verification by using conditionals.
\nFor example, if someone is signing up with a gmail.com email, we can be relatively sure that the email is legit. On the other hand, a tmmcv.net email has a high chance of being fake.
\nEither way, it’s critical to define a trigger that will initiate the email verification flow. Once initiated, the flow should tell users that a verification email has been sent and lock features until the user has confirmed the email. If the user has no incentive to verify their email, they’ll simply ignore the verification email.
\nOnce the email verification process starts, the first step is to design a verification token. With SuperTokens, the verification token is a random 128 character string. You can generate any random 64-128 character token. The length prevents brute force attempts from attackers.
\nOnce the token is generated, it’s assigned an expiration time of 24 hours. Unlike password reset or email change functions, email verification is relatively harmless. As a result, some companies may even opt for longer verification times.
\nNow that we’ve done all that, it’s time to send the user an email verification link.
\nAn example of this is:
\n\n\nhttps://example.com/auth/verify-email?token=OTJiN2E5NmZkMGQzMWQ3ZTRhZTkwOGU4MmVmZjZmYjE5ZTQyMmViO
\n
Here is pseudocode for sending a verification email:
\nconst crypto = require('crypto');\n\n/*\n\tFirst, we need to generate a verification token. \n\tWe're using the JSON Web Token library for our example.\n*/\nvar token = crypto.randomBytes(128).toString('hex');\n\n/*\n\tHere, we save the verification token in the db \nto be verified when the token is consumed\n*/\ndb_startTransaction() {\n\tdb_saveNewVerificationToken(userId, token);\n}\n\n/*\n\tNext, we use the token to generate a verification link. \n*/\nconst emailVerificationLink = 'https://example.com/auth/verify-email?token=' + token;\n\nconst mailConfigurations = {\n\tfrom: 'example@example.com',\n\tto: 'user@user.com',\n\t/*\n\t\tThe text and subject can be personalized for your specific use case. \n\t*/\n\tsubject: 'Verify your email to access Example',\n\ttext: emailVerificationLink\n};\n\n/*\n\tWith all that done, it's time to send an verification email to our user\n*/\nsendMail(mailConfigurations);Occasionally, a user might try to request multiple email verifications. Since we have a generous expiration time, we can reuse the previously generated token in the database and send the same link each time the user requests a new email. If the expiration time is up, we can generate a new token and send the new link to the user. Generally, this makes it easier for us to handle email verification logic without having to create and disable multiple verification tokens.
\nOn the other hand, if we wanted to tighten security, we could choose to generate a new verification token, replace the verification token in the database, and send a new email verification link each time. The drawback to this approach is mainly in dealing with previously generated tokens.
\nIn some cases, it makes sense to disable them. However, it could lead to frustrated users. Alternatively, we could keep all tokens enabled and disable all of them whenever one of the tokens is consumed.
\nAfter a user clicks on the verification link, there should be a clear indication for the user that they’ve been email-verified. This can either take the form of a distinct landing page or it could be a pop-up on the home page of the application.
\nOne potential edge case with email verification links is that email clients might open the verification link for scanning purposes and consume the token. To prevent this, we can check if a session exists and if not, redirect the link to a page with a verify button. Email clients won’t click on the button and users that are redirected to this page can simply click on the button to finish their verification.
\nThe token in the URL is then passed onto the backend for verification. On the backend, once a verification token has been consumed, the verification status for the user should be changed.
\nfunction verifyEmail(token) {\n\t/* \n\t\tFirst, we need to verify that the token corresponds with an actual user.\n\t*/\n\n\trowFromDb = db.getRowThatContains(token)\n if (rowFromDb == null) {\n throw Error(“invalid password reset token”)\n }\n userId = rowFromDb.user_id\n\n\t/*\n Now we know that the user exists, so it is valid. We start a \n\t\ttransaction to prevent race conditions.\n */\n \n db_startTransaction() {\t\t\n\t\t\t/*\n\t\t\t Here we check if the user is already verified.\n\t\t */\n if (userId.verified = 1) {\n db_rollback();\n throw Error(“User is already verified.”);\n\t }\n\n /*\n\t\t\t Here we check if the current token has expired or not.\n\t\t */\n if (userId.token_expiry < time_now()) {\n db_rollback();\n throw Error(“Token has expired. Please try again.”);\n\t }\n\n /* \n Here we'll change verifications status to verified. \n */\n db_saveNewVerified(userId, 1);\n db_commitTransaction();\n }Email verification is only a small part of the overall onboarding process, but one with a surprising amount of nuance. Poor implementation can lead to frustrated users who will churn out. While you’ll get away with it in the beginning, ignoring this is a bad idea in the long term.
","frontmatter":{"date":"February 24, 2023","title":"Implementing the right Email Verification flow","cover":"email_verification_blog_banner.png","author":"Rishabh Poddar","description":"Email verification can increase friction and adds another stop to onboarding, but when done correctly can lead to better security and establish better communication with users."},"fields":{"slug":"/implementing-the-right-email-verification-flow/"}},"site":{"siteMetadata":{"title":"SuperTokens Blog"}}},"pageContext":{"id":"b2f151ae-5d7e-5652-9c2a-c6dca88100a8","fields__slug":"/implementing-the-right-email-verification-flow/","__params":{"fields__slug":"implementing-the-right-email-verification-flow"}}}, "staticQueryHashes": []}