Question

We are in the early design stages of a major rewrite of our product. Right now our customers are mostly businesses. We manage accounts. User names for an account are each on their own namespace but it means that we can't move assets between servers.

We want to move to a single namespace. But that brings the problem of unique user names.

So what's the best idea?

  • Email address (w/verification) ?
  • Unique alpha-numeric string ("johnsmith9234")?
  • Should we look at OpenID?
Was it helpful?

Solution

EMAIL ADDRESS

Rational

  1. Users don't change emails very often
  2. Removes the step of asking for username and email address, which you'll need anyway
  3. Users don't often forget their email address (see number one)
  4. Email will be unique unless the user already registered for the site, in which case forward them to a forgot your password screen
  5. Almost everyone is using email as the primary login for access to a website, this means the rate of adoption shouldn't be affected by the fact that you're asking for an email address

Update

After registration, be sure to ask the user to create some kind of username, don't litter a public site with their email address! Also, another benefit of using an email address as a login: you won't need any other information (like password / password confirm), just send them a temp password through the mail, or forgo passwords altogether and send them a one-use URL to their email address every time they'd like to login (see: mugshot.org)

OTHER TIPS

OpenID is very slick, and something you should seriously consider as it basically removes the requirement to save local usernames and passwords and worry about authentication.

A lot of sites nowadays are using both OpenID and their own, giving users the option.

If you do decide to roll your own, I'd recommend using the email address. Be careful, though, if you are creating something that groups users by an account (say, a company that has several users). In this case, the email address might be used more than once (if they do work for more than one company, for example), and you should allow that.

HTH!

I like OpenID, but I'd still go with the email address, unless your user community is very technically savvy. It's still much easier for most people to understand and remember.

If you use an email address for ID, don't require that it be verified. I learned the hard way about this when one day suddenly the number of signups at my site drastically decreased. It turns out that the entire range of IP addresses including my site's IP was blacklisted. It took a long time to resolve it. In other cases, I have seen Gmail marking very legitimate emails as spam, and that can cause trouble too.

It's good to verify the email address, but don't make it block signups.

Right now our customers are mostly businesses.

People seem to be missing that line. If it's for a business, requiring them to login via OpenID really isn't very practical. They'd either have to use an external OpenID provider, or their poor tech people would have to setup and configure a company OpenID.

If this were "should StackOverflow require OpenID for login" or "Should my blog-comment-system allow you to identify yourself via OpenID", my answer would be "absolutely!", but in this case, I don't think OpenID would be a good fit.

I personally would say Email w/ Verification, OpenId is a great idea but I find that finding a provider that your already with is a pain, I only had an openId for here cause just 2 days before beta i decided to start a blog on blogspot. But everyone on the internet has en email address, especially when dealing with businesses, people aren't very opt to using there personal blog or whatnot for a business login.

If most of your customers are mostly businesses then I think that using anything other than email creates problems for your customers. Most people are comfortable with email address login and since they are a business customer will likely want to use their work email rather than a personal account. OpenID creates a situation where there is a third party involved and many businesses don't like a third party involved.

I think that OpenID is definitely worth looking at. Besides giving you a framework in which to provide a unified id for customers, it can also provide large businesses with the ability to manage their own logins and provide a common login across all products that they use, including your own. This isn't that large of a benefit now when OpenId is still relatively rare, but as more products begin to use it, I suspect that the ability to use a common company OpenId login for each employee could become a good selling point.

Since you're mostly catering to businesses, I don't think that it's all that unreasonable to offer to host the OpenId accounts yourself. I just think that the extra flexibility will benefit your customers.

If you are looking at OpenID you should check out http://eaut.org/ and http://emailtoid.net. Basically you can accept email addresses for a login and behind the scenes translate them to OpenID without the user having to know anything. Its pretty slick stuff...

OpenID seems to be a very good alternative to writing your own user management/authentication piece. I'm seeing more and more sites using OpenID these days, so the barrier to entry for your users should be relatively low.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top