Pattern: User Account Confirmation

gistfile1.md

Problem

A user's true identity or email address must be verified before they are given full access to your application.

Solution

The system sends an email to the user's email address containing a unique, personalized url. Visiting the url in a browser provides sufficient identity verification, since the url could only have been known to the person who received the email.

Assumptions/Flaws

The entire solution rests on the presumption that access to an email inbox is succificient proof of identity authentication, much like bringing a utility bill with an address on it is proof that you live at the address shown on the bill. If someone were to visit that url (perhaps by guessing or hacking into your email account) then they will be falsely authenticated.

Typical Implementation

1. The user provides their (alleged) email address, let's say jeff@example.com.
2. The system sends an email to jeff@example.com that has a personalized link. The link contains a hard-to-guess path component value or querystring value, often referred to as the token. For example: www.service.com/confirm?token=8F74XO9ASD74ACS0ACL232
3. The system handles the GET request to the personalized URL, and updates the user's account as being "confirmed" or "verified."

Common variations

• The system can place a limit on how long the token can "live". If the token expires, the user has to request a new confirmation email.