Dr Nic

One App, One User Account and Multiple OpenIDs

Summary: Its the future, and its not Facebook. Learn it.

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|...
  4. MagicCGI shows OpenID user count In the last 20 days, 43 people have used...
  5. One year on the InterTubes Dumping thoughts onto the InterTubes, aka blogging, is fun. And...

23 Responses to “One App, One User Account and Multiple OpenIDs”

  1. Brian says:

    Any good tutorials out there about not only implementing the openID, but extracting relevant information from the given site? I can only see one problem, with 3000 providers out there, wouldn’t that essentially mean 3000 apis that you’d have to be able to interface with?

  2. Dr Nic says:

    @Brian [via] – its better than that – 3000 providers with 1 API – the OpenID API.

    At the moment some of the stuff I mention above is “draft” and no one has implemented it (friends lists etc).

    Perhaps there are some interesting links under my del.icio.us bookmarks for ‘openid‘.

  3. scott says:

    [correction]Six Apart owns LiveJournal[/correction] (not to diminish the awesome of A List Apart)

  4. Dr Nic says:

    @scott [via] – doh, I get confused easily, apparently :P

  5. Brian says:

    the only thing I see as a problem would be the fact that the friends or any asset list would only be valid if they logged in with an openid of the same domain. E,g, I could login with my aim account but if my friends did, they would only be listed as my friends if they used their aim accounts as opposed to their livejournal accounts or some other source.

  6. Dr Nic says:

    @Brian [via] – I’m scheming some cunning plans about these issues.

  7. Brian says:

    @Dr Nic [via] – Let me know what you come up with, I’m looking forward to it.

  8. Dr Nic says:

    This article on implementing OpenID confirms that I might be the only silly person thinking 0-1 OpenIDs per User was sufficient.

  9. ende says:

    Simmon Wilson presentation is really nice! And I never felt comfy with facebook… OpenID is the future.

  10. tommorris says:

    LiveJournal OpenID usage can give you the person’s FOAF profile…

  11. Dr Nic says:

    @tommorris [via] – it can, though I think that’s an inconsistent API to match the OpenID API.

    Plus, currently LiveJournal’s link to your FOAF file is on your public page.

    With OpenID, requests for new profile information should be redirected back to the OpenID provider so you can click “Allow Forever” for each field, etc. Or for each friend, or each group of friends, etc.

  12. [...] The next thing I want to do is work more on profile managment, offer some of the OpenID Simple Registration fields, and look into supporting multiple auth IDs linked to the same user profile. [...]

  13. jayshao says:

    I think the key distinction you’ve hit upon is separating the credentials (what the user uses to prove they’re them) from their account. That way, users can give multiple sets of credentials, but that get bundled into the same experience. e.g. I could give you my AOL screenname, Livejournal ID, University id, and all of those could include various attributes about me: buddy list, FOAF, student status, and claims that prove these things to the site, and get added to my account.

  14. Squeegy says:

    But isn’t one of the major selling points of OpenID to have a single login? And the real value comes when you make your own URL a delegate to your provider.

    It seems to me that it might be better to allow 1 OpenID, and allow them to manually set their their AIM, and other info. I shouldn’t have to login with multiple OpenID’s just to get the functionality of their providers.

    It strikes me that this OpenID stuff is still so new we don’t have a widely accepted set of best practices for application integration just yet.

  15. Dr Nic says:

    @Squeegy [via] – if you only need one OpenID to get around the world of the InterTubes, then that’s great. I’m sure that fits my profile too.

    It seems an interesting idea though: as more service providers make their user accounts available as OpenIDs, that apps can use this mechanism as a built-in “prove you have an account with app XXX” by giving me your OpenID, and then making them signin with it.

    Currently, sites like Flickr implement their own “will you let your Flickr account be used by external application YYY?” mechanism. Perhaps they could just give everyone OpenIDs (http://openid.flickr.com/drnic) and then upon login to Flickr OpenID via the 3rd party app.

    To be fair, this use case isn’t well thought out by me, but its intriguing.

  16. NeilW says:

    To me OpenID is a way of getting authentication without having to do any password encryption.

    I see little reason why you can’t associate several logon systems of whatever type with one account, whether they are OpenID or some other authentication protocol. Perhaps Google/Yahoo/etc. will open up their authentication systems at some point.

    And of course a user may have several URLs for the same OpenID with the redirection capability. And I might forget which one I’m using today.

  17. justin says:

    so, any rails plugins or tutorials to help making an application an openID provider?

  18. justin says:

    Actually any HTML document can be used as an openID identifier seperate from the actual Identity Provider. You just add

    to the head of the HTML. (Section 3.1 of http://openid.net/specs/openid-authentication-1_1.html)

    So, service A could add that tag to all user pages. Then when the user signs up for service B and provides their service A identifier page, service B would know the user owned that account over at service A.

    This all would happen with a single openID provider. So, I answered my own question. Sorry to work that out for myself here:-)

  19. Dr Nic says:

    @justin [via] – but there is some example code around for an OpenID provider; though I haven’t played with them much.

    There is a server within the ruby-openid gem (lib/openid/server.rb) and there is a full-blown OpenID provider application built by EastMedia Group and Verisign, called PIP, which I think was shown off at RailsConf2006.

    Note, when you setup the PIP app, I discovered it only runs on Rails 1.1.6, not 1.2+

    If you play around with these, let me know what you find.

  20. justin says:

    That section of the spec I pointed to should have been 3.1.1. Delegating Authentication.

    I’ll take a look at PIP. I wonder if there is an advantage to actually being an identity provider versus delegating authentication on user pages to other identity providers… for the purpose of saying ‘yes, that user has an account here and he owns that url’ delegation seems less hassle.

  21. Dr Nic says:

    @justin [via] – you can use other openid providers to allow users to login, regardless if you then turn around and let your users use their app accounts to be OpenIDs themselves.

    That is, say your app is kiteflying.com. I use drnicwilliams.com as my OpenID to register/login to kiteflying.com.

    Now it turns out that drnic.kiteflying.com is also an OpenID url (it could be a delegate like drnicwilliams.com is to myopenid.com, or kiteflying.com could be an OpenID provider itself).

    But the point is that your app can be a consumer of OpenIDs and a provider of OpenIDs independently.

  22. Dr Nic says:

    The 2nd last sentence doesn’t make sense… doh.

    Let’s say kiteflying offers OpenIDs for each of its users via their profile page (say drnic.kiteflying.com). Alternately, as suggested above, perhaps the profile page allows me to delegate the url to a different OpenID provider like I do with drnicwilliams.com. But that’s off topic here.

    So kiteflying can accept OpenIDs for ppl to login/create accounts, but can then turn around and let those accounts be OpenIDs themselves.

    Is that any clearer? :)

  23. justin says:

    Yup, that’s what I meant – kiteflying.com doesn’t have to be the OpenID Identity provider to provide a kiteflying.com openID for their users, they can delegate that to aol, claimid, myopenid, whatever service the user has designated.

    Off to build kiteflying.com now…