Eric Sachs, Product Manager, Google Security
Originally posted 9/18/2008 (last update 10/27/08)
Federated Login has been a "holy grail" in the identity community for a long time. We have known how to do the technical part for a long time. However the industry has constantly tried, and failed, to find a model that was (1) simple for end users, and (2) had a reasonable trust model between the RP (the relying party, which is the site you want to log into) and the IDP (the identity provider, who will identify you to the RP). Google has been experimenting with different user interface models for federated login using the following design principles:
The UI we are suggesting is closest to that of websites like Buy.com and Amazon.com. As an example, here is the current Buy.com login UI:
Below is a modified version of the Buy.com UI which uses the UI model we are suggesting. Can you see the difference?
In the following sections, we will provide some examples of different use cases that this login UI can support.
Scenario 1: New user from a trusted IDP
If an AOL user comes to the buy.com site with their current UI (as opposed to the suggested modified UI), and has never created an account at buy.com before, then they would enter their @aol.com E-mail address, and choose "I am a new customer." In that case, buy.com would show them an account creation form. However, let's assume buy.com is willing to act as an RP, and it has decided to trust AOL as an IDP. Assuming they switch to the UI model suggested above, then when the user visits the buy.com site, they would enter their @aol.com E-mail address, and choose "Help me sign in." Admittedly the phrase "Help me sign in" is not as explicit as "I am a new customer" however so far our usability tests have shown it works just as well (though we would like help getting more data to confirm that fact).
In this scenario, buy.com could detect that the domain name is for an IDP that it trusts. It could then redirect the user to AOL to verify their identity. Assuming the user approves sharing their identity, then the user will be redirected back to buy.com which can automatically create an account for them, and log them in.
Scenario 2: Repeat user with an IDP enabled account.
If the same AOL user from scenario 1 visits buy.com's site on another computer, they would be presented with the modified login box UI. In most cases, the user will choose "Help me sign in" just like they did the first time. Buy.com will again redirect them to AOL to verify their identity, and when AOL redirects the user back, buy.com can detect that a local account already exists for the user, and can log them in. However, in our usability studies, we have found more users are confused by this UI the second time they visit then the number of users confused by this UI the first time they visit. The confused users assumed they must have a buy.com password, because that is the experience they are used to for sites where they can login. Fortunately, even though they are confused, nearly all users did enter their E-mail address and clicked the login button. As long as they do that, it does not matter whether they chose Yes or No in the UI, nor does it matter whether they typed a password. Buy.com just needs to know that their domain is aol.com, and can then redirect them to AOL to verify their identity.
Google is evaluating different ways to minimize this confusion. One option is that users who go through scenario 1 should be presented with an educational page by the RP after an account has been automatically created for them. That page can explain to them how they should log in the next time (see the example below). Another optimization is that in scenario 2, if the user choses the wrong option before clicking login (such as saying they did have a password) then the RP could warn them after verifying their identity with the IDP.
Scenario 3: New user from a domain that is not an IDP
Scenario 1 describes how buy.com would handle a user from AOL. However if a new user enters an E-mail from a domain that is not a trusted IDP, then buy.com would simply show the exact same UI it does today to help the user create an account with a buy.com password. An additional option is to ask the user if they have an account with a large IDP who will have already validated a user's E-mail address. Examples include Google Accounts, Facebook, MySpace, MS Live, etc. If so, the user could be sent to that IDP to verify their identity and E-mail, and in the future they could login to the local site by just entering their E-mail and choosing "help me sign in." In that case the local site could lookup which big IDP was associated with that E-mail address, and redirect the user there.
Scenario 4: Legacy user from a domain that is not an IDP
In this document we use the term "legacy user" to refer to someone who already has an account at the RP and which uses a local RP (buy.com in this case) password. If such a legacy user enters their E-mail/password in the login box, then buy.com would log them in as it does today. However that assumes the user is from a domain that is not a trusted IDP. As in scenario 3, an additional option is to ask this user if they have an account with a large IDP, and if so use that IDP to authenticate the user in the future.
Scenario 5: Legacy user from a domain that is an IDP
If a "legacy user" logs in with an E-mail address that is from a trusted IDP like AOL, and provides a valid buy.com password, then in this situation the RP can promote the option to "bind" their existing buy.com account to a federated login using AOL as an IDP. If the user chooses that option, they will be redirected to AOL, and then back to buy.com. Buy.com can then associate their AOL identifier with the pre-existing buy.com account. Buy.com could optionally disable the user's ability to login with their legacy password.
Scenario 6: Help me sign in
Usability testing indicates that some new users will simply select "No, help me sign in" and then click the Sign In button. For those users, the login box can display an error requesting the user's E-mail, but users respond better if they are redirected to a page which gives more context about what is happening and then asks for their E-mail address.
The five scenarios listed above are the most common use cases. There are some edge cases discussed further below, however it is worth first discussing how this UI fits into our design principles:
However, many websites do not have these types of restrictions, and so we hope that some of those sites will experiment with this type of UI, and report their results so that this UI model can be refined. One thing to remember is that most websites which rely on E-mail based logins already trust the E-mail provider to validate the owner of an E-mail address, not just for account creation, but also for account recovery. So technically, those websites already act as RPs to those E-mail providers.
In the scenarios described above, an E-mail addess was always used as the identifier in the login box. However, it is worth noting that this is not a requirement. For example, in most cases it would be sufficient for the user to just type their domain name. In fact, if the IDP uses opaque federation identifiers, then that would allow the user to consistently login to that website from different computers, but without any globally unique, or personally identifying information, being shared with the RP. Even if the IDP uses global identifiers such as URLs, the user could still enter the domain name of their preferred IDP, even if it was not their E-mail provider. For example, some users might enter facebook.com or myspace.com to leverage those popular social networks' identity services. Other users might enter pip.verisign.com to leverage Verisign's 2nd factor authentication service. A smaller group of users might enter a full URL (like an OpenID validated URL for their blog), or a mobile phone number which can be validated by sending it an SMS message.
However, there is a tricky balance to be found between promoting these options to advanced users, and avoiding confusing regular users. Some websites that have experimented with federated login technology have tried adding specific buttons for particular IDPs, in addition to their regular login box. For sites with technical users, that has minimal impact, however sites with a wider audience have reported that their regular users get confused by these additional options. In addition, there is a chance that the same user might login via the regular login box one time, and then later try to use one of the custom IDP buttons. That requires the website/RP to present additional UI to try to detect those situations, and this can further complicate the signup process.
We hope that different websites will experiment with different UI options to promote these options. For example, a website might change the sentence "Enter your E-mail address" to "Enter your E-mail address or IDP" where the word IDP provides a popup with more details. Another website might add a sentence to the bottom of the login box that says "Logins supported from: X Y Z" where X, Y, & Z are small icons for some large IDPs who are not E-mail providers such as MySpace & Facebook.
New Account Signup Flow
One of the biggest reasons the industry has focused on federated login is to minimize the work required for a user to signup for a new account at a website. When users are presented with a traditional signup page that asks for E-mail, password, & password confirmation, it is quite common for 30-50% of users to not finish the process. So in this next section, we look at the specifics of how the signup flow interacts with federated login using a few scenarios:
Scenario 1: RP just needs a consistent identifier
Some websites do not care about the user's E-mail address, but they ask for it anyways because it is easier for users to remember that then to ask the user to create a username on the site. The simplest signup page for such a site would simply ask for E-mail address, password, and password confirmation. If a new user enters an E-mail for a trusted IDP, then the user will be sent to the IDP to get approval to verify their identity, and will then be sent back to the RP. The site can simply skip the signup page completely, and log the user into the website. So there are two possible flows for end users:
legacy signup: 1 login page which collects their E-mail, and a 2nd page which asks for E-mail, password, password confirmation
IDP signup: 1 login page which collects their E-mail, and a 2nd page which asks the user to click a button to approve sharing their identity
Scenario 2: IDP who uses opaque identifiers
If the IDP supports using opaque identifiers, then a user may have told the IDP to auto-approve any identity verification request by an RP. In this flow, the IDP signup takes only 1 page, the login page.
Scenario 3: IDP hint
Before the user visits the RP's website, they may be on the website of an E-mail provider, or a site that can provide the E-mail domain of the user. For example, if the referral URL is mail.aol.com, then the RP can be quite confident the user is an AOL user. If the referral URL is a websearch provider, then it is possible that the user was already logged into the websearch provider, and thus the websearch provider could pass along the user's E-mail domain as a URL parameter for a redirect caused by an ad click or websearch click. Another option is for a browser extension to detect the last IDP that the user logged into, and send that parameter in the HTTP headers along with other information such as the user's language preference list. If this IDP hint is passed to the RP's site, and the RP is willing to trust it, then it could send the user to that IDP immediately. If this flow is combined with that of an IDP who uses opaque identifiers, then the signup process can be 0 steps. However in most cases, the RP will treat this is just a hint, and will modify their login box to say something simple such as "Login with your @aol.com account" which would take the user to the AOL IDP, and a smaller option underneath that says "Or use a different account" which would display the same login box that the RP uses when the IDP hint is unavailable.
Scenario 4: Terms of Service
The scenarios above describe the most optimal user experience, however many sites have more complicated requirements. For example, the site might require users to agree to a Terms of Service. In scenario 1 this would add a 3rd page to the IDP signup scenario, and make it more pages (though still less work) for the user. Depending on your legal requirements, it may be possible for you to avoid showing the TOS on a full page, and instead log the user into your site, but show a visual banner of some type near the top that includes a link to the TOS to make sure users have a chance for informed consent. Unfortunately in some cases your site might have more complex legal requirements, such as requiring that users click a box to confirm they have read the TOS. Some IDPs may even be willing to show the TOS of the RP on their approval page, however the RP's lawyers will need to evaluate whether that meets their legal requirements.
Scenario 5: Training Page
In "Scenario 2: Repeat user with an IDP enabled account" we mentioned that returning users are sometimes confused by this suggested login UI, but that the confusion can be reduced by adding a "training page" during the new account process. Unfortunately that page does add a step to the account creation process. However, if your site already needs to show a page after the IDP verification, such as a Terms of Service page, you can combine the two.
One of the trickiest parts of the new account flow that we have found in the use of federated login is the use of E-mail as identifiers. Most websites use E-mail addresses to enable their legacy users to login. If an RP then starts to trust an IDP who provides E-mail, it needs a way to map legacy users to federation identifiers. If the IDP does NOT support E-mail validation as part of the federation protocol, then there are a few techniques the RP can use:
Note: One edge case is that the user's E-mail address on the IDP might not be an exact match for the E-mail address they used with their legacy account. For example, a Google mail user can have an E-mail address such as firstname.lastname@example.org, but they can also receive mail at email@example.com. Some Gmail users have legacy logins that use those E-mail addresses with "." characters in different locations then their primary address. The RP will need to keep a list of the domains that operate this way, and whenever it compares a legacy E-mail address to an E-mail assertion it gets from the IDP, it will need to remove all "." characters before the "@" sign from both E-mail strings before doing the comparison. For legacy users, the RP should probably continue to keep the legacy E-mail address for the user instead of replacing it with the one asserted by the IDP. The advantage of doing that is that the user may have filtering setup in their mailbox based on the location of those "." characters.
Longer term, a more privacy sensitive RP can monitor to see if all the legacy users in a given domain are now using federated login. If so, it could potentially stop storing the E-mails for that domain, and only ask the IDP for that domain to send the opaque identifier of the user. However, if that IDP disables their IDP verification service, or it becomes unstable, then the RP cannot authenticate the users from that domain. Therefore, a more conservative RP is likely to continue to require E-mail addresses because they can be used as a backup way to authenticate users in that situation by sending the user a traditional E-mail verification or Forgot Password link.
Some RP websites need to gather other information about the user in their signup flow such as zipcode, country, gender, etc. Generally this information is collected at the same time a user would be shown a Terms of Service page as described in "Scenario 4: Terms of Service." However, if the IDP supports E-mail validation, they mail also support the exchange of other attributes. Thus, if the RP trusts an IDP who provides E-mail validation, and has already decided to use that feature, then it should check whether the IDP also supports the exchange of other attributes because that may be used in some cases to further simplify the signup process. However, the RP should be prepared for the situation where some users at the IDP do not have all requested attributes (or don't allow the IDP to share them with the RP), in which case the RP will need to collect them.
In Google's usability tests, we found that there are some common attributes that are unlikely to be personally identifiable, and which users tend to be very comfortable sharing from an IDP to an RP. Those include Country, Zip Code, Language, & Time Zone.
Comparison Summary for Sign Up
A key goal of federated identity is to make the new account signup process simpler. Below is a summary of the steps required in one of the most common cases, which is a website which needs an E-mail, ZipCode, & Terms of Service. If the Website is not an RP, then new account flow is as follows:
Step 1: User clicks a Create Account buttonBelow are the steps if the Website is an RP, and the user is logged into an IDP which the RP trusts. This assumes the IDP supports a federation identifier & E-mail address validation.
Step 2: On the next page they are prompted for (1) E-mail address, (2) password, (3) password confirmation, (4) ZipCode & (5) Terms Of Service
Step 1: User enters E-mail address in login box and chooses "Help me sign in"Note that the federated signup process is more steps, but in our usability studies the removal of the double password prompt is a significant benefit. We hope that some websites will experiment with this type of UI, and report back the % of users who finish the new account flow using the federation technique as opposed to the traditional method. That % is also likely to vary based on the IDPs user interface and functionality, so it will be helpful for websites to report the % success for different IDPs so that the IDPs can learn what techniques work best.
Step 2: On the IDP they are prompted to approve sharing their identity & E-mail address
Step 3: On the RP site they are asked to enter their Zip Code, agree to the Terms of Service, and they are also shown "training" information on how to login in the future
Comparison for Sign In
The second key goal of federated identity is to make the sign in process simpler for user's who already have an account. The comparison here is complicated by the "saved password" feature of some browsers. If the end user is on a machine that does not have any saved credential information for a particular RP, and they are already logged into their IDP/E-mail provider, then it is less work for the user to login using federated identity (especially if they would have otherwise have used a hard to remember password at the RP site). However, in the common case, a user is logging into a website from their home computer and their credentials will have been pre-filled into the login box by the browser. In that case the user simply has to click the login button, and it is hard to make the process much simpler then that. If the user logged into an RP site using federated identity, and the browser did not save any credential information, then the user will have to type their E-mail address every time they come back to that site (though some browsers at least support type-ahead). The behavior varies by browser, but when possible, the RP should try to leverage the browser's ability to save the user's E-mail address for auto-fill or type-ahead purposes.
If your site does choose to implement the user interface guidelines described in this document, we have provided a checklist to help you evaluate your implementation.
The UI flow described above works on the web, even with different (and sometimes proprietary) federated identity protocols. However for a desktop app (or a mobile client app like a J2ME app), this mechanism is much harder to use with those identity protocols because they are generally designed to be used with web clients. If your website needs to support legacy client apps that cannot be modified, like Outlook, then you may not be able to use federated login unless the IDP is willing to use some background mechanism to sync a copy of their passwords to your RP. However if your client apps can be modified, then one option is to use the OAuth (www.oauth.net) protocol. That defines a standardized flow for a desktop app to request a token from your RP that will be used for data access, however initially the token is invalid. The client app then, if possible, launches a web browser and sends the user to your site to first login, and second to be shown a screen they can use to make that token valid. Once the user is in their web browser, they can use the technique above to login with a federated identity, but then are redirected back to your RP site to show the token approval page. If the client app cannot launch a web browser, it can direct the user to launch one manually (even on a different computer), and go to a URL on your website where they will first login (using federated identity). After they are logged in, your site can ask the user to enter the token that needs to be approved by having the client app display it. After the end-user has used one of these two mechanisms to approve the client token, the client app will then be able to access the user's data.
The technique above works well when the client-app only works with one, or a few, sites. However if a client-app is being built to work with any site that supports a particular data-protocol (such as the new OpenSocial REST APIs), then this technique will need some special setup because OAuth requires the client app to know what URLs to use for interacting with the data provider site (to request a token, to request data, and to redirect the user to approve the token). The client app usually needs to be pre-configured with that information, though the OAuth community is discussing ways to enable that to happen automatically in a standard manner.
Account Settings page
If a website becomes an RP, then in addition to modifying its login box, it should also modify the UI of its account settings page. For a non IDP user that wants to change their E-mail address, then the RP needs to check if the old or new domain is a trusted IDP. If the new domain is a trusted IDP, then the user needs to be sent to that IDP to get the associated federation identifier. For an IDP user, the option to change the password should be removed, and instead they should just have the option to change their E-mail address (which technically is bound to an IDP). If they choose the option to change it, then the RP should first attempt to redirect the user to their IDP using the OpenID PAPE extension to force the user to re-authenticate (assuming the IDP supports that feature). Then the user should be asked for their new E-mail address. If it is for a domain that is not an IDP, then the user will also need to be asked to specify a password. Otherwise they should be redirected to the IDP of the new domain to verify their identity.
Forgot Password flow
The proposed login box UI uses the generic "help me sign in" term. Some legacy account holders might choose that option if they forget their password, so the RP will need to detect that situation and sent them to the forgot password flow. Some RPs may still keep a separate link on their login page that specifically links to the forgot password flow. We hope that RPs will experiment with different wording/location of that link (as well as not showing it), and report back the comparative usage rate.
Browser auto-fill, tab order, and signup
RPs who use this approach should be carefull note to break the login autofill feature of browsers. The fieldnames of the E-mail address and password fields should not be changed. The tab order of the fields should be (1) E-mail (2) the two radio box options, (3) the password field, & (4) the login button. The addition of item 2 (the radio boxes) will add one step for legacy users, however what major websites have found is that the autofill feature of browsers is so commonly used that tab order for existing users is of minimal importance. By default, the radio box option should be set to "I have a password," however if the previous login on that computer was done using federated login, then the RP should set a permanent cookie on that computer to remember that preference and to changet the radio box to the "help me login" option. For new users who need to signup, they have the option to choose "help me login" and then to click login. However if the RP has room of the page, it is also good to have a single signup button since that is fewer steps (however in that case the RP should use a modified signup form as described in scenario 1 of the Supported Use Cases section.
Session Timesouts and Reauthentication prompts
See http://sites.google.com/site/oauthgoog/Home/repromptsEric Sachs
Websites with strong authentication requirements
Some websites, such as online banks, are unlikely to be able to trust consumer E-mail providers to act as IDPs for authenticating their customers. Those sites frequently ask users to register a username (as opposed to E-mail address) that is used to login to their site, however numerous studies have shown that users have a hard time remembering unique usernames for sites in addition to password, which is the main reason most sites use E-mail addresses instead of usernames. However, those sites could experiment with using the UI suggested here as one form of authentication, and then also using a second authentication mechanism. For example, after the user has been authenticated by their IDP, the site could check what second factor of authentication should be used to verify the identity of that particular account. It could be an image that the user associated with their account, a PIN code, a physical token, mobile phone, etc.
Scaling the set of supported IDPs
Some websites may want to aggressively support as many IDPs as possible. However, there are technical and legal/trust barriers to achieve that goal. On the technical side, there is no single standard for federation protocols. Even when multiple IDPs use the same protocol, there can be some variance in how they use it. For example, some IDPs might support OpenID using global identifiers (like URLs) and others via opaque identifiers. Or some IDPs might support the OpenID discovery protocol for their top level domain name, like gmail.com, while others require the RP to know that a subdomain should be used. However the protocols in this space are evolving, especially the automatic discovery mechanisms which allow an RP to support different ways of interacting with IDPs, and then checking which methods a particular IDP supports.
On the "trust" side, there is the potential for brokers to exist that operate an identity provider's IDP service for them, just as some company's outsource hosting their E-mail or website. Those brokers could develop a reputation, or even legal contract, for a certain quality of service, user experience, and protocol support. That would then allow RPs to support any IDP operated by a trusted broker.
Some potential IDPs will be concerned that becoming an IDP will make it easier for their end-users to fall prey to phishing attacks. That is because an "evil" RP could intercept the user when they would normally be sent to the IDP, and instead show the user what looks like a login page for their IDP. The RP could then use that phishing page to collect the user's credentials. We do not have a magic answer for that problem. A similar problem also exists with web delegation protocols like OAuth. In the case of web delegation protocols, the user demand for access to their data was too high for websites to ignore, especially when users would give their credentials to 3rd party sites which would then scrape the main site for the user's data (such as social networks scraping a user's E-mail address book). End-users have a similar demand for federated identity, and because of the lack of it, many users will simply use their exact same password on their E-mail provider's site as they do on many other sites where they login with that same E-mail address. It will be up to individual IDPs to decide how to balance demands from their end-users with concerns about potential increases in phishing attacks.
Product Manager, Google Security
E-mail: google.com (username esachs)