Persona makes signing in easy for Gmail users(identity.mozilla.com)
identity.mozilla.com
Persona makes signing in easy for Gmail users
http://identity.mozilla.com/post/57712756801/persona-makes-signing-in-easy-for-gmail-users
121 comments
Persona isn't a panacea. If websites collude, and you use the same address on each site, then they'll be able to correlate their user tables.
That's identical to the status quo, and fixing it is not one of Persona's explicit goals.
We're very consciously trying to hit a pragmatic middle ground that moves the web closer to user empowerment, without being so different as to hinder adoption. Consider: if you're already collecting email addresses for your users, you can immediately start using Persona without changing any of your assumptions about your data model. It's portable and it dovetails into current practices.
However, it is technically possible to do what you want right now, so long as you have your own domain and write a small browser extension. Longer term, we're currently working with a partner on a possible extension to the provider protocol which would make it easier to implement that sort of "directed identity."
That's identical to the status quo, and fixing it is not one of Persona's explicit goals.
We're very consciously trying to hit a pragmatic middle ground that moves the web closer to user empowerment, without being so different as to hinder adoption. Consider: if you're already collecting email addresses for your users, you can immediately start using Persona without changing any of your assumptions about your data model. It's portable and it dovetails into current practices.
However, it is technically possible to do what you want right now, so long as you have your own domain and write a small browser extension. Longer term, we're currently working with a partner on a possible extension to the provider protocol which would make it easier to implement that sort of "directed identity."
Can't they already do this based on your email address they have on profile?
To be fair, this is not really Persona's responsibility. Pre-Persona, if you used the same email address on every signup, you already enabled this sort of tracking. With Persona, you'd have to take the same precaution of having multiple Personas if you wanted multiple personas :).
Also some people do want a single identity for the entire Internet, or at least a lot of it. Many people use the same real-name identifiers on HN, Github, LinkedIn, etc. professionally.
Also some people do want a single identity for the entire Internet, or at least a lot of it. Many people use the same real-name identifiers on HN, Github, LinkedIn, etc. professionally.
I've seen a few demos of this. The developer story is great.
Easy to integrate, no need to worry about screwing up storing passwords and you are not abdicating authentication to some evil or possibly evil in the future, company.
Easy to integrate, no need to worry about screwing up storing passwords and you are not abdicating authentication to some evil or possibly evil in the future, company.
Not trying to troll or anything, but how do we know Mozilla won't be evil in the future? I'm sure you could find people who thought that about Google back in the day, they seem to now be routinely called out for questionable evils.
Mozilla is a global non-profit organization dedicated to building a public good -- an Internet that works for everyone.
Google is a giant multi-national corporations that measures revenue in the tens of billions of dollars per quarter.
That means that Mozilla's responsibility is to the people of the world and Google's responsibility is to maximize financial returns for the the already well-off financial class that invested in Google stock.
Does that help you see the difference?
Google is a giant multi-national corporations that measures revenue in the tens of billions of dollars per quarter.
That means that Mozilla's responsibility is to the people of the world and Google's responsibility is to maximize financial returns for the the already well-off financial class that invested in Google stock.
Does that help you see the difference?
Well.. I agree with you here. We can never really tell.
AFAIK Right now there are two things that Mozilla controls.
1) login.persona.org that takes care of authentication
2) a JavaScript shim that developers add to their sites to get the login button to work.
Persona is designed in such a way that reliance on Mozilla will be phased out as email providers take care of #1 and as browsers start to implement #2. As of now I think FireFox is the only browser that has #2 baked in.
1) login.persona.org that takes care of authentication
2) a JavaScript shim that developers add to their sites to get the login button to work.
Persona is designed in such a way that reliance on Mozilla will be phased out as email providers take care of #1 and as browsers start to implement #2. As of now I think FireFox is the only browser that has #2 baked in.
Actually, only FirefoxOS has #2 baked in. Everything else is using the shim.
I'm pushing us to get our data formats stabilized in the next few months so that we can start building native extensions for browsers and get ourselves completely out of that loop.
It's worth thinking of Persona as the reference implementation of the BrowserID protocol. If we're successful, Persona as you know it automatically disappears as more and more domains and browsers add native support for the protocol. :)
I'm pushing us to get our data formats stabilized in the next few months so that we can start building native extensions for browsers and get ourselves completely out of that loop.
It's worth thinking of Persona as the reference implementation of the BrowserID protocol. If we're successful, Persona as you know it automatically disappears as more and more domains and browsers add native support for the protocol. :)
I hope there will soon be a way to `apt-get install mozilla-persona` on a personal server. That would seriously help the deployment a really decentralized Persona.
Tell me more!
Do you want Persona authentication on your website or do you want a deamon that is an identity provider for your personal domain?
What language or platform would be ideal?
Do you want Persona authentication on your website or do you want a deamon that is an identity provider for your personal domain?
What language or platform would be ideal?
I have to use different computers throughout the day and I use Lastpass to manage passwords on my laptop. It would be awesome if there were a WordPress plugin that would allow users/admin to log-in using Persona/Gmail. That way when I am already logged in to my gmail I can use Persona/Gmail to log into my wordpress account and resume writing.
UPDATE:- There is a plugin like that http://wordpress.org/plugins/browserid/ . Too bad it doesn't work with Google Apps.
UPDATE:- There is a plugin like that http://wordpress.org/plugins/browserid/ . Too bad it doesn't work with Google Apps.
I run my own mail server. Linux + Postfix + Dovecot. The standard stuff. How do I enable Persona on [email protected] ?
Check out the docs under the "Identity Providers" heading here: https://developer.mozilla.org/en-US/docs/Mozilla/Persona
Shane Tomlinson and I gave a talk about turning your own domain into a Identity Provider at FOSDEM this year, which might be helpful: https://www.youtube.com/watch?v=0YRq9LWnlBw
Also, if you'd like to source dive:
- Minimal, static, Mailinator-style IdP: https://github.com/callahad/mockmyid/
- Minimal standalone IdP: https://github.com/mozilla/eyedee.me/
- Mozilla Employee (LDAP) IdP: https://github.com/mozilla/vinz-clortho
- GMail Bridge: https://github.com/mozilla/browserid-sideshow
And there's a Drupal module: https://drupal.org/project/browserid_idp
Shane Tomlinson and I gave a talk about turning your own domain into a Identity Provider at FOSDEM this year, which might be helpful: https://www.youtube.com/watch?v=0YRq9LWnlBw
Also, if you'd like to source dive:
- Minimal, static, Mailinator-style IdP: https://github.com/callahad/mockmyid/
- Minimal standalone IdP: https://github.com/mozilla/eyedee.me/
- Mozilla Employee (LDAP) IdP: https://github.com/mozilla/vinz-clortho
- GMail Bridge: https://github.com/mozilla/browserid-sideshow
And there's a Drupal module: https://drupal.org/project/browserid_idp
As I mentioned below, I also wrote a service to turn your domain into an identity provider (so you can log in with [email protected]): https://persowna.net/
It's free for now, and will probably always be free for individual usage.
It's free for now, and will probably always be free for individual usage.
Here's another one:
There's a couple of posts on meta.discourse.org asking how to integrate Discourse with an existing Single Sign On (assume all users have email addresses)
With Persona on a LAN-side server, you could even have emails like [email protected] and it'd still be seamless.
There's a couple of posts on meta.discourse.org asking how to integrate Discourse with an existing Single Sign On (assume all users have email addresses)
With Persona on a LAN-side server, you could even have emails like [email protected] and it'd still be seamless.
I want to be my own identity provider, which ever web technology, php, ruby, python, JavaScript.
This is a NodeJS personal project that I use to host my identity: https://github.com/ozten/hostedpersona
https://ozten.com/.well-known/browserid (a static website) delegates to https://hostedpersona.me/.well-known/browserid which I run on an ec2 instance.
This clearly isn't as polished as aptitude install, but feel free to fork and play.
https://ozten.com/.well-known/browserid (a static website) delegates to https://hostedpersona.me/.well-known/browserid which I run on an ec2 instance.
This clearly isn't as polished as aptitude install, but feel free to fork and play.
I wrote a service so you don't have to do any of that: https://persowna.net/
Just add the .well-known file to your site, and that's it.
EDIT: Actually, I might just open-source this and keep the hosted version for people who want convenience.
Just add the .well-known file to your site, and that's it.
EDIT: Actually, I might just open-source this and keep the hosted version for people who want convenience.
Side note, Your font differs on https://persowna.net/pricing/ and https://persowna.net/ for the logotype.
Awesome job on the site!
Awesome job on the site!
Oops, good catch! Thanks!
EDIT: This is really odd, it's the exact same HTML/CSS, yet a different typeface. Weird.
EDIT 2: It would help if I had actually included the font in the header. Thanks again :)
EDIT: This is really odd, it's the exact same HTML/CSS, yet a different typeface. Weird.
EDIT 2: It would help if I had actually included the font in the header. Thanks again :)
Dude, that's awesome! I didn't know you were ready to accept sign-ups. Will try to mention it more often. :)
Man I told you about it like three times on IRC (and that was your response then, too)! :P
It's still early-stage, but it works very well for plain authentication. Next step is two-factor auth.
It's still early-stage, but it works very well for plain authentication. Next step is two-factor auth.
Whichever technology you want to use is fine. You need to publish 3 routes: /.well-known/browserid, an auth route, and a provision route.
The auth and provision routes need to be HTML pages that authenticate you however you want, and then sign a certificate with your key that you publish the .well-known file.
Here's how we did it for Gmail: https://github.com/mozilla/browserid-sideshow/blob/master/bi...
The auth and provision routes need to be HTML pages that authenticate you however you want, and then sign a certificate with your key that you publish the .well-known file.
Here's how we did it for Gmail: https://github.com/mozilla/browserid-sideshow/blob/master/bi...
I wrote a blog post about implementing an IdP from scratch in Python. (Uses Django, but the lessons should be transferable). https://lukasa.co.uk/2013/04/Writing_A_Persona_Identity_Prov...
Really excited for this. Password authentication is an absolute disaster on the Internet, and despite at least 8 years of development solutions like OpenID are not succeeding fast enough. Mozilla Persona looks really promising. Sure wish there were a Chrome extension for it!
There isn't a Firefox extension yet, either. :) JavaScript polyfills are fun!
(Persona works on all major browsers, save MobileIE and Chrome for iOS. Fixes are in the works for those two.)
(Persona works on all major browsers, save MobileIE and Chrome for iOS. Fixes are in the works for those two.)
I wish TLS-SRP was more prominent or that some mutual auth protocol was common (http://arxiv.org/abs/0911.5230).
Then you're never sending anything sensitive to the server.
Sure, it still has the issue of the user choosing a good password, but persona doesn't really get around this, just makes the mail server deal with it.
Then you're never sending anything sensitive to the server.
Sure, it still has the issue of the user choosing a good password, but persona doesn't really get around this, just makes the mail server deal with it.
I wish Hacker News used Persona.
It used some another (failed?) provider before (which connected accounts to Gmail, Yahoo, etc.)
HN was using Clickpass (YC Summer 07), which was acquired and shuttered by Janrain early last year. Amusingly enough, Stack Overflow still has a (broken) Clickpass button on its login page.
If I recall correctly, Clickpass was a centralized OpenID proxy, whereas Persona is trying to bootstrap a fully decentralized protocol. We don't want to even be able to track you. :)
[Edit: Corrected YC cohort. Thanks wamatt!]
If I recall correctly, Clickpass was a centralized OpenID proxy, whereas Persona is trying to bootstrap a fully decentralized protocol. We don't want to even be able to track you. :)
[Edit: Corrected YC cohort. Thanks wamatt!]
I believe Clickpass was YC '07. Falling short of a Series A raise, Yola/Synthasite acquired them in 2008 [1]
Then a few years later (2012), Yola sold the IP and users to Janrain [2]
[1] https://news.ycombinator.com/item?id=402973
[2] http://janrain.com/clickpass-acquired-by-janrain/
EDIT: my pleasure callahad :)
Then a few years later (2012), Yola sold the IP and users to Janrain [2]
[1] https://news.ycombinator.com/item?id=402973
[2] http://janrain.com/clickpass-acquired-by-janrain/
EDIT: my pleasure callahad :)
"Amusingly enough, Stack Overflow still has a (broken) Clickpass button on its login page."
Where? I can't see it.
Where? I can't see it.
The button was removed a few hours ago: http://meta.stackoverflow.com/questions/192501/remove-obsole...
It had (has?) OpenID support.
had. was dropped a while back :'(
Hilariously it was dropped with no real notification, and one day my account just stopped working. I had to make a new one, because there was no way to access my previous account.
No where in that headline does it mention OpenID -- and I have no idea what ClickPass is. Nor was it a persistent announcement; it was just a regular story. Perhaps I didn't even check HN that particular day?
There are many ways they could have notified OpenID users that would have worked -- this wasn't really one of them!
There are many ways they could have notified OpenID users that would have worked -- this wasn't really one of them!
Yeah, I very luckily had my account still logged in on one browser, and was able to save it :|
The only bad thing with this new Gmail integration is that it gets more annoying if you have multiple Gmail accounts, or aren't logged in to the Gmail account you want to use.
And some things, like using [email protected] doesn't work at all.
And some things, like using [email protected] doesn't work at all.
I highly recommend using Chrome's multiple user feature to log into your separate gmail accounts. This is the only thing that has kept me sane at the last couple companies where we used Google Apps.
I use Firefox... and I don't think I wan't to be logged into multiple accounts - it's just that now Persona requires it.
FWIW - firefox has supported multiple profiles for years, long before Chrome even existed.
Run it with the following command-line arguments: -ProfileManager -new-instance
That brings up a profile picker/creater. Each profile is isolated, different plugins, different cookies, etc. The only information leakage is when a plugin keeps its own data outside of the profile directory, like Adobe Flash keeps its version of cookies in a per-user directory rather than a per-profile directory.
Run it with the following command-line arguments: -ProfileManager -new-instance
That brings up a profile picker/creater. Each profile is isolated, different plugins, different cookies, etc. The only information leakage is when a plugin keeps its own data outside of the profile directory, like Adobe Flash keeps its version of cookies in a per-user directory rather than a per-profile directory.
Oh yeah - I use about 5 different profiles with one main profile. It's not a solution, though: I want to be logged into [email protected] and log into other sites with [email protected] and I'd prefer to not have to be logged in there at all.
[email protected] should absolutely work -- please file a bug if not: https://github.com/mozilla/browserid-sideshow/issues/new
Huh - it does work, as you say. I guess I misremembered.
EDIT: Now I remember my use case.
My email is actually [email protected], and so I want to sign in with the same randomstring every time. Previously when signing in to Persona with my Gmail email address it would suggest all alternatives, and I'd choose the appropriate one. Now it logs in with Gmail directly instead.
Of course, this is such an edge case that it's probably not worth doing anything about. And I can simply sign into Persona with [email protected] for the previous functionality.
EDIT: Now I remember my use case.
My email is actually [email protected], and so I want to sign in with the same randomstring every time. Previously when signing in to Persona with my Gmail email address it would suggest all alternatives, and I'd choose the appropriate one. Now it logs in with Gmail directly instead.
Of course, this is such an edge case that it's probably not worth doing anything about. And I can simply sign into Persona with [email protected] for the previous functionality.
Yet another use case that's more difficult now: I use [email protected] for some sites where I expect to get lots of spam, and then forward email based on some filters.
We'll switch from proxying via OpenID to OAuth 2 in the next few months, which will make that seamless again thanks to the `login_hint` option to Google's OAuth endpoint.
I'm looking forward to when their LDAP adapter [1] is ready for prime-time so that we can use it internally for our own email addresses. I'm curious if the GMail adapter would work if you host your company email at google?
[1] https://github.com/mozilla/vinz-clortho/
[1] https://github.com/mozilla/vinz-clortho/
As callahad pointed out, it's already in use for some Mozilla sites, and I at least haven't seen any problems with it. In fact, I just logged into one (with my Mozilla LDAP credentials) earlier today :)
We're using Vinz Clortho in production right now (try to log in as [email protected] and you'll be prompted for my LDAP password).
It's not super generalizable, but if you're interested in rolling it out on your end, ping our mailing list (https://lists.mozilla.org/listinfo/dev-identity) and we're happy to support you while you get that going.
A generic Google Apps bridge is somewhat tricky, but we're really interested in prototyping it over the next few months.
It's not super generalizable, but if you're interested in rolling it out on your end, ping our mailing list (https://lists.mozilla.org/listinfo/dev-identity) and we're happy to support you while you get that going.
A generic Google Apps bridge is somewhat tricky, but we're really interested in prototyping it over the next few months.
If you just wanna try it:
http://myfavoritebeer.org/
and put your gmail in the box :)
http://myfavoritebeer.org/
and put your gmail in the box :)
It doesn't work with google apps, unfortunately.
Which is completely logical when I think about it since persona would not use the mx record to find the identity provider.
Which is completely logical when I think about it since persona would not use the mx record to find the identity provider.
Actually, why not?
Looking for that "aspmx.l.google.com" entry in the MX record would let them know, with a high degree of certainty, that Google is the login authority for that particular email address.
Is there something I'm missing?
Looking for that "aspmx.l.google.com" entry in the MX record would let them know, with a high degree of certainty, that Google is the login authority for that particular email address.
Is there something I'm missing?
There's the /.well-known/browserid [1] file that can be used to delegate a domain to another identity provider.
The main thing is that while Persona talks about email verification, the protocol doesn't require that email handling exists. Just that a server vouches for the existence of a user@host, so using MX records wouldn't be 'correct' even if it would be a useful heuristic for google apps domains.
There has been talk of using SRV records, but it looks like the .well-known/browserid file will be the recommended way to do things.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/.we...
The main thing is that while Persona talks about email verification, the protocol doesn't require that email handling exists. Just that a server vouches for the existence of a user@host, so using MX records wouldn't be 'correct' even if it would be a useful heuristic for google apps domains.
There has been talk of using SRV records, but it looks like the .well-known/browserid file will be the recommended way to do things.
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Persona/.we...
Persona harps on 'your email address is your id' part, but it's just a way to get an identifier @ a domain (so your login id doesn't actually have to be a real email address). At this point, persona (or the service implementing persona, more precisely) will ask the domain to authenticate the identifier.
Using the mx record would be bad, because, if you are doing it yourself, then your email server would have to also have a persona authenticating server, it would be hard to use your own persona authenticating server and have a third party take care of email, etc.
Using the mx record would be bad, because, if you are doing it yourself, then your email server would have to also have a persona authenticating server, it would be hard to use your own persona authenticating server and have a third party take care of email, etc.
As callahad said, there are some issues and it isn't a core priority for the team.
That said... here is one of the building blocks https://github.com/mozilla/browserid/issues/2932
Get involved and implement this as a NodeJS module.
That said... here is one of the building blocks https://github.com/mozilla/browserid/issues/2932
Get involved and implement this as a NodeJS module.
We're super interested in bridging to Google Apps, but it has some quirks that gmail.com itself doesn't, so it's on ice for the moment...
If you're interested in integrating Persona into your website, I've made a couple of examples of how to do it:
https://github.com/workhere-io/personaexamples
There's also a demo that shows how Persona works (doesn't save any of your info):
http://personaexamples.workhere.io/
https://github.com/workhere-io/personaexamples
There's also a demo that shows how Persona works (doesn't save any of your info):
http://personaexamples.workhere.io/
This seems like it just adds another click for gmail/yahoo users? I don't understand. Added another step to the login process and I think I'll have to change around some of my javascript to prevent returning users from "magically" authenticating after Persona gets around to authenticating them.
Weird. Oh well. Can't bitch much with a free service can I?
Weird. Oh well. Can't bitch much with a free service can I?
They replaced the step where you had to enter your "Persona password" with one click confirming your gmail credentials to Persona. You have to do it just once.
(And not even once per website, just once in a lifetime.)
(And not even once per website, just once in a lifetime.)
This makes it so gmail users don't need yet another password to log in to Persona-enabled sites. It effectively turns Persona into a superset of "login with Google".
If anyone wants to hear more about Persona and lives around the Edinburgh (Scotland) area then please feel free to pop along to a talk that one of the Persona developers is giving. https://edpug2013aug.eventbrite.co.uk/?ref=ecal
I'm really glad they finally added this. Persona is a great way to login and better for developers and users.
What is the benefit of this (from a developer/website perspective) over using OpenID? I can't really see the difference... obviously I'm missing something fundamental...
The main things are ubiquity, ease of use, and privacy.
- Persona works with any email address. This means you can reach anyone that hits your site, without forcing them to sign up with a third party provider.
- I can answer the question "what email address do you want to log in with?" I can't answer the question "what is your OpenID?" nor can I remember which of the 13 buttons on Stack Overflow I used last.
- OpenID requires phoning home with every login transaction. Persona explicitly does not. Your provider doesn't get to learn where you are logging in.
Edit: Put another way, can you tell me what your Google OpenID URL is without cheating? Can most people? If not, then you're only able to select a provider from a predetermined whitelist on each website. That undermines your ability to self-identify, self-assert, and choose who you trust. The open web deserves better.
- Persona works with any email address. This means you can reach anyone that hits your site, without forcing them to sign up with a third party provider.
- I can answer the question "what email address do you want to log in with?" I can't answer the question "what is your OpenID?" nor can I remember which of the 13 buttons on Stack Overflow I used last.
- OpenID requires phoning home with every login transaction. Persona explicitly does not. Your provider doesn't get to learn where you are logging in.
Edit: Put another way, can you tell me what your Google OpenID URL is without cheating? Can most people? If not, then you're only able to select a provider from a predetermined whitelist on each website. That undermines your ability to self-identify, self-assert, and choose who you trust. The open web deserves better.
http://profiles.google.com/xistence/
Or that was my Google OpenID at one point, not sure if it still acts like one or not.
Or that was my Google OpenID at one point, not sure if it still acts like one or not.
While the HN community understood that, my mother was never going to grasp the idea of ownership of a URL as a login credentials. Many people don't even understand URLs and just Google for everything they want.
Email addresses have been used as login credentials for a while, so people are used to that. The explanation of Persona might be a little weird, but it's not as totally disabling to a nontechnical user as being asked to sign in with OpenID.
Email addresses have been used as login credentials for a while, so people are used to that. The explanation of Persona might be a little weird, but it's not as totally disabling to a nontechnical user as being asked to sign in with OpenID.
In short: easier to implement, everyone has an email address, improved privacy. OpenID tells the provider every time you log in to any website, Persona does not.
https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Why...
https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Why...
1. Why the popup window?
2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
> 1. Why the popup window?
Persona follows the LIFD architecture: http://www.open-mike.org/entry/lifding-the-web
Popups allow us to create a nice messaging channel between the shim / localstorage at persona.org and the website the user is trying to log into, without losing their state on that website.
> 2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
Sure. Brand it however you want. "Sign in with your email" converts best. The popup will always follow the same basic form, but you are able to add your logo, a human readable name, and a background color to influence its design: http://identity.mozilla.com/post/55796551587/persona-a-login...
Check out the login on https://see.drupalpersona.me https://webmaker.org and https://ting.com for examples.
> 3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
Our UX folks are actively experimenting with this. Look for Ryan Feeley's posts on the dev-identity mailing list for some explorations.
Persona follows the LIFD architecture: http://www.open-mike.org/entry/lifding-the-web
Popups allow us to create a nice messaging channel between the shim / localstorage at persona.org and the website the user is trying to log into, without losing their state on that website.
> 2. Are developers permitted to strip the Persona branding - to make the login process seem to flow with the current website - not a bolt on?
Sure. Brand it however you want. "Sign in with your email" converts best. The popup will always follow the same basic form, but you are able to add your logo, a human readable name, and a background color to influence its design: http://identity.mozilla.com/post/55796551587/persona-a-login...
Check out the login on https://see.drupalpersona.me https://webmaker.org and https://ting.com for examples.
> 3. Would you consider including tiny profile icon links next to the button itself, to facilitate single-click profile sign-on/switch?
Our UX folks are actively experimenting with this. Look for Ryan Feeley's posts on the dev-identity mailing list for some explorations.
Does this mean that Google implemented a Persona endpoint for Gmail, or that Mozilla is now using OpenID (or whatever it is Google uses now) to piggyback on Google's existing login mechanisms?
Croikle's right. This is using Google's public OpenID endpoint to validate your email address, and bootstrap a Persona certificate. We did this independently of Google, though we are in informal contact with the relevant folks on that side of the Valley.
Judging by [1], the latter.
1: http://identity.mozilla.com/post/56526022621/what-is-an-iden...
1: http://identity.mozilla.com/post/56526022621/what-is-an-iden...
Can someone explain the security implications of Persona? In what ways is it more or less secure than other authentication mechanisms (username/password, two factor auth, etc)? Thanks!
Persona is basically just public-key cryptography, but with a nice interface on top.
What you're really doing when you sign in to your identity provider is getting a certificate, signed by them, and containing a serialized public key (from a keypair generated and stored in your browser).
What you're really doing when "signing in" to a Persona-enabled site is sending them the certificate and a signed assertion, and letting them check all the signatures (public key in the certificate verifies the signature on the assertion, and the provider's public key is obtained to verify the signature on the certificate).
The only entity involved in this who needs to get a password from you is the identity provider, and password auth isn't required for that; it's just an easy and common way to do it. Sites you log into using Persona never ask for, see, or store a password for you.
The certificates are transient (they expire within 24 hours). The assertions generated by your browser are transient (they expire within 5 minutes). The keypairs generated and stored by your browser can be transient (you don't need to use the same keypair each time you sign in to your identity provider), and are tied to a specific email address and browser instance.
The whole thing is also designed to be decentralized. For most people, for now, Mozilla is the identity provider, but you can run your own (relatively easy) or use a trusted third-party provider. All that matters in a provider is that it speaks the protocol.
This means that comparing Persona to "password authentication" or "two-factor auth" is not really a useful question; your provider can use any mechanism you both agree on to verify you and give you a certificate. Though the immediate big win is, of course, that if there's a password involved, only the provider ever handles it, so you don't have to worry about a bunch of sites' password-storage practices, and you may not even have to worry about your provider's (if your provider doesn't use passwords to verify you).
The provider also doesn't know what sites you're signing in to with Persona; they don't receive the assertion from the site you sign into, they just provide a copy of their public key so the site can complete verification.
What you're really doing when you sign in to your identity provider is getting a certificate, signed by them, and containing a serialized public key (from a keypair generated and stored in your browser).
What you're really doing when "signing in" to a Persona-enabled site is sending them the certificate and a signed assertion, and letting them check all the signatures (public key in the certificate verifies the signature on the assertion, and the provider's public key is obtained to verify the signature on the certificate).
The only entity involved in this who needs to get a password from you is the identity provider, and password auth isn't required for that; it's just an easy and common way to do it. Sites you log into using Persona never ask for, see, or store a password for you.
The certificates are transient (they expire within 24 hours). The assertions generated by your browser are transient (they expire within 5 minutes). The keypairs generated and stored by your browser can be transient (you don't need to use the same keypair each time you sign in to your identity provider), and are tied to a specific email address and browser instance.
The whole thing is also designed to be decentralized. For most people, for now, Mozilla is the identity provider, but you can run your own (relatively easy) or use a trusted third-party provider. All that matters in a provider is that it speaks the protocol.
This means that comparing Persona to "password authentication" or "two-factor auth" is not really a useful question; your provider can use any mechanism you both agree on to verify you and give you a certificate. Though the immediate big win is, of course, that if there's a password involved, only the provider ever handles it, so you don't have to worry about a bunch of sites' password-storage practices, and you may not even have to worry about your provider's (if your provider doesn't use passwords to verify you).
The provider also doesn't know what sites you're signing in to with Persona; they don't receive the assertion from the site you sign into, they just provide a copy of their public key so the site can complete verification.
You don't hand your password to anyone but your email provider - and they can implement two-factor authentication (or anything else they like) - as GMail have done, for instance.
Which means that 99% of sites don't need to worry about security for passwords, and you don't need to worry that your password has been stolen by hackers and now they're trying that same password on every site you might have ever used.
It's also decentralised, so there's no tracking of what sites you've logged in to. (Or, at least, it will be, once email providers implement IDPs themselves rather than using the Mozilla fallback). And the way the certification works, the IDP has no idea what sites you're signing into, so you're safe from that too.
Which means that 99% of sites don't need to worry about security for passwords, and you don't need to worry that your password has been stolen by hackers and now they're trying that same password on every site you might have ever used.
It's also decentralised, so there's no tracking of what sites you've logged in to. (Or, at least, it will be, once email providers implement IDPs themselves rather than using the Mozilla fallback). And the way the certification works, the IDP has no idea what sites you're signing into, so you're safe from that too.
Ok, that is a big deal.
Must add that to velruse.
Must add that to velruse.
This worries me a little. Perhaps because I don't fully understand what's going on under the bonnet. When I give a website my email address, some communication must happen between that website and persona. So there's some centralised persona server sending auth tokens back and forth between websites that use persona api? Am I misunderstanding?
If that's not the case, then what, exactly, information does website X have about me now that I have 'logged in using persona'?
If that's not the case, then what, exactly, information does website X have about me now that I have 'logged in using persona'?
I had this misunderstanding also, but if I understand it correctly...
Basically a site using Persona tries to send you to your email provider to authenticate. If your email provider is running Persona, you'll authenticate through them, and the email provider sends a token back confirming your identity.
Mozilla is the default identity provider for people whose email providers don't run Persona (yet). Once the project gains widespread adoption, Mozilla won't be processing much if any authentications because they'll be distributed to email providers.
Also it will in theory work as a browser extension, so your email provider sends your browser the token, and your browser sends the token to the websites you log in to. So your email provider doesn't know where you're logging in.
Basically a site using Persona tries to send you to your email provider to authenticate. If your email provider is running Persona, you'll authenticate through them, and the email provider sends a token back confirming your identity.
Mozilla is the default identity provider for people whose email providers don't run Persona (yet). Once the project gains widespread adoption, Mozilla won't be processing much if any authentications because they'll be distributed to email providers.
Also it will in theory work as a browser extension, so your email provider sends your browser the token, and your browser sends the token to the websites you log in to. So your email provider doesn't know where you're logging in.
>Also it will in theory work as a browser extension, so your email provider sends your browser the token, and your browser sends the token to the websites you log in to. So your email provider doesn't know where you're logging in.
I don't understand this. Presumably there's nothing stopping Website X sending both: a) my email address; and b) Website X's URL.
Scenario: Joe Bloggs tries to log in to www.SiteThatSellsCars.com using Persona. Joe enters his email address. SiteThatSellsCars sends Joe's email address and "www.SiteThatSellsCars.com" to Joe's ISP. This translates to SiteThatSellsCars saying, "Hey, Joe's ISP, Joe is looking to buy a car, you should send him a metric shit-load of car adverts. He might not like it, but whatever. Thanks for the $20!". Then Joe's ISP replies with, "I sent Joe a token to his browser so he thinks he still has his privacy, but fuck him. Every customer you tell us about, we'll give you $20."
Perhaps I am being cynical.
I don't understand this. Presumably there's nothing stopping Website X sending both: a) my email address; and b) Website X's URL.
Scenario: Joe Bloggs tries to log in to www.SiteThatSellsCars.com using Persona. Joe enters his email address. SiteThatSellsCars sends Joe's email address and "www.SiteThatSellsCars.com" to Joe's ISP. This translates to SiteThatSellsCars saying, "Hey, Joe's ISP, Joe is looking to buy a car, you should send him a metric shit-load of car adverts. He might not like it, but whatever. Thanks for the $20!". Then Joe's ISP replies with, "I sent Joe a token to his browser so he thinks he still has his privacy, but fuck him. Every customer you tell us about, we'll give you $20."
Perhaps I am being cynical.
The site doesn't send anything at all to the identity provider. Your browser sends an authentication requests to the identity provider and relay it the site it wants to log into.
The site then checks the request is really signed by the identity provider and lets the user in.
The identity provider knows two things:
- You asked to log in somewhere - At least one person logged to site X because site X asked for its public key
The site then checks the request is really signed by the identity provider and lets the user in.
The identity provider knows two things:
- You asked to log in somewhere - At least one person logged to site X because site X asked for its public key
> I don't understand this. Presumably there's nothing stopping Website X sending both: a) my email address; and b) Website X's URL.
Yes, but there's nothing stopping them from doing that today. Persona doesn't help you if the site you sign into can't be trusted with the identity you give them. But nothing requires you to give them your normal e-mail address - you could just use throwaway if you find that a concern.
This is not what Persona tries to fix.
Persona is single sign-on where the identity provider does not know which site you sign in to, unlike current solutions where e.g. Google, Twitter or Facebook knows where you sign in whether or not the site you sign into is trustworthy or not.
Yes, but there's nothing stopping them from doing that today. Persona doesn't help you if the site you sign into can't be trusted with the identity you give them. But nothing requires you to give them your normal e-mail address - you could just use throwaway if you find that a concern.
This is not what Persona tries to fix.
Persona is single sign-on where the identity provider does not know which site you sign in to, unlike current solutions where e.g. Google, Twitter or Facebook knows where you sign in whether or not the site you sign into is trustworthy or not.
redalastor is correct. Joe's browser asks Joe's ISP for a token... Joe's ISP never knows what site it's for.
It's more like a client certificate issued by your email provider and installed ad-hoc on demand, rather than a typical Central Authentication System.
It's more like a client certificate issued by your email provider and installed ad-hoc on demand, rather than a typical Central Authentication System.
> So your email provider doesn't know where you're logging in.
This is already the case. For browsers that use the shim, the certificate is stored in localStorage on the login.persona.org domain, and then given to the website you're trying to login to.
This is already the case. For browsers that use the shim, the certificate is stored in localStorage on the login.persona.org domain, and then given to the website you're trying to login to.
Congratulations to the team!
Still annoying I have to type in my email address even though I'm already logged in to Gmail. With OpenID I just click a Google icon, some auth clicks, and I'm done. With this I have to type in my email and do some auth clicks.
Isn't this more of an issue with the current browser you're using? As in, once fully implemented in the browser you won't be prompted to enter it at all. Also, my understanding was that your session information isn't passed along (privacy feature), so it would have no clue you're logged in elsewhere.
You can choose different identifies to log in with. It doesn't know that you want to use Google to authenticate until you choose an identity. You could have used, say, a Yahoo identity, in which case asking Google to vouch for you wouldn't make any sense.
I like idea of Persona, but the idea of requiring emails prevents me from ever implementing it. There are plenty of places where I need an identity system, but don't want to force users to fork over their email address.
From their docs: "The protocol does not require that [identity provider]-backed identities are SMTP-routable, but it does require that identities follow the user@domain format."
The protocol still requires an identity provider to attest to your identity, but the actual identitifier doesn't appear to have to be a real email address. It seems like you could use anything in email address format.
The protocol still requires an identity provider to attest to your identity, but the actual identitifier doesn't appear to have to be a real email address. It seems like you could use anything in email address format.
You almost always want their email address so that you can email them a password reset link in case they forget their password, which is even more important on smaller obscure sites where that's bound to happen.
Yes but with Personna you don't need to send them a password reset link because they have no password in your system :)
If users don't want to provide an email (and then can't reset their password), that should be their prerogative.
As a user who doesn't want to provide my personal email to random services, I have a throwaway email on a different provider with a gibberish username. Given that signing up for 99% of services already requires an email account (or a Facebook/Twitter login, which themselves require a verified email address), Persona is no less onerous.
Realistically, in the modern commercial Web, a user who doesn't want to provide an email probably has negative lifetime value.
Someone still needs to solve the "what verifier do I use problem" in a decentralized way, or we're going to see Persona follow OAuth and be dominated by Google, Facebook, and Twitter accounts.
I think Persona does solve that, or at least, is designed to. Could you say more about what you're thinking?
(Persona always prompts you with a completely free-form email input field and routes you to the appropriate provider based on that.)
(Persona always prompts you with a completely free-form email input field and routes you to the appropriate provider based on that.)
You haven't reached the "verifier" step yet, which is step 4 https://developer.mozilla.org/en-US/docs/Mozilla/Persona/Qui...
Oh, that. It's completely possible to do all of the verification locally, so you don't have to talk to our hosted verifier. We're working on building libraries to make that easier, but we still want to tweak our data formats a little bit before recommending local verification.
In particular, we're watching the IETF's JOSE family of standards pretty closely.
In particular, we're watching the IETF's JOSE family of standards pretty closely.
When Persona gets integrated into the browser, the browser will remember which email address you want to use.
So...that means instead of someone knowing my password to get into xyz website, they can easily just use persona which in a few clicks will let them into my account?
Sure, if they're logged into your Gmail account at the same time. At which point it's already game over. :)
Touche sir.
[deleted]
A company build upon a work-around. I think this is a new level of epic cruft.
Persona would be a lot more privacy-preserving if it generated a unique identifier for each website. A "persona" for each website instead of one persona for the entire interwebz. Since the system is mostly automated it shouldn't be that hard to add one extra layer of indirection.
It might even be possible to shoe-horn it in to the current protocol with just a little bit extra on the browser and identity provider sides, but no change on the website code.
If anyone has actually done that, please post, I'd like to hear about it. Availability of that functionality would sway me to start using Persona and probably anyone else who is worried about spreading their email adddress far and wide across the internet.