OpenID, baby!

OpenID LogoA post on Intertwingly (Sam Ruby’s blog) brought me back to the idea of single sign-ons. A year and a half ago I came up with SPTP, the Simple Profile Transfer Protocol, which turned out to have a major flaw. Then I looked at SINP. But the problem is that it’s kind of hard to get a new system off the ground.

And honestly, there already is a system that is pretty slick.

It is called OpenID and it gets more and more support. The idea is that you login to OpenID-enabled sites using a URL that you own. This URL links to an OpenID server where you have an account to authenticate you. If you look at the HTML code of zefhemel.com right now you will see two new tags in the head: 

<link rel="openid.server" href="http://www.myopenid.com/server"/>
<link rel="openid.delegate" href="http://zef.myopenid.com/"/>
This means that if somebody (me) uses http://www.zefhemel.com to authenticate somewhere, the MyOpenID servers will handle this authentication. MyOpenID is a free service where anybody can get an OpenID, you don’t need a website, by default you get a http://username.myopenid.com address. You can use this address to login to any OpenID-enabled website, or you can link your current website to your MyOpenID account (like I did). On MyOpenID you just fill in your profile (you can create multiple), with information that you want to make available to the services you will use your OpenID for.

Authenticating on OpenID services is easy. You simply type in your OpenID URL and press login. That’s it. The first time you do this, the OpenID service will ask you to authorize this service to get access to your user information, you can authorize once, forever or decline. It’s that easy.

What makes or breaks a system like this, is whether services actually use this. More and more services start to support OpenID. A few examples:

There are a number more on MyOpenID’s directory page. There is also a WordPress plugin.

If you’re developing a web application, consider supporting OpenID. There are libraries available for most programming languages so it shouldn’t be that hard to integrate. It would make a lot of lives easier if you would.

This entry was posted on Wednesday, January 24th, 2007 at 11:42 by Zef You can follow any comments to this entry through the RSS 2.0 feed.

  • Hm. Having multiple _single_ signons would be a bit of a contradiction.

    I think I'll first write a SINP server that also acts as a OpenID server. And a client library which works via SINP or openID.

    (When I got time :))
  • I'm not sure if I would spend my time writing bridges between authentication systems, but it could be interesting. But as the amount of data we're talking about here (profile data for now) is fairly limited I would be tempted to just create an account once with the major single sign on providers out there. There are not that many that are being widely used. I have a Microsoft Passport, I have OpenID, I have a Google account. That's all I need.
  • Martin Atkins
    It's actually pretty easy to create bridges between OpenID and other browser-based auth technologies. See my blog entry on the subject for a quick summary of how it works:
    http://www.apparently.me.uk/2767.html

    My take on it is a proxy that allows you to another auth provider as an OpenID IdP via the proxy, but I imagine you could probably do it the other way too if you want, depending on the flexibility of the other protocol.
  • It's tempting to suggest (in my opinion improvements) borrowed from SINP to OpenID, but I'm afraid they are already too big for drastic changes (they'd loose users) and not big enough to cope with that.

    It's tempting to work on SINP again, but SINP hasn't got any momentum at all. (Ok, I'll be honoust. I really didn't work on it anymore)

    Jabber has got this really great thing that are called gateways. You can chat with someone using msn via a gateway server with jabber. Maybe it would be nice to implement this for SINP/OpenID. (and all those others)
blog comments powered by Disqus