PyCon: Mozilla Persona

At first blush, PyCon doesn't seem like quite the right venue for a talk on Mozilla's Persona web authentication and identity system. Persona is not Python-specific at all, but given the number of web application and framework developers at the conference, it starts to become clear why Mozilla's Dan Callahan was there. Python also gave him the ability to do a live demo of adding Persona support to a Flask-based web site during the well-attended talk.

Kill the password

In a nutshell, Persona is Mozilla's attempt to "kill the password", Callahan said to applause. It is a simple, open system that is federated and works cross-browser. Beyond that set of buzzwords, though, the idea for Persona is that it "works everywhere for everyone".

For an example of using Persona, Callahan visited ting.com—a mobile phone service site from Tucows—that has a login page supporting Persona. Clicking the "Sign in with Persona" button popped up a window with two of his email addresses and a sign-in button. Since he had already used the site before, to log in he just needed to choose one of his email addresses (if he is using a different address from the last time he visited the site) and click "Sign in". It's "dead simple", he said.

Persona ties identities to email addresses. That has several advantages, he said. Everyone already has an email address and sites often already track them. For many web sites, adding Persona support requires no change to the database schema. That also helps prevent lock-in, as sites that decide not to continue with Persona are not stuck with it.

Some in the audience might be saying "I can already log in with two clicks" using a password manager, Callahan said. That's true, but Persona is not managing passwords. There is no shared secret between the site and the user.

That means a database breach at the site would not disclose any information that would be useful for an attacker to authenticate to the service as the user. While site owners will need to alert their users to a breach, they won't have to ask them to change passwords. Better still, they won't have to recommend that the users change their identical passwords at other sites.

If there are no shared secrets, many of the existing account registration questions can simply be skipped. The Persona sign-in process provides an email address, so there is no reason to prompt for that (twice in many cases), nor for a password (twice almost always). For example, with sloblog.io and an existing Persona, he can set up a blog with two clicks.

To prove a point, he was doing his demos from the Opera web browser. Persona works the same in all major browsers (Firefox, Chrome, Safari, IE). It uses existing technology and standards and "works everywhere the web works", he said.

The story behind Persona comes right out of the Mozilla Manifesto, Callahan said. That manifesto was "written at the height of the browser wars" and lists ten points that are "crucial to the open web". Principle #2, "The Internet is a global public resource that must remain open and accessible", is particularly threatened today, while principle #5, "Individuals must have the ability to shape their own experiences on the Internet" speaks directly to the Persona ideal. Nothing is more important to shape one's internet experience than is the choice of identity, he said.

"Single" sign-on

There has been a movement toward single sign-on (SSO) in recent years, but "single" is a misnomer at this point. Many sites allow people to sign in with their Facebook or Twitter (or Google or Yahoo or MSN or ...) account. His slide had an example login with a bunch of login icons for those services, ending with a "Good luck with OpenID" button.

The problem with that approach is that it is like Tribbles (with a requisite Kirk and Tribbles slide); there are more and more of these service-based login mechanisms appearing. How does a site pick the right one (or, more likely, ones)? How does a user remember which of the choices they used so they can use it on a subsequent visit?

He gave another example: the 500px login screen. It splits the screen in half, into two sets of choices, either logging in via a social network (Facebook, Twitter, or Klout) on one side, or with a username and password on the other. If a user wants to use a Google or Microsoft login, they are out of luck. They must create a username and trust that 500px will do the right thing with their password. He was also amused to note that he hadn't heard of Klout, so he visited to see what it was and Klout wanted him to log in using either Facebook or Twitter.

There are also some implications of using the login network of certain services. Google and Facebook have real-name policies that can sometimes lead to account suspension when a violation is suspected. That suspension then trickles out to any other services that use those login mechanisms. Facebook policies disallow multiple accounts (e.g. personal and business) as well. Basically, services using Facebook logins are outsourcing their account policies to Facebook.

It is worth a lot of money for the social networks to get their buttons onto sites, Callahan said. So "any solution has to come from someone outside who is not trying to make a buck off every login". Since Mozilla is on the outside, it is well positioned to help solve the problem.

The earlier Persona demonstrations were for email addresses that had already been set up, but Callahan also wanted to show what happens for users who are not yet signed up. In that case, the user must type in an email address in the Persona pop-up. Persona checks with the email provider to see if it supports Persona, if so the email provider authenticates the user via its normal mechanisms (e.g. web-based login) that the user has seen plenty of times before. If the user successfully authenticates, the email provider indicates that to the site.

Using Persona team members as props, Callahan showed the process. The user claims a particular email address and the site contacts the email provider for verification. The email provider asks the user to authenticate (using a password, two-factor authentication, facial recognition, ...) and if that is successful, the provider signs the email address and hands it back to the site (along with some anti-replay-attack data). The site then verifies the signature, at which point it knows that the user has that email identity.

Implementing Persona

As can be seen, the description of the protocol and cryptography used was rather high-level. Callahan's clear intent was to try to convince web application and framework programmers to get on board with Persona. There is more information about the underlying details at developer.mozilla.org/persona, he said.

For the moment, few email providers support Persona, so as an "optional temporary" measure, sites can ask Mozilla to vouch for the email address. For example, Gmail does not support Persona (yet), but Mozilla can vouch for Gmail users by way of a challenge email. Authenticating the email address to Mozilla need only be done once. But that puts Mozilla in the middle of each initial authentication right now; eventually the user's email providers will be serving that role.

The documentation lists four things that a site owner needs to do to use Persona. There is a JavaScript library to include in the login page, the login/logout buttons need "onClick" attributes added, and the library needs to be configured. The final piece of the puzzle is to add verification of the identity assertions (signed email addresses from the email provider or Mozilla). That verification needs to be done in the server-side code.

In the future, the hope is that browsers will natively support Persona, but for now the JavaScript is needed. On the client side, it is 30 or so lines of JavaScript called from the login and logout paths. The server side is a little more complicated, as assertions are cryptographically signed, but that verification can be handed off to a service that Mozilla runs. The back end just posts some JSON to the Mozilla service and reads its response. Those changes take less than 40 lines to implement.

Using the code directly from his slides, Callahan changed both client and server sides of a demo application. That added the "great user experience" of Persona logins. It also showed an "amazing developer experience" in how easy it is to add Persona. Once the demo was done, and the applause died down, Callahan said "I am so glad that worked" with a relieved grin.

Callahan had three tips for site developers adding Persona support. The first was to make a library specific to the framework being used that can be reused in multiple applications. Second, his example used the Mozilla verifier, but that is not a good long-term solution for privacy reasons. But, he cautioned, make sure to use the Python "requests" library when doing verification as the standard library does not check SSL certificates properly. Lastly, he wanted to make it clear that using Persona did not mean that a site had to get rid of the other login buttons, "just that maybe you should", he said. Persona can peacefully coexist with these other login mechanisms.

In conclusion, Callahan said he had a request: "spend one hour with Persona this week". You could add it to your site in an hour, he said, but if not, just try it out on some site. Persona is still in beta, so it is "able to be shaped by your feedback". Also, he requested, please ask one site that you use to support Persona, "that's how we are going to change the future of the web". Persona will allow everyone—not just the few who understand OpenID or password managers—to have a safer, more secure web.

[ In keeping with Callahan's request, we will be looking into Persona support for LWN. ]