On the 27th September 2012 Mozilla launched the first beta of Persona. Persona is an authentication system that on the surface is quite similar to OpenID and oAuth, but differs in important technical and functional ways.

We were fortunate enough to partner with Mozilla and create a beta version of The Times Crossword as part of the launch of the Mozilla App Store. In doing so we were one of the first third-parties to integrate Mozilla Persona (BrowserID back then). Mozilla even did a video about it.

Why do we need another identity system?

Let’s outline some of the issues with OpenID and oAuth:

• OpenID uses URLs as identities.
  • While fundamentally this is a good idea, it can be confusing for users and therefore results in bizarre login systems that ask you to ‘choose a service to login with’ such as Google, LiveJournal, etc. when you’re not really logging in with them at all.
  • Most sites would like at least an email address to be able to contact you, so will almost always require an additional step after logging in for the first time.
• OpenID is a jarring login process; you have to completely leave the site you are on and return after authenticating with a third-party. The same can be said for oAuth (though some oAuth implementations allow single-click sign on processes such as Twitter).
• oAuth is complicated for developers to implement, requiring the storage and management of tokens. There are also several versions of the protocol, and sometimes extra authentication cruft on top (for example Google’s refresh tokens).
• Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.

How do Persona and BrowserID solve these issues?

• They use email addresses instead of URLs. Not only are email addresses easier to remember, but you can also use different email addresses for different identities e.g. your work email, home email.
• Mozilla Persona uses a popup so that you aren’t completely leaving the website you are on. But it gets better, when browsers natively support the BrowserID protocol, you won’t need to do anything.
• Persona/BrowserID is largely handled by the browser (either with Javascript or natively) and as a developer you only need to verify the user is who they say they are. This needs to be done on your own server, but can be implemented with little more than a cURL request.
• By placing the user’s browser in the middle of the authentication process identity providers are unable to track what the user visits, whilst still allowing sites to verify the user’s identity. It achieves this by incorporating public-key cryptography in its protocol.

Of course, Persona doesn’t help when you need to access authenticated third-party resources (e.g. Twitter data), but it’s not supposed to. This is the correct separation between identity and data.

How does it work?

What is great about Mozilla Persona as a solution is that there are two levels to it. The first is the bootstrapped BrowserID service; Persona, and the second is the underlying identity protocol; BrowserID. By designing a protocol that can be bootstrapped in this way, Mozilla have avoided the issue of low-uptake and make it super-appealling for developers to use.

BrowserID

In a utopian world where BrowserID is fully adopted here is what happens when you want to log in on a website:

1. You click login.
2. Your browser asks you which email address you would like to identify with.
3. You are logged in.

And here’s how this works in detail:

1. You click login on a site (henceforth known as the Relying Party, or RP).
2. Your browser asks you which email address you would like to identify with.
3. Your browser contacts your Identity Provider (e.g. Gmail, henceforth known as IdP) with your email address and public key for that address on your browser. It asks for a signed certificate.
4. Optional: Your IdP asks you to sign in (usual username and password for that).
5. Your IdP gives your browser a signed certificate, this lasts for 24 hours.
6. Your browser generates an ‘Assertion’. This is proof that you own your email and is generated using your private key (held in the browser) and contains the domain of the site you are signing in to, and an expiry date for the assertion.
7. Both the assertion and your signed certificate are sent to the RP.
8. Using your public key (provided by your browser) the RP verifies that your assertion looks OK.
9. The RP requests your IdP’s public key (but does not send any information about the user) and uses it to verify that the certificate from them that your browser passed on is also OK.
10. You are logged in.

Quite a lengthy process! However it is decentralized, secure, and respects your privacy (your identity provider cannot track what websites you are visiting).

If this alone was the only method of implementing BrowserID, there would definitely be an issue with uptake. Fortunately that’s where Mozilla Persona comes in.

Mozilla Persona

Mozilla Persona is a third-party services that provides a nice REST API on top of all this public key cryptography.

• Persona handles checking with Identity Providers and also acts as its own Identity Provider for services that don’t run their own (every email provider right now).
• Persona provides a REST API for validating assertions.

By dealing with all the cryptography, implementing BrowserID becomes a few lines of JavaScript (the login button and callbacks to POST the assertion to your server) and a cURL request (to validate the assertion).

Want to use it?

The first place you should visit is the Persona Quick Setup, which gives you instructions on adding Persona to your site with JavaScript examples and a Python implementation of assertion verification (it’s really, really easy though). In total it’s about 60 lines of code.

Then you should probably check the best practices to make sure you’re not doing anything bad.