Trying out Mozilla Persona (BrowserID)

The problems with authentication.

Getting user authentication on a new website right is up there with uploading media content. It’s a problem with a million different solutions, and every single one of them is painful to implement.┬áThe Mozilla Persona project, conceptually, is designed to fix many of these pain points. I tried it myself on a proof-of-concept site I’m building to see how effective it was, and found a mixed bag of good and bad.

The main issues that Persona seem to focus on solving are:

Registration. If the registration or sign-in process is too onerous, you will lose users. If it is not onerous enough, users will not trust you with any sort of valuable information.

Password security. Passwords in a home-grown solution must be encrypted with a salt, and your database must be absolutely safe. Sending out a mass email to all your customers saying that their passwords may have been compromised is very bad for business.

Support services. If you don’t want to be continuously fielding support requests for lost or forgotten passwords, you need a password reset system. You also need a way for users to change their password or identity credentials.

Single Sign On. If you want to have your site spread over multiple domains you need some form of single sign-on, a way to use the same account and sign-in process on all of your sites without constantly re-creating sessions across multiple domains.

Implementation costs. Creating all of the required code, even if you can use an off-the-shelf library to solve a large chunk of the functionality, is time consuming, error prone, and difficult to test.

Independence. Most third party sign on measures, things like OpenAuth’s “sign in with Google/Twitter/Facebook”, rely on you continuously calling back to the server, letting them know everything that the user is doing on your site. For highly security-focused users, this is a big minus.

In these aspects, Persona is a substantial improvement. There are some substantial issues though, which I will go into shortly.

Implementing Persona in a new website

This is one of the areas where Persona excels. Using their sample implementation code, it took me less than an hour from start to finish to get Persona working in a code base which previously had no concept of a logged in user. It was spectacularly straight forward. The process went like this:

  • Load a javascript library from the Mozilla CDN in your HTML page.
  • Add two callbacks to your pages, one for log in and one for log out. These callbacks should point to your own server end points for these actions.
  • Create the two server end points for log in and log out. I grabbed the sample NodeJS implementation and tweaked it slightly, but it pretty much would have worked out of the box.
  • Update your routes so that any page which should recognize the user has access the the currently logged in user ID (from the version stored in the session.

Voila, instant authentication! For new users, the registration pop up window prompted them to create a new Persona identity. For existing users, they could choose between one of the identities they had already created. Instant log-in, without even needing to re-type their password.

The user’s account travelled from page to page with them, and when they logged out they were logged out… Sort of.

The Account Security Problem

This was the first, and possibly the most significant issue I had with persona. It is effectively forcing users to have their usernames and passwords saved in their browser for all Persona apps. If you sign out of one application, all someone has to do to log back in again is click the “log in” button; the usernames and passwords are all stored silently in the browser.

Sign out doesn’t mean what you think it means.

The simple version, then, is that sign out effectively becomes a two stage process. If you don’t want anyone else to access your account on a Persona enabled service, you have to log out of that site, then log out of Persona. Of course, this then logs you out of all Persona services.

Sign in on one Persona site means sign in to all Persona sites

If you log in to a different site using Persona, you’ve now effectively unlocked all of your persona sites in that browser window. The sites won’t immediately recognise that you are logged in, of course, but all a user needs to do is click “sign in” on the specific site and pick your email address from a list. No verification at all.

Not as independent as it seems

The goal of having a sign-in solution which doesn’t “call-home” on each page is apparently still a work in progress with Persona. Because their implementation is changing frequently at this point, and the process for authentication is quite complex, they recommend against self-hosting the persona js scripts. The downside of this is that every page of your site must remotely import a js script from the Mozilla servers. It is most definitely calling home to mozilla for each and every action. User validation also slows down page load quite substantially. I don’t have exact numbers, but it was a bit enough difference that I became aware of a slow-down as a user.

Final thoughts

If you have a blog and want to invite people to leave comments as a signed-in user, Persona seems like a great tool. It would streamline the account creation and sign in processes elegantly, and the risk to the user should someone else be able to log in to that blog using their identity is very low. But for sites where you use your account to access any kind of personal data, things like photos or schedules or anything which you may want to have some level of privacy controls over, it becomes much higher risk. If you ever want to deal with any sort of financial transactions locked behind a sign-in screen, Persona seems like a very unwise idea.

Leave a Reply

Your email address will not be published. Required fields are marked *

*