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
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".
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.
"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.
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.
"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.
"email.com" will respond with success or failure.
Case 2 - User Not signed into email.com
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.