Overloading username and openid_url

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?


  • 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)


  • 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.

Comments (7) to “Overloading username and openid_url”

  1. The less fields, the better!

    Removing at least three of those cons is quite easy. Neither http:// has to be arbitrary nor the username has to be the URL.

    Check out the bottom of http://test2.phpbb.cc/

  2. I don’t like the idea of having the same field for local usernames and OpenIDs. It might confuse users if they see a password field and they type in their password, although we should tell them to never use their password on a site different from the OP (phishing!). If both are enabled on a site, they should be clearly seperated. I can’t see how that could confuse a user.

  3. One possibility is to make the following assumptions: Usernames should never contain a fullstop “.” character, and an OpenID (because it contains a DNS domain name) must contain at least one.

    That way, the form can use Javascript to dynamically determine whether the “Username or OpenID:” field currently contains an OpenID or not; and disable or enable the “Password:” field as this changes.

    Thus, the user gets immediate feedback, while they type in their OpenID, that the Password field is not needed. Those who are logging in with a regular username + password see the form remain the way they expect.

    What do you think?

  4. Of course, there may be cases where a username value *will* contain a fullstop (e.g., where the username is firstname.lastname); and there may be cases where the DNS hostname of the OpenID contains no fullstop (because the application and OpenID provider are both within a local network where hostnames are regularly typed without a domain part).

  5. Great comments. For a combined login form, I liked the look of yours Dmitry (note the link isn’t working right now, your host is saying ‘exceeded bandwidth limit).

    This is a good time to experiment with this stuff. It’s too early to settle on one, true way — although we have to watch confusing and turning users off on OpenID completely.

    I’ve struggled with how to implement OpenID side-by-side with password authentication, both to the user, and internally in the application.

    Right now, I’m in the traditional camp of having separate openID and password login forms which may, of course, be displayed on the same page.

    And on the internal side, I do believe password authentication and openid are often going to be supported together, I’m in the camp of having as cleanly decoupled implementations as possible. Sometimes easier said than done.

  6. Indeed. I need a better host…

    The link should work now, check it out. DHH already has. ;)

  7. My principles for thinking about models is that they should mirror the real world as well as possible. In the real world, a username is not necessarily my name. It could be a number. I should be greeted and represented to others via a nickname, not an identifier. Also, an openid_url is an identifier, and since it links to the ‘official online representation of me,’ it shouldn’t be displayed everywhere. Use a nickname. And hey, why don’t I make my app allow me to type in my _nickname_, then look up my openid and authenticate me with that?

    This is who I am: username
    This is how you can authenticate me: openid_url
    This is what you can call me: nickname
    (or combine username and nickname if you wish)

Post a Comment
(Never published)