Self-service Registration
Let's talk about self service registration, where a user navigates to your website and signs up for an account without any action by you.
Self-service registration is a great solution for allowing users to access to extra functionality or personalized content. One typical use case is for a visitor to an e-commerce system to have the ability to save items in their wish list for future purchase. In the general sense, registration is a low cost way to allow a person to return later and be recognized by the system in question.
What are you asking the user for?
This process general requires asking the user for a couple of different types of information.
A login identifier. This can be a username, and email address, a mobile number or anything else that identifies the user but is not private. What fits depends greatly on what the user is doing in your application. If they are signing up for a cat picture sharing website, made up usernames are perfectly fine. If they are signing up for a bank account or credit card, you want a username tied to the real world.
A secret, typically a password. This secret allows a user to prove themselves to the system. Otherwise, if the identifier is public, other people can masquerade as this user (though there are other ways for a user to prove themselves)
Other demographic or profile information, such as name or date of birth. The requirements here vary drastically based on what your system is protecting.
Payment data if the application requires it. This may turn immediately into revenue or be captured for future billing if there’s a free trial.
Additional factors of authentication, be they something the user knows, something they are, or something they have. (A factor is a fancy word for "method".)
When to require registration
When self-service registration happens likewise depends on the business needs. Things to think about include:
what functionality requires knowing who someone is in a persistent way
what is the business value of knowing who someone is
what are the expectations of the customer
how will forcing registration affect user behavior (it will drive down conversion, but how much?)
It is difficult to speak in any absolutes about this decision because the business needs differ so wildly. For example, a sandwich restaurant ordering site might want a user to register so they can send additional offers to them and otherwise engage them, but the prime goal is to sell the user a sandwich. The revenue generating activity of sandwich selling outweighs the value of a user registration. While the user may be prompted many times to "create an account", they should be able to check out as a guest. If you have state (browser cookies or a mobile application) you can also let a user order anonymously repeatedly and remember aspects of the order ("user 123 likes swiss cheese") without forcing registration. I wrote more on how to do this here.
On the other hand, a registration paywall for a news site may have be absolute. Sure, there may be workarounds or limited free articles per month, but the demographic data and forced registration has enough value to the news site that they may force it. They may even require payment data.
Finally, an app that stores user data and offers functionality based on it, such as an web based email client, will almost certainly require registration to access any functionality. Users will expect registration in this type of application.
The best way to determine self-service registration details is to think about what you are trying to accomplish, the value of reducing friction for whatever activity you are trying to incent (hahah, as if there is only one) versus the value of a longer term relationship with your users,. Determine what level of friction you need to achieve the goals.
Keep in mind that registration is absolutely a source of friction. The friction can be decreased or increased based on when you present the form as well as what data you collect.
It's also good to look at what the competition is doing, just as a checkpoint. That's one of the nice things about the internet--you can often see what someone does on their website.
Other complexities
Other complexities to think about when considering self-service registration:
the credentials to support. In addition to the secret above, you can also require ownership of an email inbox or phone number to prove user identity, or a private key (via WebAuthn) to do so. This is another way you can increase or decrease friction
registration data collection can be progressive; as a user gets more involved in an application, you can require more information. A very common pattern is the free trial for SaaS applications, mentioned briefly above. A system can require some kind of authentication to set up an account and later require payment details. Another common pattern is favoriting of products, where the user may not even have to set up an account to save some products, but is forced to provide far more details, including payment and shipping address, when they check out.
the level of account validation should be determined by business needs. Depending on the data and functionality you offer, you may be comfortable with any user providing any login identifier. Or perhaps you need to require a user to prove ownership tied to the real world. Validating email address or phone number ownership are most common in CIAM scenarios, but proof of identity can range up to and including proving access to a certain physical location via postcard, bank account control via microdeposits, or certitude of government issued identity via identity proofing.
account recovery is the act of a user in your system being able to recover their account access. In CIAM systems, this typically is automated, with the user proving they deserve access to the account through secondary mechanisms of varying complexity, including clicking on a link in an email to prove they own that inbox or answering challenges they provided or are private information. In some cases this may involve a human customer support rep answering a user's phone call and initiating account recovery. Allowing account recovery without appropriate challenges can lead to account takeover.
people change over time and so user should be able to update all aspects of their profile, including the login identifier, the credentials, multi-factor methods and other information. Those first three should not be allowed without challenging the user to authenticate themselves at a higher level of certainty, since similarly to account recovery, profile editing can lead to account takeover.
one layer of defense in depth is to prevent an attacker from knowing accounts that exist in a system. Unfortunately, with self-service registration, there's no great way to prevent this kind of account enumeration, because any system that allows arbitrary login identifiers can not distinguish between a valid user who forgot they had an account (and maybe a valued customer) and an attacker.
Self-service registration allows companies to let customers and users self-identify at the time and place of mutual choosing, without requiring any human intervention.
Dan