Recent site activity

Federated Login box (Email only)

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 that focused on usability, especially for websites that have a mix of users who use federated login and users who have traditional accounts with passwords at the site.

In September of 2008 we posted the summary of a large set of usability/user-interface research that Google had done (see LSO style).  Since that time we have also studied an alternative approach which is to modify the login box on a website to initially ONLY ask for the Email address of the user, and nothing else.  This design is simpler then the LSO style, however it has the downside of requiring an extra click for legacy users to login, i.e. users who have a traditional account with a password at the site.  To minimize that downside, we experimented with JavaScript and HTML to make sure the the password auto-fill feature of browsers would continue to work for this type of login box and we have made a demo site available.

To test the demo, try logging in with your email and make up a password.  Most browsers will ask you if they should remember that password so approve that request.  Now close the window, and visit the demo site again.  After you enter your E-mail and click Continue your password should already be filled in.  Now close the window yet again, and visit the demo site again.  This time enter an email address in a domain hosted by Google, such as test@gmail.com (for consumer users) or test@alertblue.com (for enterprise users) and in both cases you should get redirected to the login page (or if you are already logged into an account on that domain you will just see the approval page).  If you try this with a Gmail account, you can choose the RememberMe option on the approval page.  In that case, if you restart your browser, visit the demo site, and type your Gmail address you should be invisibly logged in.

If you decide to implement this flow on your own site, here is some technical guidance on how to configure the JavaScript/HTML to support the password auto-fill as well as avoiding a full-page redirect for gathering the password of legacy users:
  • Upon hitting the "Continue" button we perform an AJAX request to the server, which then performs OpenID discovery on the domain-part of the email address that the user typed.
  • This AJAX request returns either with an error code or, having successfully performed OpenID discovery, with the IdP URL that the user needs to be redirected to. In the latter case, we simply set the document.location to the value of the URL returned by the server.
  • The former case (AJAX request returning with an error code) means that OpenID discovery failed. (In a real deployment the server could additionally check whether the email address typed by the user belongs to a legacy account, and therefore no OpenID discovery should be performed to begin with  - the server would return the same error code in this case as if OpenID discovery has failed)
  • If this happens, we 
    • change the login box to add the password field, 
    • re-label the button from "Continue" to "Sign in", and
    • stop intercepting the submission of the login from from Javascript (this means that when the user hits "Sign in" or "Enter", the form is actually submitted to the server, instead of the AJAX request mentioned above)
  • The trickiest part is actually to make the browser recognize this form as a login form, and trigger its password-management mechanism (the part where the browser asks you whether it should save the password for you, and auto-fills it on subsequent visits). It turns out that simply adding a password field (upon an unsuccessfull OpenID discovery) that wasn't there when the page loaded is not good enough - some browsers miss the fact that the form now looks like a login form, and that they should therefore try and help the user remember the password. So what we do is that we have the password field always there and visible, it's just moved off the side of the page using CSS. This seems to work for all the browsers that we tested.
There is some fairly well documented code that implements this. When you read the code, note how we're trying to make it as easy as possible for the user in both cases - the OpenID and the "legacy" (password) case, by handling tab orders, etc. A legacy user would visit the page, and depending on their browser would either already see their username filled in, or would have to start typing the username and allow some form of autocompletion. Then they hit Enter, which causes the password field to be displayed with the password pre-filled-in. Then they hit Enter again, and they are logged in. That's only one additional keystroke compared to a login box that's purely aimed at legacy users.

OpenID users typically have to type their email address (unless their browser has some more advanced form-autofill-features beyond login boxes), and hit Enter. Depending on their IdP, they may or may not have to interact with the IdP. But hopefully, they are already logged into their IdP, and have things set up so that they don't need to approve each login request, so that hitting of  Enter should be all that's needed to log the user into the RP.