DHH, who is promisingly writing a Rails plugin for OpenID with Rick and others, has made a case for applications to store a user’s openid_url in place of their username, and present a unified login form which hides or reveals the different processing of openid & password logins, based on the presence of the http prefix.
When users start typing an OpenID identifier URL into the username field, the web app transparently turns it into an OpenID login action.
The common implementation today is to add an openid_url field alongside the existing user data, provide a login screen that offers regular and OpenID login, and often internally maps OpenID’s nickname (from the Simple Registration Extention) to the username/login.
What are some pros/cons to the proposed overloading approach?
Pros
- For users, the the login or signup screens aren’t complicated further with another visible alternative
- As a developer, you don’t have to use an additional field in the database
- As a developer, you don’t have to deal with potential uniqueness conflicts between one person’s OpenID nickname, and another person’s username (which may require an additional username/email form to be presented during account creation in the case of a conflict)
Cons
- According to Spec (s 3.2.1), the user shouldn’t be required to prefix their identifier with http (basically, a usability issue)
- The gentleman’s standard (also in the spec) of naming the form field “openid_url” to allow it to be auto-populated across sites is lost.
- Both OpenID users and traditional users may be confused by the overloaded form. If the OpenID logo is displayed, it doesn’t have a natural home which won’t confuse one party or the other
- The application no longer has a place to store a friendly name for the user. So views display a URL, which will typically be much longer than a username, and require some additional view logic to turn into a link
- OpenID accounts are at a privacy disadvantage vs. username/password accounts, because their visible username tracks directly back to them
- For the developer, the code for the two authentication methods (password, openid) becomes even more coupled
Wrong on anything? And other major pro/cons missed?
On the whole, what’s common with current implementations (separate openid form on the login page for the user, separate openid field in the database for the application) is both in line with the spec, and still the better compromise. As the core team’s Rails Plugin quickly evolves, expect details and directions to change.
