TechWandering random header image
TechWandering
TechWandering
wandering the world of technology
wandering the world of technology
 

 

Log into OpenID sites using your own URL

October 19th, 2007 · 7 Comments

In a previous post I talked about the benefits of OpenID-enabled web sites. In a nutshell, OpenID promises to let you use the same logon credentials across multiple sites rather than having to create a new username and password at each site you visit. If you manage your own web site (or even a page on a web site) you can use your site’s URL instead of your OpenID provider’s URL. That means that you can log to OpenID-enabled sites using a “friendly” OpenID name (something like “techwandering.com”) instead of your OpenID provider’s name (like “techwandering.myopenid.com”). Here’s how.

An OpenID Refresher

OpenID is a distributed system which allows users to log into an OpenID-enabled web site using an OpenID URL instead of the traditional username/password combination. The idea is that a user can choose their OpenID provider and use that provider to log into any OpenID-enabled site. Think of it as a way to allow a web site to outsource its login procedure to a third party.

Using your own web page

The way we’re able to use our own web page URL instead of our OpenID provider’s URL is by adding an extra “hop” to the whole OpenID authentication process. You’ll remember from the original post about how OpenID works that the normal flow of an OpenID logon goes like this:

  • The user navigates to an OpenID-enabled web site (like http://wikitravel.org)
  • Instead of entering a normal username/password combination, the user enters his OpenID username (like techwandering.myopenid.com)
  • The web site parses the OpenID username and redirects the user to their OpenID provider (in this case, to http://myopenid.com)
  • The user logs into his account at the OpenID provider
  • After successfully logging in the user gets bounced back to the original web site (http://wikitravel.org)
  • The user is now logged in

An Example

Using the example above, let’s say that I have an OpenID account named “techwandering” at the OpenID provider myopenid.com. That would make my OpenID login “techwandering.myopenid.com”. I could go to any OpenID-enabled web site (like WikiTravel.org) and use that URL to log into the site. Although that URL works, it’s a bit “wordy”. Since I can edit pages on the TechWandering web site I can set make a change to the main page which will allow me to use the URL “techwandering.com” to log into my “techwandering.myopenid.com” OpenID account using an OpenID feature called delegate.

To do that we’ll have to add a bit of code into the HTML of the main page of TechWandering. The code goes into the <head> section of the page, and it looks like this:

<link rel=”openid.server” href=”http://www.myopenid.com/server” />
<link rel=”openid.delegate” href=”http://techwandering.myopenid.com” />

Here’s the flow of our OpenID login now (the additional steps are in bold):

  • The user navigates to an OpenID-enabled web site (like http://wikitravel.org)
  • Instead of entering a normal username/password combination, the user enters his OpenID username. In this case I’ll enter the URL “techwandering.com”.
  • The web site parses the OpenID username and redirects the user to their OpenID provider (in this case, to http://techwandering.com)
  • The web site at techwandering.com does not indicate that it’s an OpenID provider. At this point the OpenID processor at WikiTravel looks for the two <link> tags listed above. The first <link> tag tells the WikiTravel server what OpenID server to use to process the login. The second <link> tag tells the OpenID server what username “techwandering.com” actually translates to at that provider.
  • The user is redirected to the “real” OpenID provider (myopenid.com)
  • The user logs into his account at the OpenID provider
  • After successfully logging in the user gets bounced back to the original web site (http://wikitravel.org)
  • The user is now logged in.

Use any page

The nice thing about this approach is that I’m not limited to using the root page of my web site. Instead of using “techwandering.com” as my OpenID login I can use a subdirectory under that root — for instance, I can use “techwandering.com/frank” or “techwandering.com/ralph”, or even “techwandering.com/george/myopenidpage.html”. As long as you can edit the HTML of a page you can use that page as your OpenID username.

Change OpenID providers without changing your OpenID login

Using this OpenID redirection approach also gives me additional flexibility when it comes to choosing my OpenID provider. In our example I’ve logged into WikiTravel using the OpenID “techwandering.com”, which actually translates to the OpenID “techwandering.myopenid.com”. The WikiTravel web site knows me by my “techwandering.com” name, and any preferences I set at that site are linked to that username. Let’s say that, at some point in the future, the folks at myopenid.com decide that they’re no longer going to be OpenID providers. If I had an account at WikiTravel tied directly to my techwandering.myopenid.com account I wouldn’t be able to log into my WikiTravel account any more. But since I used techwandering.com as my OpenID name I can just create another OpenID account at another OpenID provider and change the code in the <link> tags on my web page to point to that new provider instead of to myopenid.com. The next time I log into WikiTavel it bounces me through my new provider instead of through the old provider. From WikiTravel’s perspective I’m still logged in as techwandering.com, regardless of what my underlying OpenID provider turned out to be.

Some Examples

Remember, the values in the <link> tags of our example tell the OpenID processor two things:

<link rel=”openid.server” href=”http://www.myopenid.com/server” />
<link rel=”openid.delegate” href=”http://techwandering.myopenid.com” />

The first link above tells the OpenID processor where to go to find the OpenID provider. The second link tells the processor what the full OpenID username is going to be when the user gets to that OpenID provider. Here are two examples using other OpenID providers:

using Verisign Labs (http://pip.verisignlabs.com) as an OpenID provider:

<link rel=”openid.server” href=”https://pip.verisignlabs.com/server” />
<link rel=”openid.delegate” href=”http://techwandering.pip.verisignlabs.com” />

using SignOn (http://signon.com) as an OpenID provider:

<link rel=”openid.server” href=”https://www.signon.com/openidProcessing.action” />
<link rel=”openid.delegate” href=”https://techwandering.signon.com” />

Conclusion

If you’re a user of OpenID and you own some sort of web page go ahead and try out using that page as your OpenID identifier — it makes remembering your OpenID easier and it insulates you from being bound to a specific OpenID provider. And that makes an already open system even more “open”.

Related Posts