Browser supported Single Sign on with Email Addresses

In this post I would like to explore Single Sign on's with email addresses, with the support of the users browser. Browsers do not currently support Single Sign On. Recently Mozilla showcased their concept of BrowserID.

I am not comfortable with their use of asymmetric keys, because this requires the user to manage his own private/public keys. Indeed BrowserID will ease the process for the user, but he still needs a private key on every computer he uses. And this may include public computers at browsing centers etc.

So here, I will present a Single Sign on process, that will not require asymmetric keys. For the sake of this post we will call the users email provider "email.com". The site he wants to sign into "site.com", and "BSSO"  for Browser Supported Single Sign On. This article will not get into the details of algorithm's etc, because each step described here can be carried out in many ways, and has already been implemented in some form or the other by other protocols. A good example is OpenID 2.0.

First, I will describe the process when the user is already signed into "email.com", and wants to sign into "site.com".

Case 1 - User signed into email.com

Step 1

The user browses to "site.com". "site.com" needs to indicate to the user's browser that it supports BSSO. This can be done in many ways. I will give one example here. On site.com's page it can include two elements. One element in the html head part like below

<link href="https://site.com/bsso" rel="bsso_end_point"/>

In the body part it can have an element with id "bsso_sign_in_button".

The rel="bsso_end_point" link element will indicate to the browser that this site supports BSSO and it should listen to the click event of the element with id="bsso_sign_in_button".

Step 2

When the user clicks the "Sign In" button for "site.com" the browser will make an authentication request to "email.com" on behalf of "site.com" with "site.com"s end point. This will need the user to have pre selected his prefered email address(s) in the browsers BSSO setup, if not the browser will show a popup asking the user to select his prefered email address. The browser may also have discovered "email.com"s end point during setup using webfinger.

Step 3

"email.com" returns a positive assertion of the user's email address. This is not a problem because the user is currently signed into "email.com". Also a private "association key" is included along with the assertion.

Steps (2) and (3) are transparent to the user. The browser makes a cross-domain ajax request to "email.com". This is possible because it is the browser making the request and not any javascript on "site.com"s page.

Step 4

The browser now directs the user to "site.com"s end point url with a http post request, with the assertion returned from "email.com" in the post body.

Step 5

"site.com" will now verify the assertion by sending the assertion along with the association directly to "email.com"s endpoint. "site.com" would have also followed the webfinger protocol to determine the end point. It is possible for "site.com" to request a time bound association with "email.com", so that Step 5 and 6 can be avoided in subsequent requests.

Step 6

"email.com" will respond with success or failure. 

Case 2 - User Not signed into email.com

In the case where the user is not signed into "email.com", in Step 3 "email.com" will respond with a "user not signed in" response along with a sign in url that might have an encoded token in its query parameter. (The encoded token is for preventing phishing, I am not yet sure if this token is required or not as of now). The browser will pop up a window and listen to the popup's close event, and direct the user to the returned sign in url. After sign in "email.com" must "close" the popup via javascript. When the popup is closed the browser will continue with Step 2 again. In case the popup was closed without the user signing in, the browser will receive a "user not signed in" for the second time, in which case the browser has to query the user again.

Some Notes

This may look like a lot of steps, but the user only "see's" (1) and (4). Also (5) and (6) are not required after "site.com" and "email.com" have established an association.

Phishing is not possible, because there are no redirects from "site.com".

The user can sign in from anywhere, there is no need to have any private keys on the computer being used.

Unlike BrowserID "email.com" will be aware of the site's the user sign's into. I don't know how much of a problem this is. It's a debatable issue I guess.