OpenID is primarily thought of as a process that starts in a login box where a user either selects their identity provider, or types in an identifier like a URL or email address. However many websites are understandably nervous about changing their login box. Fortunately, there are many ways to use OpenID without a website needing to change its login box. There are four main techniques the industry has identified that can be used:
Email notifications to existing users
Invitations to new users
Account creation wizard
Email verification for new users
Email verification for existing users
Each of these techniques is discussed in a section below.
Email notifications to existing users
If your site sends email to users, then this is likely to be the most valuable technique. Traditionally when a user receives an email from a site where they have a login, the message contains a URL link back to the site. However if the user is not currently logged into the site then they need to type their email address and password. This is annoying to the user at best, and at worst they have forgotten some of their login information.
To improve on this technique, your site can use OpenID with some popular email providers such as Gmail, Yahoo mail, Hotmail, AOL mail, Google Apps mail, etc. Most consumer websites find that 60-80% of their users have email addresses with these providers. Whenever your website sends email to a users, any URL links back to the site can be modified to include a URL parameter with the email address of the user it was sent to.
Note: For security/privacy reasons the email address should generally be encrypted using a key that only your server can decrypt.
If your website gets a request to load a page that includes that URL parameter, and the user’s browser is not currently logged into your site, then that email address can be saved in a cookie. If the user then visits any page on your site that would normally show a login box, it should check for the existence of that cookie (or the URL parameter). If the email address is for a supported OpenID enabled email provider, then instead of showing a login box, your website should show a big button for that email provider, along with a smaller text option below to button that says “Or use a different email address.” If the click that text option, then your site can show a regular login box. However if they click the identity provider button, then your site can start an OpenID flow to the identity provider. One of three things will happen:
The user will be redirected back with the IDPs assertion of the email address of an existing account at your site, in which case you can immediately log them in
The user will be redirected back from the IDP with an error, in which case your site can show a regular login box
The user will be redirected back with the IDPs assertion of the email address of an account that does NOT yet exist at your site. In that case you can help the user create an account for that email address, but you will not need them to verify their ownership of the email address since the IDP already asserted it.
Note that even though you might use OpenID to login the user in this situation, your site can continue to store the local password the user has associated with their account. That way if the user visits your website directly, they can login to your existing login box using that password.
One of the nice things about this technique is that it is very easy to measure its impact, and to slowly roll it out by adding the email address to more Email notification and adding support for more identity providers.
There are a few additional ways to improve upon this technique:
Identity hint: In steps 1 and 3, your site can save the OpenIDURL of the user’s email address. Before sending a user to an identity provider, the site should check if it knows the OpenIDURL of the user. If so, then some IDPs provide a way for that OpenIDURL to be sent as a hint of the user’s identity. This can be helpful if the user is logged into multiple accounts at the IDP (which Google supports) or if the user is not logged in at the IDP in which case the IDP can use that hint to pre-fill the email/username field of its own login box.
Auto Login: Your site should then modify the logic used to display a button for identity providers. It should check if the email address in the cookie/URL-parameter is for an identity provider that supports a technique called checkid_immediate. This technique allows your site to open an invisible iFRAME to the IDP and ask if there is a user logged in who has given permission to be automatically identified to the current website. If that succeeds, your site does not even need to display a button, it can instead automatically login the user.
Hybrid mode: The IDP may provide APIs that your website uses for other services like giving access to a user’s address book, activity stream, calendar, photos, etc. In the code on your site to show an IDP button, it can detect whether the account associated with the email address in the cookie/URLparameter has given consent for that API to be accessed. If the user has not, then when the user clicks the button the site can initiate a combined OpenID+OAuth request to both identity the user and get their consent to access that API. If your site uses this technique, it sometimes is helpful to (1) explain what the site is going to request & why, and (2) offer an option on the page for the user to only do a regular OpenID request, and not include the OAuth request.
Username Recyling: Some email providers will detect when a username is no longer being used, and will allow a new person to create an account with that username/email address. In that case, the IDP will assign the new account a different OpenIDURL. If your site ever receives an assertion from an IDP where the OpenIDURL does not match the existing one associated with a particular email address, then your site can disable the old account for that email address and help the current user create a new account.
Invitations to new users
Some websites send email invitations to users who are not yet members of the site. For example, a website might ask existing users for the email address of their friends so they can receive invitations. That is just a specific instance of the feature described above. However many website find that a good a way to start with OpenID is just to use it with invitations to existing users. This particular technique is frequently referred to as “hybrid onboarding” and was first widely used by Plaxo and Facebook.
Account creation wizard
If a user visits their site, and does not think they have an existing account, they normally need to go to an account creation form. Normally those are long forms with lots of fields such as the user’s email address. Frequently after the user submits that form, they are then told that an email verification message was sent to their email account, and they need to go find it (which can be hard if it ended up in their SPAM folder). In addition, it is pretty common for users to forget they have an account at a site, in which case they may mistakenly try to create a new account. Those users normally get caught in an ugly series of error messages, and in many cases they need to perform a password reset to get back into their account.
An alternative is to replace the form with a “wizard.” The first page of the wizard shows a list of support identity providers, as well as the option for a user to just type their email address. If the user clicks a button for an identity provider, then it kicks off the same logic as describe in the first section of this document. Most of the users who come back from the IDP will be creating a new account, but some will have forgotten that they had an account, but your site will be able to give them a great user experience because you can just automatically log them in. If the user types an email address, you can then do one of 3 things:
If the email address is for a domain with an IDP, you can redirect them there
If the email address is for an existing account without an IDP, you can show a login box with the email address field pre-filled
If the email address does not have an IDP and does not match an existing account then you can show the regular account creation form with the email address pre-filled
Like with the first technique, it is very easy to measure its impact, and it can be rolled out as an experiment that is only shown to a specific % of people who click the account creation link on your login page.
There are a few additional ways to improve upon this technique:
Customized IDP list: If your site supports many IDPs, it may be visually overwhelming to list all of them in the wizard. However you can look at information like the user’s language settings and IP address (mapped to a geography) to try to promote IDPs that are more likely to be relevant to the user
Login easter egg: Once your account creation wizard is enabled for 100% of users, it creates a hidden “easter egg” that existing account owners can use to login without a password if their email address is OpenID enabled. Very few users will figure this out, but to login they can ignore the login box, click create account, and then click the button of their identity provider.
Email verification for new users
There is an alternative to the Account Creation wizard that is more conservative. Your site can leave the form umodified, but instead of telling the user they have been sent an email to verify their email address, you can instead detect email accounts for OpenID enabled domains, and show the user a button that will take them to that IDP to verify their email address. If you use this technique, it is generally still a good idea to also send the user the traditional email verification message before displaying that button, just as a backup. Google has a blog post on their use of this technique.
Email verification for existing users
If a user tries to log into your site and still has not verified their email address, you might have logic that sends them another email verification message. In that case, for OpenID enabled email domains, you can also use the technique from the previous session to give them the option to use OpenID.