Tag Archives: OpenID

There is a well-established “grammar” for how we sign up and log into websites. Provide your name, email and password; verify the email; login to the site with username and password until you’re timed out. You know the drill. But a wave of new web apps and protocols is challenging the status quo, breaking the traditional interaction patterns. In some cases, they blur the distinction between logged-in and logged-out status; and in others, they provide ways to perform privileged actions without explicitly logging in.

Before we walk through these new interaction patterns, let’s be clear about the “old” pattern we’ve come to know and (sometimes) love. It starts with visiting a new site:

use the site anonymously. Nothing you do yet is persistent; you can look (sometimes), but you can’t touch.

sign up by providing username, email, and password. (variants: email is *username*, password is auto-generated)

click on link in verification email

now you can log in by providing username/password and logout by clicking the logout button or by explicitly timing out

Right, you know that sequence and it works okay. However, problems remain:
– barriers to signup: perhaps the biggest problem faced by site owners is getting users to sign up. A known, authenticated, user gets a much richer experience, can contribute in mire valuable ways to the community, and can receive targeted services, not to mention targeted ads.
– barriers to login. Users might have signed up at one stage, but rarely sign in due to the hassle factor, a factor that multiplies when they have forgotten their password.
– timeout. For security reasons, timeout must happen and that will frustrate users and see them going elsewhere.
– mobile access. My dear reader may well bear the latest and greatest web-enabled digital communications circuitry in thir pocket or handbag, but the majority of phones still lack a basic web browser. Even when you do have a browser, it’s difficult to login, especially if you are using suitably complicated passwords. There’s something to be said for more fluid models of mobile-webapp interaction.

Lazy Registration (NetVibes)

In Lazy Registration, an anonymous user is allowed to interact with the site right away, and through the magic of cookies or unique URLs, the site builds up a profile before the user even signs up. Once the user does sign up, they take their existing (hencetoforth anonymous) profile with them. The benefit is clear: the ability to start playing with the site without incurring the overhead of registration. The better e-commerce sites do this by letting you add to your cart as an anoynomous user; where most of those fail is they completely time you out after a short time. See Partial Logout below …

Unverified User (Flickr pre-Yahoo!)

Here is another pattern that defies the traditionally strict dichotomy between those who are in and those who are out. You sign up as normal, but you don’t have to verify the link straight away. There’s effectively an “email verified” flag against your name and unverified users only have partial rights, e.g. You might be able to start maintaining content, but no-one else can see it until you’re verified. The benefit here is eager users can get going right away, and have a reason to click on the verify link when they come across it later. (I’m afraid the only example I can think of is Flickr’s Guest Pass concept, before they tied login to Yahoo!. I’ve seen it elsewhere, but can’t recall where!)

Partial logout

Something like a rewind of Lazy Registration, the Partial Logout pattern allows for differing degrees of “logged-in-ness”. Once a user has been idle a while, instead of completely timing them out and making them anonymous again, the system continues to “sort of” trust them by letting them view some things and keep building up some aspects of their profile. In this state on amazon, you can view your shopping cart and personalised rexommendations, and products you view will be fed into your profile; but try and purchase a book or change your credit card details, and you’ll be faced with a login form. Timeout is the main reason to be partially logged out, but it might also be something else which leads the system to believe there’s a risk the browser is no longer under the user’s control; for example, the user logs in from somewhere else.

Device-Driven Interaction (SMS-Twitter)

You can tweet from Twitter.com or any number of web and desktop clients, but one of the main driving forces for twitter was the ability to say what pure doing wherever you are, a perfect example of SMS-driven authentication, and the reason why tweets are limited to 140 characters (leaving room for a username as well). The verification is all thanks to the caller ID. There are interesting international implications since the recipient pays in the US, while most other countries run a model where the sender pays. And when the sender is roaming abroad, they always pay to send. And it’s usually an absurd amount.

A variant is MMS-Driven Interaction (e.g. Joomla MMS module, although its cost – and immaturity in the US – makes it less viable. The more general way to depict this pattern is to see it as Device-Driven Interaction, where your possession of the device is used to authenticate you. Thus, a variant would be GPS-Driven Interaction, such as Google Latitude.

Email-Driven Interaction (Posterous, Tripit, Twitpic)

Email-driven interaction is becoming really popular lately; Posterous especially is taking off right now. In the simplest case, it’s just emailing a new post to your blog, to a secret destination address you can see on the web page when you logged in. Where all this gets more interesting is when you don’t even have an account yet! You simply send an email to their generic address ([email protected]; [email protected]) and you’re up and running. In Posterous, you can also reply to comments from the comfort of your mail client too. All this is fantastic in a mobile context, where it’s often more convenient to fire off an email from your camera app than log into the website and upload it. It’s also cheaper than sending MMS content around too. Of course, these services still let you log into a website the regular way too; they’ll send you a link that gets you in the first time. Of particular interest is their use of simple, public, addresses. It raises the distinct risk of spoofing to act as someone else, but in practice, the services seem to be smart enough to thwart such attacks. Somewhat. So far.

Secret URL (SlideShare, Skitch)

A secret URL is “the login you’re having when you’re not having a login”. (Which makes it a “Claytons login” in Aussie vernacular). A privileged user can see the secret URL, it being a long unguessable string, and can then distibute to trusted others. The chief benefit is no-one needs to log in. From the owner’s point of view, they don’t have to tediously list everyone who can see the resource, and it’s more granular than just “only show my friends” if you already have a list of friends. Also, the owner can access it from any device or browser just by knowing the URL, and without worrying about timing out. Secret URLs are especially nice in a real-time setting (Web 3.0, here we come), where you want your friends to converge on a website for closed communication and collaboration. The main downside of course is that it’s simplistic, offering rather limited security, and in most implementations the resource must be treated as read-only, as you don’t want to let people change something unless they can be held accountable for their actions. Skitch’s settings for an individual image are shown below:

Federated (open id-e.g. StackOverflow; Facebook Connect-e.g. CNet)

Federated login, most famously exemplified by OpenID, allow for a single identity across the internet. You authorise sites with your OpenID provider, and you only need to log into your provider to access those sites. More recently, Facebook Connect provides its own brand of federated login, which is conceptually easier and simpler for users, at the cost of tying their identity to a single provider. So while purists are grizzling about lack of openness, mainstream users right now seem happy to sign in to sites with Facebook Connect, as opposed to signing up to the site separately. And sites seem keener to integrate Facebook Connect than OpenID, probably because the story is clearer for end-users, and there is a tie-in to Facebook too (e.g. site activities can show up on the user’s Facebook feed). Facebook supports OpenID login, is now on the OpenID board, and will probably become an OpenID provider at some stage.

Special Mention: Delegated authority (OAuth-e.g. Twitter)

In a somewhat separate category is OAuth, the protocol that lets you delegate authority from one site to another. It is sometimes likened to giving someone a valet key, i.e. they have partial authority at your discretion and you can revoke it any time. For example, an OAuth-powered Twitter mashup will redirect you to Twitter, where you tell Twitter you accept certain actions being conducted with your account by the mashup. From that point on, until you revoke it, the mashup will be able to work with your Twitter data as if it were you. All this would be possible if the mashup asked you for your username and password, but OAuth offers a more secure model because you can moderate, track, and revoke privileges at any time. In that sense, it is unlike the other techniques here as it is less about making the service more convenient or user-friendly; and more about allowing for extra functionality by third parties, and with a hardened security model.

OAuth, OpenID…they sound like the same thing and they kind of do vaguely similar things But I’m here to tell you, OAuth is not Open ID. They have a different purpose. I’ve been playing around with OAuth a bit in the past couple weeks and have a grip on what it’s aiming to do and what it’s not aiming to do.

To start with, here’s what OAuth does have in common with Open ID:

They both live in the general domain of security, identity, and authorisation

They are open web standards. Created and evolved by people with an itch to scratch and evolved pragmatically by a loose, fluid, alliance. Think REST, not SOAP. Think Bar Camp, not The 25th Monosemiannual International Convention for the Society of Professionals who Devise Acronyms Quite a Bit.

They both celebrate decentralisation. There is no central Open ID or OAuth server that holds all the security information in the universe (cf Passport). Anyone can set up as a server or a client.

They both involve browser redirects from the website you’re trying to use – the “consumer” website – to a distinct “provider” website, and back again. Meanwhile, those websites talk to each other behind the scenes to verify what just happened.

The user can actively manage the provider website, exerting control over which websites can talk to it and for how long.

With that much in common, the casual observer could be forgiven for confusing them. But they’re different. Not different as in “vying to be the no. 1 standard”, but different as in “they let you do different things”. How so?

Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr.
OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.

With OAuth, you still need to log into the provider. e.g. When Moo sends you to Flickr, you still have to log into Flickr (or be logged in already). How Flickr decides you’re logged in is completely orthogonal to OAuth. It could be a standard username-password login, it could be via a physical password device, or it could well be via Open ID.

With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you, e.g. some photos, addresses, phone numbers, etc., and with your consent, send it back to the consumer so you don’t have to re-enter all the boring profile details again. However, this is data of a generic, non-application-specific, nature. (And even this limited form of sharing is an extension to the core Open ID spec.) With OAuth, any information you hold on any website can be shared with another website. You could share your GMail with a clever consumer that automatically tags items by inspecting the content, if GMail was an OpenAuth consumer.

Or you could copy your GMail address book into Facebook, by allowing Facebook to read your GMail account. Right now, the only way to do that is to give Facebook your GMail username and password. Clearly a dumb thing to do, and that’s exactly the kind of thing OAuth is set up to prevent. OAuth prevents it by explicitly asking you if you want to let Facebook grab your details from the provider. That’s not a problem Open ID solves. Even if Facebook and GMail used Open ID and you had accounts with both against the same Open ID, you still couldn’t get Facebook to read your GMail account. The Open ID provider wouldn’t let Facebook log in to GMail as if it was you. Even if an Open ID extension came along to allow it, you wouldn’t want it. It’s too coarse-grained and would allow the consumer to do too much potential damage. OAuth is more fine-grained – consumers can do some things with your provider data, not everything.

Share this:

G’Day

Welcome to Michael Mahemoff's blog, soapboxing on software and the web since 2004. I'm presently using HTML5 and the web to make podcasts easier to share, play, and discover at Player FM. I've previously worked at Google and Osmosoft, and built the Ajax Patterns wiki and corresponding book, "Ajax Design Patterns" (O'Reilly 2006).
For avoidance of doubt, I'm not a female, nor ever have been to my knowledge. The title of this blog alludes to English As She Is Spoke, a book so profoundly flawed it reminded me of the maturity of the software industry when this blog began in 2004. I believe the industry has become more sophisticated since then, particularly the importance of UX.
Follow @mahemoff