OpenID with WordPress.com Hosting


It’s a neat concept: with all these blogging sites, why not have a cross-site login capability, so a WordPress.com user can “authenticate” themselves to another site (say, blogger.com) and post a reply – all without having an account there.  And their posting hyperlinks back to their main blog.  Excellent idea… too bad it doesn’t work better.

OpenID Providers and Consumers

In OpenID parlance, WordPress is an “provider” and Blogger is a “consumer” in the scenario above.  Essentially, Blogger redirects to the URL you provide, passing some kind of data “token”; you login to your own WordPress, and their OpenID server redirects you back to Blogger while passing back another “token” behind the scenes.  Through the magic of cryptography, Blogger trusts the WordPress server; therefore, Blogger trusts your identity.  The security community calls this “single sign-on” – you logon one time, with one ID, and go many places without re-authenticating.

With OpenID, your identity is linked to the provider – more specifically, the URL you provide when authenticating.  The OpenID consumer uses that URL to figure out where to authenticate you, so that URL becomes a significant part of your identity to them.

Advantages

Folks will argue that you’ve still got to login to your main OpenID provider, so what’s been gained?  A few things, actually:

  • You can login only once to your OpenID provider, and for the duration of that browsing session (or however they choose to work it) you don’t have to login again.  You may need to present your credentials to the 3rd-party site, but you don’t need to keep a database of passwords.
  • You use one ID and password for a group of sites.  You don’t want to create accounts in multiple places with the same ID and password – if one site gets compromised or is unethical, they can login as you elsewhere.  It does happen… I’ve learned the hard way.
  • Changing your password in one place instantly applies to all the sites.  You don’t need to login to each one and change them individually.  (You do change your passwords regularly, right?)
  • From a blogging perspective, the posts you make on other systems hyperlink your nickname back to your primary blog.  If you had IDs on each of these other systems, instead they’d link to your blog on their system, which would probably be empty.

Pitfalls

Foremost, you’ve got to trust your single sign-on provider.  They hold the keys to your world.  If their security is compromised, your password could be disclosed and the attacker could gain access everywhere you use it (and potentially know which places you use it).  Ideally, the provider doesn’t actually store your password in their files, just a “hash” of the password (like a signature) – they’d briefly see your password during the authentication, just long enough to compare it against the hash in their files.

Secondly, your URL becomes a significant part of your identity, and it ties you to the OpenID provider.  You can open an account with a different provider, but it means abandoning all the identities you’ve created on other sites – they’ll see you as a different person if you change URLs.  Consider your situation if your OpenID provider:

  • Goes bust
  • Has server problems (locking you out of other sites when you need it)
  • Has security problems (gets compromised)
  • Disabled your account, perhaps because they decide you violated their ToS agreement
  • Decides to start charging an unreasonable fee.

Lastly, if your blog has multiple admins, those admins can also login as you via OpenID because they can authenticate against your URL.  I don’t have more details on this, but I’ve seen it noted as a big precaution.

Mitigating the risks

Owning your URL seems to be the key here.  If you control the URL, you can swap the back-end OpenID providers freely (or potentially run your own OpenID server if you’re ambitious).  Since you can change OpenID providers without changing your URL, the change is transparent to all the sites where you login with OpenID.

To set this up, you need to add a couple HTML tags to the <head> section of the web page at your URL.  When the remote site opens your URL during the OpenID authentication process, it sees the “delegation” instructions for your OpenID provider.

Here’s a support article with info on the tags you need to add for delegation.  Unfortunately, those tags can’t be added to a WordPress.COM theme, since they can’t be edited.  But if you self-host a WordPress.ORG blog, then you’re in luck!

From a blogging perspective, owning your URL also gives you independence from your blogging provider – if you’re forced to move, it’s possible to relocate your blog content without changing the URLs (so all the links to your blog articles continue to work).  I can’t say how easy it is to port content between blog providers, but it’s possible to do it transparently.

Caveats with WordPress.com hosting

WordPress.com supports OpenID, but only as a provider and I wouldn’t say they really embrace it.  Your WordPress account is automatically enabled to be used as an OpenID login, with some very notable caveats:

  • WordPress.com hosting doesn’t reallysupport OpenID when you use your own domain name – you can login elsewhere using your own URL, but the URL that WordPress feeds back to the remote site is the WP URL for your primary blog, not the domain name you used for the OpenID login prompt.
    • The effect here is that your WordPress URL (not your custom domain name) gets used as the back-link when you post elsewhere, and if you ever move your blog all the back-links will break even though you paid for a domain name.  This is really too bad; it’d be easy to do, and should be standard when you pay for a custom domain.
      [8/27 update: 2 weeks later, WordPress.com replied to my support e-mail. They say this hasn’t been working properly, but should, and now it’s fixed.  At least with blogger.com postings, it’s still broken.]
  • WordPress.com doesn’t support multiple personas.  A great example I saw was someone with a primary blog about horses, and another for food – if they comment on another food blog but the back-link points to their horse blog, things make no sense.
    • myOpenID.com does support multiple personas, but I’m having trouble getting it to returnt he proper URL for the backlink.  It wants to return the profile URL at myOpenID, which is contrary to the whole reason for having multiple personas.
  • WordPress.com’s server passes your account name, not the nickname you provide, to the remote site.  This affects how your name appears at the remote site.
  • WordPress.com doesn’t support pointing (“delegating”) to a 3rd-party OpenID provider.  So, your OpenID is tied to WordPress, even if you pay for a custom domain.  Really too bad, because all these “missing” features are available via 3rd-party providers.
    • The alternative here is to signup with one of these other providers and map a different entry in your domain to that provider.  This works independently of WordPress.com, but it’s not as slick; I’d rather just delegate to the provider from my main blog URL.
    • I’ve done a bit of testing with myOpenID.com, and the persona feature is pretty slick. But getting a custom domain setup was more complex than needed (it’s only multi-user, not single user, which is odd).  When commenting on Blogger, I can now control my nickname, but doggone it if the website URL configured in the persona isn’t being passed back to Blogger, so Blogger is hyperlinking the nickname to… the myOpenID profile page – this is worse than before!

Conclusion

OpenID seems like a cool technology that’s become a walking corpse, but nobody’s willing to say so.  (Even e-mail to support@myOpenID.com is undeliverable, and they’re the “largest OpenID provider”.)  For as long as it’s been released the adoption should be better, the basic stuff should work, and it just shouldn’t be this hard to use a custom domain.  Heck, I couldn’t even find a diagnostic site to test logging in against, that would give some clue where the issue is.

[8/27 – The test server at http://www.openidenabled.com/resources/openid-test/diagnose-server/ is working now.  It’s helpful, but not as much as I thought.]

It’s cool that WordPress.com offers some OpenID provider services, but I think they’re too limited to be useful.  I don’t want to build a dependency on WordPress.com that will trap me in the future.  I’d love it if they supported OpenID delegation – at a minimum to properly handle custom domain URLs; ideally also supporting delegation to a 3rd-party.  I don’t think I should have to pay for this on top of the annual domain charge, but I’d consider it.

As it stands, I’m still stubborn about getting OpenID working properly with WordPress.com because I want my comments elsewhere to hyperlink to my blog, preferably via my custom domain URL.

About these ads

7 Responses to “OpenID with WordPress.com Hosting”

  1. Great post. I’ve replaced the shutter and with great care, everything has found its place and the camera seems fine.

    With one exception… the shutter fires and sounds right, but the err message comes up. On the next shot, the shutter sounds only like it’s closing (like after a time exposure), and err is gone. Both frames are black. Every two shots repeat that pattern.

    It seems that the curtains are out of sync. Could this be an issue of the charging lever being in the wrong position? Should the shutter be charged or rested when it’s put into place? Or, is there another setting to consider?

  2. Sorry, my last post was left in the wrong place.

  3. Have you tried talking to anyone at wordpress.com? I’d like them to extend their OpenID implementation a little bit more, too, so you can set a display name.

    The nice thing about using wordpress.com for hosting is I never have to worry about keeping the server up, but alas, I’m stuck with their server :(

    • Erik – Yep, I posted a support inquiry and it didn’t get very far. Some of my issues are features they just haven’t implemented, and others are because OpenID leaves some things to the discretion of the OpenID “consumer” (e.g., Blogger.com choosing which returned field it uses as the ID, rather than the one I entered when logging in).

      It really doesn’t make sense to me that wordpress.com won’t pass my custom domain during OpenID authentication, rather than my wordpress.com URL. It’s also really unfortunate that they don’t support OpenID delegates, which would let me redirect to an OpenID provider that’s more feature-rich (while still using my custom domain name) – if wordpress.com doesn’t intend to enhance their OpenID offering, they could at least offer the option of delegating to a 3rd party.

      Cheers,
      Richard

      • Somewhat similar situation: I used my WordPress.com as my OpenID provider but I now moved to my own self-hosted WordPress installation, with “Offsite Redirect.” It seems like OpenID isn’t working when the redirect is on (but it does work when I turn off the redirect). So, if you got any news on this, I’d appreciate.
        Otherwise, I’ll just switch each account one by one.

  4. I had the same bad experience! any i got my openid sucessfullt running

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: