I’ve just implemented OpenID sign-ons for a client site, as a compliment for the standard signup/login process, and I choose the following association:

1 x User account —> 0 or 1 x OpenID

The OpenID value is a field on my User model/table.

So I login with my OpenID and I get one application account.

Or similarly, if the User already has an account, there is a field on their User settings page for their OpenID. They can put in their LiveJournal or AOL OpenID URL (or from one of 3000+ OpenID providers) there, and they can now log into that account using either normal login, or OpenID login.

Great.

But then I was watching a GoogleTechTalk video by Simon Willison and he gave the following Bonus Use of OpenID:

1. User logs into a site using an AOL OpenID
2. The site can now send AOL IM messages to that user

This is cool for two reasons:

1. The site automagically derived information about the User – they are an AOL member, and their AOL username.
2. More importantly, it KNOWS the user is the owner of that AOL account.

The site gets authentication of this information for free through the OpenID sign-in process – the user is redirected back to AOL’s OpenID page at which time the user has to prove they own the account thru AOL signin (or cookies).

So, back to my story.

My users can sign into my site with an AOL OpenID and prove they own an AOL IM account name.

What if they also have a LiveJournal account? LiveJournal URLs are all OpenID URLs too [1]

If they signed in with LiveJournal OpenID then they could prove they have such an account and my site could do funky LiveJournal specific things… like… read the user’s blog for them… ok, this example is going nowhere.

But! What is your MSN/Live account had an OpenID associated with it? Or Google Account? Or Yahoo Account? All have IMs associated with them. OpenID login could prove ownership of that information.

But…

My user has already logged in with AOL OpenID.

Stupid 1-to-1 data model of User and OpenID. Bah!

Solution: allow Users to have 0+ OpenIDs. Some quick refactoring and you’re done.

Your controller code (the standard Rails solutions for OpenID support use a sessions controller to manage the OpenID provider interactions will now have to do a small amount of extra work.

Small.

Like, you’ll need a table of known OpenIDs and a belongs_to foreign key to the User model/table.

Small.

But perhaps you are already doing this and I’m the only silly sausage around here.

Even if you don’t see the benefit of these use cases – trusting the information from the OpenID profile – here’s a more common use case I think we’ll find:

Users will want to sign-in with whichever OpenID makes them feel the happiest at the time.

I’m feeling some AOL love today, I’ll use http://openid.aol.com/iamawesome

I’ll use iamawesome.myopenid.com here as its got my Age and Country setup already.

And the poor user will instantly get 2 accounts with your application – on top of the account they already had. That’s 3 accounts.

Unless we do the following:

• Allow “new” OpenID sign-ins to select an existing application User account to connect to – don’t make the poor user feel stupid for using OpenID – help them connect it to their existing information.
• As above, allow multiple OpenIDs to be connected to each User account

OpenID allows its Providers to return additional information beyond [name, email, etc] [2]. So different OpenID profiles might store different bonus information.

AOL might expose my AOL buddies list.

LiveJournal might expose my LiveJournal buddies.

A user could login to your app with both OpenIDs, connect it to one User account, and re-use all their buddies within your app.

Its awesome, and its the “Social OS” that everyone’s harping on about.

Its the future. And its not Facebook.

[1] [History lesson] Live Journal – now owned by A List ApartSix Apart – invented OpenID. [/History Lesson]

[2] Through a draft specification OpenID Attribute Exchange; very nifty indeed as the raw OpenID1.1 spec has very limited profile data sharing. Like none.

Related posts:

1. Zero Sign On – 1 better or Infinitely better than Single Sign On? This article has no code in it. There are no...
2. Why supporting multiple OpenIDs per User is useful for users… Web apps/services go down for maintenance (expected or erroneously) all...
3. RailsRumble hates OpenID There are 146 RailsRumble entrants. %w[rubygems hpricot open-uri].each { |l|...