The majority of Internet websites use E-mail addresses for their logins, however many large websites require a unique username. Those usernames are frequently used to identify the author of content on the site, or to provide a "friendly URL" at which the user's content is posted, such as www.myphotso.com/johnsmith. Google has published research on how websites with E-mail based logins might take advantage of federated login. In this document, we provide some guidelines how websites with username based logins can still take advantage of federated login.
Most websites with username based logins still require a verified E-mail address at signup time, and it is used for communication to the user, as well as to recover a forgotten password/username. That E-mail adderss can server as the master key to support federated login. Based on that assumption, we make the following suggestions:
The RP should modify its login box to use the style publicized in our research, however the phrase "email address" should be replaced with either "username" or "username or E-mail address." The second option (username or E-mail address) maximizes sign-in and sign-up rates, however the first option (username) helps the user remember their username which can be helpful if the website tends to grow through word of mouth where end-users manually type the URL of their content hosted at the site.
The RP should then create a list of the E-mail providers it trusts who support federated login, including asserting the user's E-mail address. When an existing user logs in, if their E-mail address is from a trusted IDP, then the RP should promote the option to "upgrade" to federated login. If a user enters an unknown E-mail address or username in the login box, then the RP should display an account signup page which asks for a unique username, as well as an E-mail address. If the user enters an E-mail address from a trusted IDP, then the RP should promote the option to "upgrade" to federated login. The RP can detect such an E-mail either by using JavaScript on the account signup page, or by removing the password entry/verify boxes from the first page of the account signup process, and checking the E-mail after the user submits the first page.
If the user does "upgrade" to federated login then the RP should show them an "education" screen to remind them in the future to login by choosing "help me sign in." If a user who has enabled federated login tries to login using a password on the login box, then the password can be ignored, and the user should be shown a "re-education" screen to remind them in the future to choose "help me sign in."
Questions & Answers
>> What should the RP do if it decides to stop trusting an IDP in the future?
As long as the RP has verified E-mail addresses for the user, it can use that as a backup. The RP can send E-mail to all the user's of that IDP with one-time URL links that they can use to add a password to their account. If the user tries to login to the RP before adding such a password, then they can be sent through the traditional password recovery process.
>> Can the RP use a regular login box on part of its site, and the Google designed login box on other parts of its site?
No. If you do that, then some users will create an account via federated login on the sections of your site that support doing so. But if they go back to sections of your site with a regular login box they will not have a clean method for logging in.
>> To make the login box simpler, should the RP just display a login box that asks for username by itself?
No. The first problem is that it makes the login process a two step process for everyone, and it will cause some problems with browser autofill. Users really dislike this type of increased complexity in the sign-in process. In addition, such as login box still has to provide an option for signup, and the combined username entry + signup option is not that much simpler then the Google designed login box
>> Can the RP display a button for some of the larger IDPs it supports?
Yes. There is information about combining the buttons with the Google design login box in this document
>> Can the RP include buttons for IDPs who are not E-mail providers?
Yes, however this works best if the IDP asserts the verified E-mail addresses of its users, and the RP is willing to trust those assertions. Otherwise, if a user clicks that IDP button and comes back to the RP with a new federation identifier which the RP has not seen before, then it has to ask the user if they have a legacy account with the RP that they want to "upgrade" to be associated with this federation identifier. That question will be annoying to the majority of users who do are trying to just create a new account, so it should be avoided if possible.
>> What should the RP do if the user mistakenly enters a password for a username that has upgraded to federated login?
Show a re-education screen that reminds them in the future to click "help me sign in," and then give them a link to the IDP so their identity can be verified
>> What should the RP do if the user has an unverified E-mail address from the domain of an IDP?
Send them to the IDP, and when the IDP asserts back an E-mail for the user, replace the existing E-mail with the new value.
>> What should the RP do if multiple legacy accounts have the same E-mail address from a trusted IDP?
One option is to just not allow those accounts to be upgraded. Another is to upgrade the first one, and tell that user they must use the "help me sign in" option. If anyone tries to login to the other legacy accounts, they can be told that if they want to upgrade to federated login, they first must provide a different E-mail address at that IDP, or a different IDP. However if they don't want to upgrade, they can continue to login with the legacy password for that username.
>> What should the RP do if an account tries to upgrade to federated login, but the E-mail that is asserted back by the IDP matches one or more legacy accounts that have not yet been upgraded?
Allow this account to be upgraded. If anyone tries to login to the other legacy accounts, they can be told that if they want to upgrade to federated login, they first must provide a different E-mail address at that IDP, or a different IDP. However if they don't want to upgrade, they can continue to login with the legacy password for that username.
>> What should the RP do if an account tries to upgrade to federated login, but the federation identifier is already associated with an existing account.
Tell the user they must either (1) provide a different E-mail address at that IDP, or (2) provide an E-mail in a different domain.