There are lots of people adding support for OpenID to their apps (awesome!) but there are some issues that will invariably cause confusion in these implementations if we don't develop some best practices around interaction design.
Basic questions
What username should you give someone signing up with OpenID?
This depends on how the username will be used (if at all). It's not uncommon to use the SREG openid.sreg.nickname attribute to auto-populate this value.
In the case of collision, you could ask if the person has already signed up to your service before using that username, and if so, to have them provide the password for that account to associate the OpenID they've just verified with the existing account; if not, then you simply ask them to provide an alternative username.
Now, since you're using OpenID as the unique identifier, you really don't need the username/nickname, except for, perhaps, their profile URL. Keep that in mind, as you might refer to this as a "vanity URL" instead of "username".
Should signup and login with OpenID be two different processes?
Not exactly.
The first step of any OpenID flow is to ask for the user's OpenID URL (either by directly providing the URL or using a mediated interface, like Blogger's comment form).
Once you've verified their OpenID, then you proceed to the normal account creation process if they've never logged in before. You should try to import and auto-populate any profile forms with data available via SREG, Attribute Exchange, hCard Import. This is especially true for basic data like first and last names, timezone, country and the like. Don't make someone fill out forms that they've already taken the time to fill out elsewhere!
If the person has logged in before, you simply continue on as though it were a normal login flow.
We need the person signing up to check the EULA acceptance box
Nothing about OpenID prevents you from putting up barriers like EULAs in the account creation process. OpenID lets people use existing credentials and optionally import data from their Identity Provider, but doesn't mean that you don't have control over your sign up process.
If someone verifies their OpenID but then aborts the signup process before agreeing to the EULA, their account is simply flagged as needing to agree to the EULA before they can begin using the site, just as you would do for someone who hasn't verified their email address.
In any case, you can still have whatever checks and mandatory data requirements you want in your signup process. OpenID doesn't restrict you in that way at all.
What about confirming email addresses? (the email provided by SREG et al won't necessarily be verified)
Same as before. Since they're using OpenID to sign in, one presumes that they'll be able to use OpenID to login again, obviating some reliance on the email address.
All the same, you simply send out a confirmation email to the email address they've provided and wait for them to confirm it. If provided a false (or accidently incorrect) email, what difference does it make? They can still login with their OpenID and then add other email addresses under their account settings, just as they should be able to do otherwise.
People who use OpenID can't use OpenID inside of our desktop application
Ah ha! Actually then can, thanks to the development of OAuth. OAuth was designed to specifically solve this problem by providing a delegated authorization protocol that is compatible with OpenID (and any other authentication protocol).
There are even libraries to make it easy to implement.
For existing accounts
Associating accounts with OpenIDs
Some sites allow for multiple OpenID identifiers, but I don't see a compelling reason for that. And it would require a significantly more complicated UI, and starting with a single one keeps the option of extending it later to multiple IDs (which I think is unlikely going to be necessary).
I agree this is an outlier case. Most people will probably only use one OpenID to sign in to services, and even if they use more than one, they may not wish to associate them with the same account.
That said, OpenID offers this as a measure of robustness that email doesn't support as well... in particular, if, for whatever reason, your OpenID provider goes down, you can login with one of the other OpenIDs you signed in with.
As well, some people will have more than one OpenID, like they have more than one username that they've had to use over the years... they may forget which OpenID they signed up with -- authenticating against all of them means they won't have to remember. It's edge, but it's something to consider.
Wordpress's wp-openid plugin handles this UI pretty well:
Nitty gritty questions
Should we publish the openid identifier on the public profile?
There is no consensus whether that is bad practice or not. The standard does not disallow it.
There will be a note about this on the registration form where the user enters the OpenID identifier, so those who are uncomfortable publishing their OpenID can choose to register differently.
I think that having it public can be highly useful in the long run when people start to outsource identity management. E.g. I can put all information about myself into something like this: http://username.myopenid.com/ - and then we're is free of the burden of profile management.
For the most part you should conceal people's OpenID's like you would their email accounts -- *unless* you ask them if they want to reveal their "homepage link" or something like that. For a while, people delegating their OpenIDs will be in the minority, and will be coming from sites like Yahoo, AOL and others where their identifiers are also useful for IM and email. In those cases, you really don't want to expose their OpenIDs without asking.
I like what Veer has done with allowing for privacy settings per item:
Setting a username for OpenID users
This one's really hard because you do need a way to internally refer to someone, and it's handy to be able to give members an "alias" (just like a username) so it's easier to get to someone's URL on a site... then again, if people host their profiles elsewhere, there's less of a need to have a primary profile link, theoretically.
If there is a collision, say when filling in a username from SREG or other profile import mechanism, you could either provider alternate username options, like AOL does, or you could prompt the user: "Do you already have an account here? If so, you can signin now to associate the OpenID that you just authenticated against with your existing account."
Should I show the username? Full name? OpenID? Random numbers?
Ideally you'll want to show the person's name -- either the firstname (less ideal) or the full name (more ideal). This is really a privacy issue, so it's up to you what makes sense for your community. If you choose to use unique aliases, that's also usually a safe bet, but leaving it up to each member is usually a good idea.
Showing the OpenID as the person's identifier or "name" is probably a bad idea. Even though you might display their homepage URL, which might be their OpenID, on their profile, that doesn't mean that's what they should be called. Remember Compuserve usernames? Yeah, that sucked.
Limited Betas with OpenID
Using invite codes
BricaBox's private beta requires an invite code and the use of the email address that you received the code at when you sign up. They allow you to sign in with OpenID but unfortunately it seems that unless you've previously associated an email-based account with your OpenID, it'll complain that it doesn't recognize your OpenID, even if you have a valid invite code.
The problem with this scenario is that, once I've received my invite email, it should matter how I sign in. Once I've proven that I have a valid invite code (since I received the email), I should be able to sign in with my OpenID.
If they wanted to make sure that I sign up with the same email address that was invited, they should remove the "sign in with OpenID" option until later. Of course this kind of defeats the profile portability benefits of OpenID.
Using Whitelists
...later
When OpenID fails
Recovering from errors with OpenID is super critical, but not always obvious. You *don't* want to do this:
Using email for account recovery
Even though users really only need their OpenID to signin to a site, sometimes people forget their OpenIDs (yes, it happens, more often then you think). In these cases, offering the ability to recover a temporary password to access their account by entering an email address which they've previously confirmed will save you copious amounts of time working with someone who can't signin.
Upon signing in with their temporary password, you could prominently show a message: "Next time, use (openid address) to signin to this site. The password you just used has now expired."
37Signals does this on Basecamp:
--
Comments (0)
You don't have permission to comment on this page.