This page will go through the BrowserID protocol at a fairly high level.
Public key cryptography
To understand the BrowserID protocol you need at least a very basic understanding of the principles of public key cryptography and digital signatures. If you already know what digital signatures are, you can skip this section.
In public key cryptography the key consists of two pieces. If you encrypt some data with one of the pieces, you can only decrypt it with the other piece.
To use this technology to make digital signatures, you keep one piece secret (the private key) and publish the other piece (the public key). To sign a message, you encrypt it using the private key and attach the result to the message as a signature.
When someone wants to check the signature they fetch your public key and use it to decrypt the signature. If the decrypted result matches the message, then the signature is valid: only someone with your private key could have produced that particular signature from the original message.
(In practice, signatures encrypt a hash of the message, not the message itself. But the principle is the same.)
The protocol involves three actors:
- User: Users are issued credentials by Identity Providers and use these credentials to sign into web sites run by Relying Parties.
- Identity Provider: Identity Providers are services which issue credentials to their users. Since the BrowserID protocol uses email addresses to identify users, email providers can become Identity Providers by adding BrowserID support to their service. If an email provider doesn't support BrowserID, Mozilla operates a fallback Identity Provider at browserid.org.
- Relying Party: Any web site, application, or service that accepts BrowserID credentials for user authentication.
In this overview the BrowserID system involves four steps:
- Identity Provisioning
- User Certificate Provisioning
- Assertion Generation
- Assertion Verification
In this step the user establishes an identity with an Identity Provider.
If the user's email provider is an Identity Provider, the user already has an identity by virtue of having an email address with that provider.
If the user's email provider is not an Identity Provider, then the user must prove ownership of their email address to the fallback Identity Provider. This is typically done by sending the user a confirmation email containing a unique link and waiting for the user to click on that link.
To protect user accounts, the fallback Identity Provider will ask users to create a password. For other Identity Providers, the user's normal email login and password are used.
Either way, at the end of this step the user can sign in to an Identity Provider.
User certificate provisioning
When the user attempts to sign into a web service with a given email address, the browser first checks to see if it already has a fresh user certificate for that address. If it does, then this step is skipped and the browser goes straight to the Assertion Generation step below. If it doesn't, then it needs to get a fresh certificate from the user's Identity Provider.
First, the browser asks the user to sign into their Identity Provider. Upon successful sign in, the browser generates a new key pair and sends the public key to the Identity Provider for signing.
The Identity Provider signs a JSON structure containing:
- the user's public key
- the user's email address
- a validity interval
The Identity Provider returns the signed data structure, called a user certificate, to the browser.
The user certificate represents an assertion by the identity authority that the owner of the private key corresponding to the enclosed public key is the owner of the enclosed email address. Essentially, it verifiably connects the user's email address to the their key pair.
The validity interval determines how long the user can use this certificate and its associated key before having to generate a new key pair and ask the Identity Provider for a new signature.
Assertion generation and verification
To sign into a web service using BrowserID, the browser uses its private key to sign the user's email address, and sends the result to the relying party along with the corresponding user certificate.
The relying party checks the validity interval on the user certificate, then extracts the public key from the user certificate and uses it to check the signature on the email address. If this checks out, then the relying party is assured that this user owns the corresponding private key.
Next, the relying party fetches the identity authority's public key. It uses this key to check the signature on the user certificate. If this signature checks out, then the relying party is assured that this user owns the email address in question.
With that assurance, we're done.