Quantcast

Design patterns: one-click account creation via email



Pavel churiumov 321968

How can I easily invite a person I know, such as a client, partner, or customer, to create an account in my system? 

We build web sites and web applications that integrate content management, digital publishing, customer support, and operations workflow. We’ve solved similar problems often enough that we’ve formalized solutions into reusable components of our software framework. This article is the second of a series Nick is writing on workflow design patterns.

Context

A host organization with a complex software system has customers, clients, partners, or collaborators with application workflow needs—perhaps they need to check the status of an order, manage documents or images, or fill out a form. Administrative staff know these people individually and has their email address.

Challenges

Confirm the email address: ensure administrative staff has the correct email address on hand, and the client can access it.

Uphold common sense security design patterns: avoid sending usernames and passwords over email, which is not a secure communication network.

Enable easy account confirmation: avoid forcing the user to copy and paste information from an email into a web form. From a usability perspective, it’s difficult at best on a mobile device and creates a terrible first impression: here’s some work for you to do, before you even get started.

Solution

Since administrative staff knows the person to be invited, they can create an account for them in the system. The email address is mandatory, but optionally name, address, or other supporting information can be included. A single action button—email login info—uses a form letter to create and send an inviting welcome email. In the welcome email, the system embeds a tokenized URL which identifies the person.

Upon receipt, the customer clicks on the link, which confirms her account. She can then continue to setup her account by establishing her password, or use OAuth integrations to popular services like Google, LinkedIn, Facebook, etc. The token is expired after use.

The system should update the record with date and time stamps for around this workflow: potentially when the email is opened, and when the link is clicked.

Consider monitoring the token for troubles: repeated clicks might indicate a problem. Users might try to use the email repeatedly, as their “gateway” to the system, so redirect expired tokens appropriately. From a mobile usability perspective, tokenized URLs are ideal—they are easily clickable.

What do tokenized URLs look like?

A tokenized URL uses an algorithm like SecureRandom to generate a random, unguessable string. It is appended to the application in a URL. They might look like:

  • www.example.com/welcome/pTMjSZL1bhhgL3ooeMAmo1
  • www.example.com/welcome/ioaGrbVxHFCVi9yQKEJuCT
  • www.example.com/welcome/dDWo7YtUFksBZM6Luhn87A

Security considerations

Tokens expire after use, and are practically not guessable given an appropriate size. However, while SSL secures the token while in transit to the application, email is inherently not secure. Mitigate email security considerations pragmatically by expiring the token after a period—perhaps even a few hours. Administrative staff can also be provided a revoke or resend option if the account is not established as expected.

Photo by Pavel Churiumov