Logout: the other half of the identity equation
May 22nd, 2009 by Luke Shepard

This week, Facebook began accepting OpenID for single sign on. At the Internet Identity Workshop, many people raised a lot of questions about Facebook’s implementation, and in general the relationship between single sign in and sign out. In this post, I’ll argue that sign in is only half the battle; if we want OpenID to represent a complete identity solution, then it needs to support sign out just as robustly as it does sign in.

First, let me define what I mean by “automatic single sign in”. Here’s how it works:

  1. The user first establishes a connection between an identity provider (i.e., Google) and a relying party (i.e., Facebook).
  2. On subsequent visits, if the user is signed into their provider, then the relying party detects that and automatically logs them into their own site.

So then, the user sees something like this on the relying party:

Logout link at the top of a page

What does that “logout” link do?

There are three possible choices:

  • Log you out of the current site. (clear cookies on the current domain)
  • Log you out of the current site AND the identity provider. (clear cookies and use cross domain communication to clear the parent)
  • Give the user a choice between #1 and #2.

As I argued last fall, the only logical choice is #2: for it to log you out of not only the current site, but the identity provider as well.

For #1 or #3 (which involve clearing cookies on just the current domain), we leave the user in a logically inconsistent state, which exposes them to security and usability problems.

The contrapositive

One of the basic rules of logic says that if an if/then statement is true, then its contrapositive must also be true.

IF p => q THEN !q => !p

So if we have:

P = “You are logged into the provider”
Q= “You are logged into the relying party”

Then the negation would be:

~Q = “You are NOT logged into the relying party”
~P = “You are NOT logged into the provider”

In English:

If you are NOT logged into the relying party, then you should NOT be logged into the identity provider.

Otherwise, we end up with a contradiction. The user clicks “logout”, and perhaps they even see a logged out page, but when they refresh or navigate away, the relying party will grab the parent’s session and log them right back in.

In short: for relying parties and providers that support automatic single sign in, they need to also support automatic single sign out.

The examples

We can look to the web to see how real sites have implemented this. My favorite example is Google, Youtube, and Blogger. These are all owned by the same company, and if the user sets it up, then they all share the same identity provider (Google). However, I think to most consumers, they are branded sufficiently different that it approximates the world in which the provider and the relying party have no relationship.

Link your Blogger account with Google, then log into Gmail. Then go to Blogger - you’re automatically logged in. Now, click “logout”. You are logged out of Blogger and Google. (Incidentally, you’re also logged out of YouTube, Gmail, and all other Google services).

As another example, go to Citysearch. Log in with Facebook Connect. Now log out, and you are logged out of Facebook as well as all other Connect sites that implement automatic login detection.

Implementation details

Single Sign In

Single sign in can be implemented in different ways. With OpenID, it is accomplished with an immediate mode call. A relying party can do an immediate call either in a background iframe, or with a full page redirect (if there is only one provider).

In Facebook Connect, the background iframe request is done automatically by the Facebook Javascript libraries. An application can support single sign in by assigning a callback that refreshes the page when the user is logged in.

Single Sign Out

But, how do we do logout? For Facebook Connect, a site calls FB.Connect.logout(). That will do a background ping to Facebook that clears the user’s current session. It also briefly pops up a screen that says “You are logging out of Facebook.”

There is no equivalent support in OpenID, but I argue that there should be. I would like to see two request modes in addition to checkid_setup and checkid_immediate.

* logout_teardown: Inverse of checkid_setup, allows user interaction for the logout. If a provider chooses, they could show the user a page before logging them out, and perhaps give the user a choice.
* logout_immediate: Inverse of checkid_immediate, logs out without any interaction. This could be done in a background iframe or full page redirect.

It would be up to the provider to support one, both, or none of these additional modes.

In the example of Facebook Connect, a provider could display the “You are being logged out” notice via logout_setup.

The choice

But wait, you say! I don’t like this behavior! I don’t want to be logged in and out at will - I want choice to navigate throughout the web.

First, let me assert that most people don’t care that much. They just want it to work. And single sign in / sign out is a conceptually easier model to handle (once we get the kinks out) than having the keep track of accounts across the web. Single sign in is kind of the point of OpenID and related technologies.

That said, there are legitimate reasons why you might not want to support automatic login. For example, Mint.com handles very sensitive data, so may not want to trust in third-party credentials exclusively. Or Netflix, which has its own very developed sense of user identity, including credit cards on file, may choose not to accept single sign on. These companies may find it useful to link with other identities, but single sign on is just not part of the equation.

That’s fine, actually - they don’t have to. But the developer does need to pick a side. If you don’t want to support sign in, then you don’t need to support sign out. But for those sites that DO support sign in, they DO need to support signout. You’re either in the club or not.

Imagine there’s a “single sign in cloud”. When a user logs into their identity provider, they log into the entire cloud; when the log out, they log out of the whole thing. Sites choose whether they join the cloud.

Single sign in cloud

Let’s review the contrapositive rule. IF a site supports automatic login THEN it must support automatic logout. It’s a choice. If you don’t want to log the user out of the provider when they hit “logout”, then you can’t automatically log them in. You must require them to click a button or enter a password or some such to get in - each and every time.

But regardless, we want to make sure that OpenID supports automatic login and logout, even if it’s not always required.

Update: Shibboleth and Single Sign Out

There’s already been some extensive analysis of single signout within other identity communities. That post makes the very valid point that single signout is much harder than it seems. However, I don’t think that argues that it shouldn’t be attempted, just that we need to watch out and use the right tools.

Making OpenID more useful: let’s detect logged-in state
Apr 15th, 2009 by Luke Shepard

One of the biggest issues with OpenID is its usability. Many relying parties are currently faced with a difficult choice: how do you let the user know the provider they should be using? Users may be familiar with the brands of Facebook, Google, Yahoo, etc, but if your site doesn’t show it, then it may as well not exist. For the time being, at least, the OpenID brand is invisible (and in fact, sometimes is considered a negative).

As I see it, the fundamental problem we would like to solve is to figure out what are the most likely OpenID providers that the user would like to use? There are a few approaches to this:

  • Show logos for the most popular providers. This is currently a common option, popularized by Janrain’s RPX and numerous other sites. This scales up to maybe 4-8 providers - beyond that, we get into what Chris Messina dubs the “OpenID Nascar”
  • Janrain RPX displays icons of various top identity providers

    Janrain RPX displays icons of various top identity providers

  • Show a dropdown of popular providers. This scales to maybe a few more, but starts to suffer from the value problem. What’s the first element of the dropdown? Do users understand what the “openid” moniker means that sits in front of it? (the answer: nope)
  • Ma.gnolia used a dropdown of common providers

    Ma.gnolia used a dropdown of common providers

  • Let the user type in a url. You can provide a simple textbox, or better yet, a typeahead, in which the user can enter the service provider. The problem is that without prompting, users don’t really understand the value or what to write - in fact, they will type just about anything in there. You can see what this looks like here.
  • Blank box offers infinite choice and confusion

    Blank box offers infinite choice and confusion

The core problem is that we are relying entirely on the user to tell us what their provider is, but we can’t really ask them an intelligent question without explaining the value first. And the catch-22 is that the value provided relies sometimes on the provider! For instance, I may not know what OpenID is or internet identity or whatever, but I just want to log in okay?

To a user of Google products, this is how the interface should look

To a user of Google products, this is how the interface should look

A solution: detect the user’s provider

Okay, so let’s not just ask the user. Let’s ask the user’s browser, and let it tell us who their provider is. There are a few brainstormed techniques for doing this, none of which is particularly widespread at the moment:

  • One idea that’s commonly suggested but not implemented is to use some strange browser history hacks to determine what sites the user has visited recently. If an OpenID provider appears in the list, then target the message to them. Fantastic!

    While this would work with today’s technology, I think most sites have shied away from it because the information comes via an exploited bug rather than intentional, informed consent.

  • We could build support into the OpenID spec for detecting the user’s current logged-in state. Relying parties could iterate through a whole bunch of possible providers, and if the user is currently logged in, they can show them a login screen. The performance would hardly be as bad as people think - requests can go in the background, in parallel, and you could theoretically query dozens or hundreds of providers within a few seconds (although I admit I haven’t tested it). See more discussion below.
  • We could create a centralized authority or authorities for managing user OpenID provider preferences. People could set a single cookie with their preferred provider, and then every relying party can check that cookie via a cross-domain call. Some Google engineers have initiated some discussion of this based on a similar model used for advertising, but it suffers from a severe chicken-and-the-egg problem. I think that we first need to feel some pain from these other approaches first before everyone gets fed up and moves to a centralized model

OpenID needs a middle state

I think #2 is the best option of the three. OpenID already supports two types of requests- first, modal calls, with a mode of “checkid_setup”, tell the provider to ask the user to login. This is the standard mode that most people are familiar with, and much of the user experience discussion (including my previous post about the popup UI) has focused on it.

The second type of call is triggered with a mode of “checkid_immediate”, and it, well, always returns immediately. This mode is used by a relying party to re-authorize a user that has previously visited the site. When a provider receives an immediate request, it can send only one of two replies:

  1. Yes: Yes, the user is currently logged in, and they have previously authorized your website, so here’s their identifier. (mode is “id_res”)
  2. No: Nope, don’t know anything about them, you have to send them over to find out. (mode is “setup_needed”).

By contrast, Facebook Connect offers more functionality. If an application (relying party) queries the Facebook servers for a given user, it can return three states: returns three states:

  1. Yes, the user is logged into Facebook and they previously authorized your website.
  2. The user is logged into Facebook, but they haven’t authorized your site.
  3. No, we don’t know anything about this user.

That middle state ends up being pretty important. When a site sees it, they can place a Facebook login more prominently than they otherwise would. Also, because the relying party knows the user is already logged in (and so won’t be entering any user credentials), it can issue a nice neat iframe dialog instead of the heavyweight popup window. Because the popup can’t get blocked or hide behind the window, it is a nicer and less confusing user experience, and it looks better too. (It’s not really a security problem - if the OP wants to collect a password, it can always pop out of the iframe with Javascript).

There’s currently no way to communicate that middle state via the OpenID protocol. What I would like to see is an additional parameter that’s part of the “setup_needed” mode, which says in effect “the user is logged in, so if you present them with a dialog, it will be an easier experience than with other providers”.

Objection: what if a provider doesn’t want to?

Releasing logged-in state can be an optional feature. There should be a way to return logged-in state within the context of an OpenID transaction. Right now, there’s no standard way to do this, so providers that want to need to invent their own way to release that state.

Of course, the OpenID community has been fighting an uphill battle to even get the basic checkid_immediate call to work. Google, MyOpenID, and many others behave correctly, but even top providers like Myspace, Yahoo, and Microsoft always return a negative response to immediate requests - even when the user is logged in and authorized! We clearly still have a lot of work to do to make checkid_immediate a standard across all top providers.

Nonetheless, the spec should make it possible for providers who WANT to offer this additional state to do so. Just as some providers choose to offer checkid_immediate and others don’t, likewise we should allow those who want to the ability to return a more nuanced reply.

Objection: what if the user is logged into more than one provider?

So let’s say this becomes widespread. A user shows up to a relying party, and the background ping reveals that the user is logged into Facebook, Google, and Yahoo. Now what?

I think this would be a great problem to have. The relying party could present the user with choices if it wanted to, except confident in the fact that the user is familiar with all the choices. Or, a relying party could choose the provider that it has found gives it consistently better data and user experience. Or it could choose based on security preferences. The point is, the interface is still in the control of the relying party, but now the RP has strictly more information to make a better experience for its users.

A proposal for a conceptual “Open Stack”
Mar 4th, 2009 by Luke Shepard

Last summer, John McCrea and Joseph Smarr put together a diagram of the “open stack”. The image showed up in numerous talks throughout last year, culminating in an Open Stack Meetup in December. Last week, Marc Canter sent an email asking for thoughts on crafting a new revision to the “open stack” graphic. I’d like to propose a new stack based on the underlying concepts rather than the specific, possibly obsolete technology.

Here’s the open stack graphic from summer 2008:

The Original Open Stack

The Original Open Stack

Here’s the problem: how do I read this? If I’m an average businessperson or developer who has never read a spec, how do I know what these terms mean? Some of the ideas are in there … ID, Auth, Contacts … but others don’t make any sense. XRDS-Simple? My eyes start to glaze over - that doesn’t seem all that simple. I have to lean over to my friend and ask him what all these things mean.

Technology changes.

The technologies involved here change rapidly. In just the past six months, we’ve added draft specs for PortableContacts, ActivityStreams, OpenID / OAuth Hybrid, and OpenID User Experience. These are all draft specs, which means they will change (some more than others) in the near future. Other specs, like XRDS-Simple, are actively being deprecated in favor of newer versions, like LRDD. And the work is far from done - there will likely be even more specs developed and revved before the whole thing really starts to gel.

Do we really want every version of this graphic to be out of date shortly after it’s released? Or do we want something that is compelling, demonstrates the vision, and gets people thinking about how to do it themselves? We should use the underlying concepts to communicate ideas instead of specific technologies.

The "Real" Open Stack .. of papers.

For an example of a different approach, I looked at the messaging around Facebook Connect. A developer who’s deciding whether to implement Connect will see the three main benefits: Identity, Friends, and Feed. Sure, it’s much more complicated under the covers, and sure there are some pieces that aren’t covered (lots, actually), but those are the main points that everyone should think about. They will go home and think: “How can I fit each of these pieces into my own website?”

This is the Facebook Connect stack

The Facebook Connect value stack.

The “open stack” embodies a similar set of concepts, but they aren’t entirely the same. for example, to participate with a many-to-many decentralized web made up of open standards, Discovery becomes a really important element. Someone who views the diagram should be able to tell what’s going on without having to look up a bunch of terms or be involved with the community. They should also be able to immediately understand most of the terms, and apply them to their own use cases.

Here’s my proposed conceptual open stack:

Proposed new "concept" open stack

A conceptual open stack.

Let’s stack it up, with the highest-level concepts on top and the foundations for those concepts on the bottom. Thus we have:

  • Streams. Read recent activities that people are doing around the web. Can be implemented with Atom, RSS, or the newer ActivityStreams.
  • Friends. Get information about people you are connected to. Alternately, this could be called Contacts, although I think that word tends to turn people off since they think it means contact information (which it doesn’t always). Can be implemented with PortableContacts, the OpenSocial “People and Friends” API.
  • Identity. How does someone prove they are who they say they are? This one is solidly covered by OpenID.
  • Profile. All the information that goes along with an identity - name, profile picture, birthday, whatever. There are a bunch of ways of getting this, and it hasn’t really settled yet. The most popular now are OpenID Simple Registration and OpenID Attribute Exchange. Another possibility is to use the OpenSocial “People and Friends” API with the OpenID-OAuth hybrid (although to my knowledge nobody has implemented this yet).
  • Authorization. Allow someone to have access to private data. Alternately, this could be called Privacy. The open standard for authorization is clearly OAuth.
  • Discovery. In a decentralized system, we need a way to figure out where everything is. As we get more and more providers and consumers, a smooth discovery process becomes ever more important. It has hopped around, from simple link tags in OpenID 1.1, to XRDS-Simple in OpenID 2.0. Now Eran Hammer-Lahav is working on a Link-based discovery mechanism, which will hopefully replace the other forms of discovery going forward.

As you can see, the world of the open stack is constantly changing, but the underlying concepts are maturing. We should ask people to think about how they can apply the concepts to their own business or project, rather than asking them to check off a bunch of arcane technology names.

I’m sure that lots of people have thoughts on this. Let me hear ‘em!

How to accept OpenID in a popup without leaving the page
Feb 4th, 2009 by Luke Shepard

For most sites that accept OpenID today, the user experience is one of two things:

  • User is redirected to the OpenID provider, and then redirected back to the original site. This is the most popular one, but it’s a particularly jarring experience for the user.
  • User is given a Javascript browser popup, but when the popup returns, it still refreshes the whole page. I haven’t actually seen this in the wild, but I’ve heard it discussed.

There has been some discussion lately about how the OpenID experience can work within a popup window. Next week, Facebook is hosting an OpenID design summit to work through some of the issues around cohesive design within a popup. However, one question that I’ve heard several times is “How does the popup work for Facebook Connect? Can it be done for OpenID?”

In theory, yes. In this blog post, I’ll walk through an approach for how the existing OpenID 2.0 spec can be used to do the entire exchange within a browser popup, so that the page doesn’t even have to refresh. Once the user is logged in, she can just keep doing what she was doing. At the moment this is just theoretical, but I will put up sample code and a demo once I get it all working.

Update: Brian Ellin implemented this idea in, like, an hour. His sample code implements a slightly simpler version of the technique described here. It’s really quite good.

See it in action here.

How it works

Okay, so suppose the user is on a page, and they see a “Sign in with OpenID” button. I’ll assume they have some way of choosing their provider. In the image below, I use the “Sign in with Yahoo” button. The user clicks the button, which triggers a Javascript handler. That handler sets up a callback (I’ll get to that later) and then calls window.open to initiate the transaction.

The first part of any OpenID transaction is discovery - that is, given a URL like “yahoo.com”, where do I go to actually log the user in? The RP also needs to establish a secure association, so that it can verify the signature on the response for security.

We open the popup onto a helper file located in the domain of our site. That helper file does the appropriate discovery, and then does a redirect to the OpenID provider, which remains within the browser popup. The OpenID provider walks the user through the steps to log in. It doesn’t even know it’s in a popup - as far as the provider is concerned, this is a full page (Although there are some discussions about how to let that it’s in a popup, nothing has made it into the spec yet).

The OpenID provider within the popup looks something like this:

Finally, the provider redirects back to the openid.return_to url. Remember in the first step, before the popup was even opened, the Javascript handler set up a callback? Well, the return_to url is a specially encoded cross domain url. It encodes information about that callback so that it can be decoded on the reply.

Here’s an example of a return_to cross-domain url:


The cross-domain URL reads the response parameters, and just passes them directly to the parent page using Javascript. Because the cross-domain receiver and the parent page are on the same domain, the communication can proceed.

What next? The parent document now has all the OpenID parameters, but it’s in Javascript. The last step is to verify those parameters. The RP can make an Ajax call to a helper script, which looks up the association and verifies the signature. It can then perform any logging in, and pass back a success variable to the Javascript to let it know that everything went well. Of course, if the Javascript wants it can then go ahead and refresh the page, but if the user is in the middle of something, it can wait until the user is done to do so.


What about performance? This flow involves the following HTTP requests:

  1. The initial request for the RP page.
  2. The load of the helper page in the popup (which does background discovery)
  3. The redirect to the OP
  4. Probably, at least one form submit within the OP. (The user enters their name and password, and submits)
  5. The load of the reciever file when the OP redirects back
  6. The final Ajax call to the RP server to validate the signature

At least two of these HTTP requests can be optimized away:

  • Load of the helper popup. In the common case, users will be using an OpenID provider that’s been used before. For example, if someone clicks the “Yahoo” button, then the RP doesn’t need to do discovery on Yahoo.com again. In fact, the RP should cache both the server endpoint and the secure association, and make them available in Javascript. If that were the case, then the popup could open directly onto the OP site, and skip this one.
  • Load of the receiver page. The client needs to redirect to a page that lives on the RP domain- but that doesn’t mean that it has to load that page from the server. If the RP serves the cross domain receiver as static HTML with long cache headers, then the user’s browser will cache the page. As long as the query string doesn’t change, the browser won’t need to fetch the reciever again.

    But how can the query string not change? After all, the OpenID parameters need to be sent back in the query string, right?

    The way around this is to send the parameters back not in the query string but the fragment. So the return would look like:


    Because the part before the fragment doesn’t change, this file never needs to be reloaded, and this HTTP request is saved.


The techniques laid out here can help the OpenID user experience reach the same level of fluidity as that achieved by Facebook Connect. Now it just remains to get some working code, and put it in practice!

I’m running for the OpenID board of directors
Dec 17th, 2008 by Luke Shepard

I’m running for the OpenID board of directors. I’m a little nervous, having never done any sort of political thing before. So let me try to answer some questions.

Q. Cool! Can I vote for you?

Anyone who is a member of the Foundation is eligible to vote. Membership in the foundation costs $25, and requires an OpenID (Yahoo or Google will work fine if you have an account at one of those sites).

If you’re interested in OpenID and the future of the web, please join! And then vote for me. Thanks!

Click here to join and vote

Q. Huh? What is OpenID?

If you aren’t familiar with OpenID, don’t worry- you’re not alone. It’s a geeky protocol that says how to use an account from one website to log into another website. It was designed initially as a way to avoid typing a username and password into every site around the web. You should watch the same video I did that convinced me of its potential.

Q. I don’t get it.

You can try it out by visiting a Blogger blog, like my brother Scott’s. You can leave a comment using your Google account, or any OpenID. Providers currently include Yahoo, AOL, Livejournal, and a few others. Here’s a screenshot:

Logging into Blogger using my yahoo.com OpenID

Logging into Blogger using my yahoo.com OpenID

As you can see, the user experience leaves a little to be desired, as it’s not really obvious how it all works to a non-geek.

Q. What is Facebook Connect?

I’ve been working on this project for several months. It basically lets you log into a website using your Facebook account instead of making a new username and password. You also get tons of cool benefits like seeing what stuff your friends are doing, and publishing activities back to Facebook automatically (but only if you want to). Give it a shot at Citysearch or Techcrunch. Or on the Comment form on my blog (if you’re reading this on Facebook, click “view original post” and then check out the comment form).

Q. But I heard that Facebook and OpenID were competitors. Why would they want you on their board?

Well, they aren’t competitors so much as just working at the same problem from different angles. You could say it’s complicated.

OpenID is a protocol, like HTTP, SSL, 802.11b. Facebook Connect is a product offered by a single company. But as far as products go, I think we did a pretty good job of it, and I’ve learned a lot that can be shared with the community.

Ultimately, I would love to see a world in which your information and identity follows you around. If you interact with a website, or a store, or a phone, then it knows who you are – to the extent that you want it to. All your data should be privacy protected, so that the user is ultimately in control of who gets to see what. But we can remove a lot of the friction that gets in the way of people sharing their data with who they want to share it with. I don’t think that Facebook can get to this world all by itself – that’s why they built the platform, and now Connect. I hope that by joining the board I can establish a tighter connection and increase communication between competitors and allies alike.

Q. Watch out for this shoe!


Q. What do you think OpenID needs to do to improve adoption?

The message of OpenID has generally been “make it easier for consumers to log into multiple sites without a new password”. Well, after a few years, it’s pretty clear that that is not enough to get people to adopt it.

The primary competitor to OpenID is not Facebook Connect, Google Friend Connect, or any of these new systems. It’s old-fashioned email. When a site gets your email address, they get both an identifier and a way to contact you. When they get an OpenID, all they get is an identifier. As long as an OpenID is less valuable than an email address, it will not be adopted widely. So we need to make it more valuable to websites.

There are elements of the “open stack” that can layer on top of OpenID and provide not only a way to contact the user, but also get their profile info, friend data, and distribution among their friends. These are all available via Facebook Connect, and they offer real value. For instance, with Connect, websites are impressed by how much data they get from their users, and how much more content users contribute. For example, Govit reported that more than half of their new users use Connect, and they all have names and profile pictures, and they can publish their stories back into their Facebook Newsfeed.

Unfortunately, OpenID providers aren’t there yet with providing all that value. There are extensions to OpenID that help with this: simple registration, attribute exchange, OAuth, portable contacts, …. Sorry, did I lose you? These different pieces are really confusing and inconsistently applied. As long as that is true, it will be really difficult for relying parties to well, rely on them being there. Yahoo is the only major OpenID provider that offers simple reg (I mean of the big few) and even they haven’t released it publicly (although soon will). I hope during 2009 that the breadth of providers offering the full “open stack” will be dramatically expanded, such that relying parties can come to expect a consistent experience from the average OpenID provider. It should be as consistent as it is with Facebook Connect.

Q. What would you do as a board member?

My understanding is that the board is actually somewhat disjoint from the mechanics of actually moving the technology forward. The board members meet once or twice a quarter, plan and manage finances, and set the strategic direction and overall goals of the OpenID brand and organization. I think I can help particularly in representing the needs of big companies (Facebook specifically), and the top 100 websites, and making sure that their voice is heard within the OpenID board meetings. I’m also really interested in learning about the goings-on in the technology, and talking with representatives from other stakeholders in OpenID.

Regardless of whether I make the board, I plan to work within the community … help with the OAuth extension, continue to evangelize OpenID and other elements of the open stack within Facebook. I’ve done a significant amount of work towards that end already and plan to continue.

Lessons from Facebook Connect
Dec 11th, 2008 by Luke Shepard

Last week we finally launched Facebook Connect to the general public. In the time since I joined the team last May, I’ve definitely been surprised by a few things I thought I’d share.

think big

This time last year, I thought “Man, wouldn’t it be cool if Facebook became an OpenID provider? Maybe if we just put it out there, then eventually people could do redirect back to Facebook, and we could expand the platform incrementally.” Moments of surprise:

  • When Wei told me that we were going to do the entire login flow in an iframe on the remote site, without any redirects needed. And he would build an extension to HTML that would render social data on a remote site, but in Javascript. Whoa, I didn’t even know that was possible.
  • I started to think, “Wow, maybe some sites will actually use this.” Then Josh, Matt, and Dave told me that they had already talked to Citysearch, Digg, CNN, CBS, … I thought, “Wow, real sites? Like ones my friends would use?”
  • As we got closer to launch, the dialog kept growing and shrinking. The feed form kept changing. Engineers would add checkboxes, options, and then Julie would smack them down. Or if she didn’t, Zuck would. After several iterations, I started to grasp the vision. This wasn’t just about letting users share their blog comments if they wanted to. This was about radically changing human behavior so that everything they do is shared through Facebook. Everything. Ultimately, that’s the goal. It blew me away.

marketing matters

The team built a great product, if I don’t say so myself. But it would have been impossible without the partner managers. Zhen, Josh, and Anand were out there every day for six months talking to partners, nursing them, giving us feedback. Somehow they kept track of a software product that was constantly changing. They cajoled and explained to the folks at shopping sites, media companies, newspapers, tech sites, and bloggers. They figured out what each one needed and let them know that Facebook would make them money.

Most importantly, they explained it to us. I didn’t really know what we were building back in June. It was the partner managers that gave us the early Citysearch mocks that let the team know we were onto something. And as the product rolled on, they helped us prioritize. I think most features we built between August and November were geared towards one partner or another, whose feature requests represented the voices of huge swaths of developers that would never ask, but just would not use our products. For example, Citysearch operates on multiple subdomains - chicago.citysearch.com and miami.citysearch.com - and we needed to build out support for that. But because we did that, it made the product that much better.

speedy is as speedy does

The engineers on this team are quick! I think every day for months someone was checking in code. There were some days with over 30 commits, and code being pushed two or three times a week. This is only possible because the whole company is geared towards speed, speed, speed. I credit our main pusher, Chuck Rossi, for launching us at least a month earlier than we would have otherwise. Of course this also meant incredible pragmatism when it came to churning out features. Very little work was wasted in the end, which was a tribute to the product management.

listen to developers

As the first few … dozen … partners rolled out, the team cheered. Each of them represents hours of engineering time on our end working with developers, helping them solve problems, debug issues, just get a mental model for how XFBML is supposed to work. Internet Explorer is not kind to cross-domain Javascript developers, I’ll say that much. But it was worth it. In the past two months we’ve seen what kind of errors people kept making, and tried really hard to reduce the code necessary to make simple things happen. Our initial partners spent so much of their time helping us smooth things out. David Recordon and Jonah Schwartz were rock stars really early on.

Wei and I made a video demonstrating Connect today. The code in this video would have taken hundreds of lines of Javascript only two months ago.

An Open Stack glossary for Facebook developers
Nov 21st, 2008 by Luke Shepard

When I was in college, I remember learning how to use Linux. It confused me horribly that different computers window managers would behave in different ways. First off, coming from Windows, I didn’t even know that the window manager and the operating system were distinct concepts - I assumed they just belonged together. Linux empowered greater modularity and flexibility, but it was also quite daunting for a first time user who had to learn all these new abstraction layers that I didn’t even know existed.

The “Open Stack” in social software sometimes feels the same way. There are a lot of terms bandied about that can be quite confusing. OpenID, OAuth, XFN, PortableContacts, OpenSocial, XRDS-Simple, Yadis, … what are these and how do they fit together? Isn’t OpenID just a url thing for geeks?

Facebook application development is similar to the all-included package. You still have the different concepts of identity, authorization, contacts, activities, but they are unified together in a cohesive interface that is easy to understand.

But the Facebook stack and the “Open Stack” are really analogous, just with different names for things. So here is your Open Stack Glossary for the Facebook Developer.

Your identity is your user ID

Identity is what lets an application say “yep, I’ve seen you before.” It’s some sort of identifier that tells them who you are. On Facebook, it’s your user ID. In the “open stack”, it’s your OpenID. Now, since Facebook controls the identity space, user IDs are simple 32-bit ints. Because there is no central authority for OpenID, they needed a more creative way to avoid conflicts, so the OpenID community borrowed from DNS to ensure uniqueness. But whether I say “I am Facebook user 2901279″ or “I am Yahoo user http://openid.yahoo.com/id/XRXRXRXR”, it’s ultimately the same thing. It provides a key into a database on the application side. (well, relying party)

OpenID Translations

OpenID identifier Facebook user ID
OpenID relying party Facebook application
OAuth identity provider Facebook

A Facebook session key is your authorization

Identity isn’t all you get with Facebook. The reason that people develop apps for Facebook is because they want data and distribution, both of which require user permission. And once you have a session key, you can make plenty of API calls. Getting that session key in a secure way is a sort of a pain though- you have to redirect the user back and forth a few times, make sure that everything is signed, handle failure appropriately. The “Facebook Auth” mechanism was developed in 2006, after studying how other websites did it. Eventually, after Flickr, Amazon, Facebook, and others had all reproduced the same series of redirects and signatures, OAuth came along to standardize the means of obtaining a token.

OAuth Translations

OAuth consumer key Facebook api key
OAuth consumer secret Facebook api secret
OAuth request token Facebook auth token
OAuth access token Facebook session key
OAuth token secret Facebook session secret

friends.get() gets all your friends.

Okay, so we have an identifier to key off, and a session key. What can you do with the session key? The current state of the world is, it’s up to the service provider. Google lets you use your OAuth token to make service calls in their own format. Flickr does the same thing. But now we’re seeing some layering on top of that, starting with friends.get().

PortableContacts is a brand new evolving standard that allows a developer, armed with an OAuth token, to fetch information about a bunch of a user’s contacts. In Facebook, this is equivalent to a friends.get() call, followed by users.getInfo() - or better, an FQL call like this:

select uid, name, ... from user where uid in (select uid2 from friend where uid1 = %d)

PortableContacts returns like this:

Of course, the quality of the contacts will vary from service to service. A large part of the reason Facebook is so strong in this area is that the friends returned tend to represent real-world friends with influence. Most services out there will have a hard time achieving the same level of quality.

The Developer Application lets you specify where your application lives and what it can do.

In any communication between two web applications, they need a way to find out how to talk to each other and what language to speak. For Facebook, this is relatively easy - the developer just comes to the site and tells Facebook all the information about itself. But in the “open stack” it’s much harder. After all, there is only one Facebook, but there are an unbounded number of “open” web services, which can each offer some variation on OpenID, OAuth, PortableContacts, etc etc. How does a relying party know who offers what, who is telling the truth, and what’s going on?

On Facebook, the developer visits the Developer application and fills out a few forms. They can specify who they are, what they offer (iframe or canvas application, on-facebook or off, etc), and most importantly, where to find it (the callback URL).

Specify an application's callback URL in the Facebook developer app

Specify an application

XRDS is a service discovery protocol that lets a service advertise what it offers, so that all necessary information can be discovered by software without needing human intervention. It doesn’t cover quite the same options as the Facebook Developer application, but it is the same idea. The main difference is that XRDS is automatic (in-band) discovery, whereas the Developer app is done manually (out-of-band).

For instance, here is Plaxo’s XRDS service definition file. Anyone who hits plaxo.com can figure out that Plaxo supports OpenID, Oauth, and PortableContacts, and they know where to find those services.

<XRD version="2.0">
<Service xmlns=”xri://$xrd*($v*2.0)”>

And then there’s the REST

Once we move beyond the core technologies and into the specifics of the APIs, the analogy starts to break down. The OpenSocial REST API offers an analogous set of APIs as fbCode, but they are sufficiently different as to not quite be a standard. And both the open community and Facebook have features that don’t appear in the other one. For instance, Facebook’s implementation of News Feed publishing, FBML, and XFBML are quite different from the OpenSocial specifications for activity streams and templates, although they do share similarities. I think that Facebook, MySpace, Google, and other containers will continue to experiment with these features until they coalesce on a standard, at which point we can add them to this list.

There’s three types of sites out there
Oct 23rd, 2008 by Luke Shepard

Let me count the ways…

Okay, so suppose you’re a website owner. You have a user database, but you want more people to use your site. You’ve heard about a lot of these technologies for making your login process easier, but you’re not sure how to use them. Facebook is offering Facebook Connect, and you’ve heard of Yahoo and the OpenID community. But how do you actually go about using them? What happens when a user decides to use one of these systems?

Three basic uses

Different sites have different uses for using delegated auth. Perhaps the site is already well established and just wishes to sprinkle some “social sauce” throughout to make their site more engaging. Other sites will be brand new and want to grow their userbase quickly. Still others may have a core userbase, but want to really increase their numbers.

1. Keyless remote

Log in once, logged in everywhere. Log out once, logged out everywhere.

My favorite aspect of this social web is the promise of being able to “sign into the web”. With a single click, I can log into any number of sites. For example, if I’m logged into Facebook, then I can go to a relying party and just be automatically signed in. This is incredibly powerful as it removes pretty much any friction. Of course there’s an initial setup phase for each website, but once that’s complete, I shouldn’t ever have to remember my provider again - the website just knows, and logs me in automatically.

If I log out of any site, then I’m logged out of my identity provider and all the rest of them. If I go to a shared computer, then I just click logout once, and I will be signed out of everything.

Master key

Substitute for name and password, but then manage everything after that.

Then there are some sites that will want to use OpenID as a means for logging in, but they have their own way of managing sessions after that. In this case, users will click on the “login” button for OpenID, Yahoo, or Facebook, and then they will get a session granted by the remote website. From here on in, it doesn’t really matter what the user does with his provider - the site will still have its own cookie that will determine if the user is logged in.

Simple Link

Establish a different identity, but don’t share sessions.

Some sites already have a strong userbase, and they perhaps have to protect credit cards or

Some sites already have a strong userbase. They really like selling data to advertisers, and they don’t want to get hung up on who “owns” the user. If they accept identity from a random OpenID provider, then what happens if that provider goes out of business? Will they be able to recover the identity? For that reason, these sites prefer each user to have their own username and password. They accept OpenID or Facebook because they want to just establish an extra link - for example, to get a user’s friends, or to display a link on their profile.

How do we implement it?

Authentication is a gnarly problem. It’s hard enough to figure out how to securely keep authenticated sessions alive on a single domain; how do you manage to get an authenticated session across domains? If I want to use yahoo.com as a provider, and I live on crossways.com, then how do I do that?

Answer: it’s pretty tough, but getting easier as library support evolves.

Logging in

The login process for OpenID is pretty straightforward. You either redirect full, or use a browser popup, but you open a window onto the identity provider’s domain. The user enters their username / password, then la-dee-dah, they are sent back where they came from and they are logged in. The RP can then set a cookie to keep track of that state.

If the RP has reason to believe that a given user has come from a specific provider, but they aren’t sure, then they can use the checkid_immediate call in OpenID to check if the user is currently logged in. For example, the RP might store a long-term cookie that says I’m jerry from yahoo.com. When I visit their site, it could do a quick redirect and then redirect back to check if I’m actually logged into Yahoo as chuck. If I’m not, then the OP can just show their normal sign-in page.

With Facebook, it’s the same basic approach, except that it is wrapped in a Javascript library. The JS does some fancy auto-detection of your login state before it renders the popup. Most importantly, it allows a site to know whether you are an existing, logged-in user before it ever does a popup, by using Facebook’s cross-domain communication library.

Google does something like this for Blogger. If you visit Blogger from a new computer, you’ll first be redirected to google.com, and then immediately back, and Blogger uses that to tell if you are logged into your Google account or not.

Logging out

OpenID doesn’t have a way to support universal logout; with Facebook, there is a FB.Facebook.logoutUser() method that allows you to log the user out of Facebook (as well as your own site, if you want). Likewise, if you log out of Facebook, then it invalidates all your sessions with the remote sites (applications).

Feb 14th, 2007 by blogger

Five minutes each. That’s all they got. Yet these presenters were able to fill my head with swirling images of two-man pogo sticks and robots taking over the world. Not to mention the career advice, a computer-aided cure for autism, and an awkward yet somewhat interesting take on the world of messenger bags.

This was Ignite Seattle, a geekfest with a surprising number of women in the audience.

Tech highlights:

* Ever wondered what it would be like to not have to type in your password at every site you go to? OpenID solves that problem for you. Instead of typing in your password, you type in your “open ID” (which is just a website). Then you are taken to your own website, where you authenticate (maybe with a password) and then you are taken back to the calling website, this time with your credentials. Now the site has access to whatever data you want it to have access to.

I’m thinking this concept could be expanded. The privacy policy of the site you’re going to could be automatically checked against what data you are willing to give … i.e., if the site has a policy that it never sells your data, then you let them have your email, but if they don’t say so, then you don’t — automatically. This would be a start at giving users control over their data without the headaches of actually keeping track of the control. And your OpenID server keeps track of all the sites you’ve logged into and when, and what data you gave to each of them, so you know where you’re data is going.

* Matt Maclaurin from Microsoft talked about programming languages for eensy weensy children. Interesting … how do you get a 5 year old to program? Make it into a game.

* A program that provides therapy for autism. That could be awesome.

* Finally Mike Arcuri from Ontela.com talked about how to leave a big company. There are a lot of reasons to stay - money, “prestige”, work with smart people, make a big difference, etc. But there are often more reasons to go. And he pointed out the reasons to stay, and encouraged us all to go out and start that new chapter in our lives. Well, he didn’t say it as such, but he meant it. It made me wonder if maybe he didn’t get a payoff from all the other teams there tonight - many of them were hiring, and he probably helped them recruit more than anything else.

»  Substance: WordPress   »  Style: Ahren Ahimsa