What the heck is OpenID?
Following a discussion on my post about using OpenID with Web.py, I decided to write up a little description of what OpenID actually is and how it works, because there’s a lot of confusion, and it really doesn’t need to be confusing at all!
We most often think of logging into a website as entering our username and password. This is fine (well, disregarding other security concerns), but it really sucks to have to manually log into EVERY site you use—Facebook, Stack Overflow, Google Documents, etc. etc. etc..
OpenID is a way of “letting someone else do it.” Say you’re developing a new website—we’ll call it blinky.org—that requires a user to authenticate herself to use the site. Instead of writing the whole authentication backend yourself (including using an existing library for such), you can let an OpenID provider handle it. This means that when you go to login to blinky.org, there is no username/password field.
Instead, it asks you to login with someone else, like Facebook, Google, Yahoo, or any of a slew of other OpenID Providers. Say you choose Facebook. If you’re already logged into Facebook, you’re done—you’ve authenticated with blinky.org and go on your merry way. If not, you’re forwarded to Facebook’s login scheme, login and return to blinky.org. And that’s it!
Now, the confusing bit is the OpenID Provider URI (Universal Resource Indicator). This is the path to the provider’s implementation of OpenID—not something your typical user is going to have ANY idea of. Our user interfaces should provide a group of typical providers as buttons/links, and have an optional field that is hidden by default to specify a specific provider’s path.
Stack Overflow, for instance, has nice provider buttons, but also the URI field, which is conflicting and confusing. Instead it should have an “Other…” button that then shows the field.