Part I: the Primary Protocol
See also: Part II: Secondary Services
Here’s what you need to know about Persona
It’s a way to sign into websites using any email address that belongs to you.
That’s it. We’ve specifically designed Persona to be easy and straightforward, so that you can sign in to your favorite websites in just a couple of steps.
But if you’re here, you probably want to know more. Maybe you’ve used Persona (successfully, we hope) and are wondering what’s going on under the hood. Maybe you’re considering implementing Persona on your own website but want to be sure you understand it first.
Whatever your reasons, this article aims to give a comprehensive but accessible overview of the Persona system. If you want something shorter and terser, consider reading the protocol overview or check out some of our other resources.
So what is Persona, again?
Persona is a way to sign into many different websites using the same set of credentials (an email and a password). Rather than creating multiple accounts with the same information, you have one account that you can use everywhere. And when you sign in, you always authenticate with your identity provider — not the website itself.
You can already see some of the security benefits. Much as we know we shouldn’t, we tend to reuse our passwords. With fewer passwords to remember (just one!), we as users can put more effort into having a better password. And because you’re not storing your password with the website, your account is safe even if that site is hacked.
Okay, cool, but this sounds familiar
Single sign-on is not a new idea. OpenID, Facebook, Google, Microsoft, Twitter, and Yahoo also provide ways of signing into websites using a single account — provided by the respective service.
Persona, we believe, offers advantages over all of these services. However, to better understand them, it’s useful to know a bit about how Persona works. We’ll talk about that now and come back to this question later.
The backstory
Imagine that you opened up a library, and I am your first patron. Sensibly, instead of just sending me out the door with a book, you want me to open an account and ask for my street address. (That way, if I forget to return the book, you can send me a reminder, and if I don’t return it still, you and a couple dozen of your buddies can come by and pick it up in person).
“Oh, sure, no problem. I live at 115 Waterman Street,” I tell you, and head out the door.
“Wait one cotton-picking minute here!” you exclaim. “How do I know you’re not lying?”
You have a good point. Look at you as I may with my large, puppy-dog eyes, you don’t really have a good reason for trusting me or my information.
You do, however, trust the postal service. So you have an idea.
“I’ll tell you what,” you say. “I’ll send your library card to the address you gave me, and when you get it, you can come back and check out books.”
This is an effective and perfectly serviceable solution to the problem you’re facing. You’re doing what many websites do in similar situations: send the user a verification message and wait until they act on it to activate their account.
So what’s the problem?
Well, it’s not very efficient, is it?
It’s annoying for me, because I have to go home and wait for my card to arrive. And what if, for some reason, it doesn’t? Letters, like emails, get lost sometimes. Then I have to come back and ask you for a new one.
It’s not good for you, the library, either. By preventing immediate access to your content, you are liable to lose patrons. Maybe I wanted that book right away and, unable to get it from you, I ended up in a bookstore.
A better way to verify identity
What you’d like is a way to verify my identity on the spot, without waiting for a letter to arrive at my address. The solution is so intuitive you barely have to think about it: you just ask for my ID. I hand you my driver’s license, you check my address against it, and, soon enough, I’m walking out the door, book in hand.
The same idea lies at the center of Persona. Sites that use Persona for authentication verify your address directly with your identity provider — not the government, like in the example, but whoever issued your email address.
Understanding the verification process
Verifying an email with its domain is not exactly straightforward. It’s not enough, for example, to ask it if an email address exists — just like it wouldn’t suffice for you, the library owner, to look up my name and address in the phone book. I could be pretending to be someone else, but you’d never know! I had to prove to you not only that the address existed, but that I was who I said I was.
I did this by showing you my driver’s license. It helps to dig deeper into why this was satisfactory.
The driver’s license is a certificate issued by the government that identifies me as Nathan Malkin using my picture, hair and eye color, height, weight, and signature. It certifies, “yes, Nathan Malkin lives at this address.” And, it provides some mechanisms for verifying it as an official government document (watermark, etc.).
I obtain my license from the government, then I give it to you. The first thing you do is make sure it isn’t fake. When you’re convinced that it’s legitimate, you check that I match the description of the person on the ID. Finally, having ascertained that, you compare the address on the ID to the one I provided. Are they the same? Great! You’ve successfully verified my identity and my address.
The verification flow followed by Persona maps fairly closely to the steps you just followed. We’ll get to the technical details in just a moment, but first, a quick diversion.
A note on cryptography
Whenever we want to do anything securely using computers, we use cryptography. The BrowserID protocol, specifically, relies on the principles of public key cryptography and digital signatures. A detailed explanation of how these work is outside the scope of this article; if you want to learn about them, Wikipedia is a good place to start. If, on the contrary, you’re well acquainted with them, you may wish to consult the BrowserID protocol specification directly.
Here’s what you need to know
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.
How Persona does verification
Nice as it would be to delegate the task to someone else, if you’re getting a driver’s license, you have to brave the lines of your DMV yourself. Thankfully, when you’re signing in with Persona, your browser does all the work for you (hence the name of the protocol, BrowserID).
So when I come to your site, www.your.library, and try to sign in with my email, nathan@example.domain, it is my browser that initiates the authentication process.
User certificate provisioning
The first thing the browser has to do is obtain my “driver’s license.” For that, it goes to the domain that issued my email address. (If it supports the BrowserID protocol, we call it a Primary Identity Provider, or IdP for short.) To example.domain, my browser says, “Hey, can you certify that Nathan here is the owner of nathan@example.domain”?
The IdP is about to certify my identity, so it better be sure I’m the right person. How can it tell? Well, if it’s a web-based mail service, I could already be logged in. In that case, it’s easy, I don’t have to do anything. It’s like renewing your driver’s license: you just turn in your old license, and you’re set.
Otherwise, as when getting a new license, I would need to prove my identity to the authority. In BrowserID, your browser will open a page on your email provider’s site, where you’ll need to sign in with your password. (In a world where everyone used Persona, this would be the one password that you’d still have.) After you’ve done that, the IdP should be fully convinced that you are the owner the email address and ready to vouch for you.
As we discussed, my driver’s license has several pieces of information (picture, signature, biometric data) that identify me as its owner. Here’s how example.domain can be similarly unambiguous about who it’s vouching for.
Remember digital signatures and keys? After I’ve signed into example.domain, my browser generates a key pair: a private key and a public key. It holds on to the private key (it wouldn’t be very private, otherwise) and sends the public key to the IdP.
example.domain has its own public/private key pair. It uses the latter to sign the user certificate confirming my own identity. The certificate contains the public key my browser sent over, the email address in question, and also an expiration date. (Like driver’s licenses, user certificates don’t last indefinitely). The signed certificate is returned to the browser.
Note again that the user certificate contains all the elements you looked for in a driver’s license. It has the address that you’re trying to verify, it’s tied to my identity (my browser, specifically, by containing its public key), and it’s provably issued by the IdP (it’s signed by their digital signature).
Assertion generation and verification
Having obtained the user certificate, my browser turns it over to www.your.library. (We call your site a Relying Party, or RP.) This is where you come in.
Like you did with my driver’s license, you first want to make sure that my user certificate isn’t fake. It’s signed, as you may remember, by example.domain’s private key. So if you get the domain’s public key and decrypt the signature, it has to match the certificate; if it does, you know it’s valid. And this is exactly what you do. (example.domain’s public key is made available as part of the BrowserID protocol.)
Now that you’ve verified the certificate, you trust it and its contents. All you have to do now is check that the email address in the certificate matches the one I’m trying to sign in with.
But wait! You verified the authenticity of the certificate, but you forgot to check if it was issued to me. (Maybe I stole someone else’s.)
To make this work, along with the user certificate, my browser also gives the RP (i.e., you) my email address, encrypted with its private key. Remember, the user certificate (which you have verified and therefore now trust) contains my public key, which you can use to decrypt the message. If you decrypt it successfully, finding my email address as its contents, then you know that my browser is the same browser the IdP was vouching for.
At this point you’ve:
- Checked the authenticity of the user certificate
- Verified that the certificate was issued to me
- Confirmed that the email address I’m using to sign in is certified by the IdP
Now, truly, you’ve verified my identity as the owner of nathan@example.domain. Phew.
The advantages of Persona
Now that you understand how the Persona protocol works, we can go back and discuss some of the advantages of Persona over other single sign-on services.
Recall that when I was signing in to www.your.library, my browser got a user certificate from example.domain, but it never told the IdP why it needed it, i.e., where you were going to sign in. In contrast, all other single sign-on services communicate with sites directly, so Microsoft, Twitter, and the others know exactly what sites you’re signing in to. With Persona, this information is left between you and the website.
With Facebook and Google increasingly pushing real-name policies, our accounts on those sites have become closely associated with our real-world identities. And when you sign in to sites using those services, that association may get passed along as well. Persona recognizes that we may have different…well…personas that we use online: a work-persona, school-persona, home-persona, etc. Rather than locking you into one of those, Persona lets you choose. It’s as easy as clicking a button: which of your email addresses, your browser will ask you, do you want to use?
Say you’re signing in to a new site that you don’t necessarily trust. Authenticating through Facebook, you would have to ask yourself, do I trust this site with my name and personal information? With Persona, if you’re worried, you can just use a throwaway address and sign in. There is even an advantage in this to the site: fewer people will be turned away at the outset; they can start engaging (and be won over!) quicker.
That’s it
Congratulations! If you’ve made it this far, you should have a solid understanding of the core BrowserID protocol.
But wait, there’s more!
To make Persona work seamlessly for everyone, users and developers, we provide a number of services that are described in Part II: Secondary Services. If you’re using an older browser, if your email provider doesn’t support BrowserID, or if you’re a developer who doesn’t want to deal with the minutia of the protocol described above, Persona will still work for you. If you want to know how, read on!