In case you're not familiar with them, this blog comes from the Mozilla Identity team, which is creating a unified login product called "Persona." It's basically the features of social login (you don't have to create a new account for every site) without the drawbacks (an advertising-driven company knowing your every login).
I use Persona on my costs-real-money subscription site[1] and I'm very happy with it. Integration was easy, the user experience is pretty good, and it's been stable and reliable. The best thing, of course, was not having to implement my own password-management infrastructure, which saved me a ton of time, as well as insulating me from the hard security problems that come along with such a beast.
If you decide to try Persona, I heartily recommend it. There are a couple of gotchas to be aware of:
1- On iOS, only Safari works due to Persona using a pop-up window for login. People using Chrome on iOS will get a confusing "relay frame not found" error.
2- Signup flow could be better. When users create an account, they get a confirmation email. Clicking the link in that confirmation email redirects them to the Persona site, not back to your site. It's possible this is configurable and I haven't figured it out yet.
3- Persona emails are case-sensitive. There's some rare issues that occur as a result. At one point, it could crash the login, but I believe that's been fixed.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
> returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.
Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers.
The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.
I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).
I'm interested to know how Persona works server-side? AFAIK, it's entirely done in JavaScript. I can't imagine sending the browser ID over Ajax to make a session, it seems far too easy to exploit.
"not having to implement my own password-management infrastructure, ..., as well as insulating me from the hard security problems that come along with such a beast."
But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like:
"Be careful if you don't do this it's going to be easy to forge"
and:
"Guidelines to use Persona securely"
?
So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests?
Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price.
The price is the added insecurity that single sign-on adds.
Hi, I'm on the Persona team at Mozilla. If you'd like to learn more about what and why Mozilla is doing with authentication, I gave a 45-minute talk at PyCon US this past Saturday. You can find the video here: http://pyvideo.org/video/1764
I'm also happy to answer questions in-thread or via email.
I looked at Persona for a project a friend of mine is doing, and I pretty much rejected from the start. Persona seems flawed in that it assumes email as identity.
I'm a developer on a e-commerce site, when we started out we assumed what Persona assumes, that email is a unique and stable identity. We found out the first day of production mode that this assumption is flawed. People changes email address all the time, it's at least as unstable as their home address, most peoples phone number is more stable.
As software developers we assumed that pretty much no one would ever change their email address, or that at least they wouldn't discard their old one. Regular people however do that. They do not care about their email address.
Is this something that the Persona team that given any thought. If so, what did you come up with?
My main question is: where is the support for the assertion made in the article title? As far as I can tell, it's just made, and then the remainder of the article treats it as a premise or a claim to be supported only with vague anecdotes.
The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise. However, I'd be interested to know if you guys have some data that's not shared in the article that suggests it is.
Thank you so much for this system. I sincerely hope that this gets more traction than OpenID. This is the most essential feature the entire web has never had.
I am very happy with the way persona works, both as an end user, and how easy it is to integrate into applications. I am hoping it gets some good marketing done or whatever is needed to make more sites start using it.
How, today, can I integrate Persona login into my site without referencing any third-party Javascript? Does any solution exist for sites that by policy only load Javascript from the same origin?
I think adding social auth was one of the biggest mistakes we made for the beta of Jetstrap. Users constantly forget which service they use. We added email/pass authentication, but now older users think they had a password when they didn't, and with django social auth you can't reset the password for a social account.
It was one big mess not at all worth it. I'd like to try Persona and see how that compares, but I think normal email/pass is better than plain social auth.
Why don't put the way the user was logged in by last time in cookie and just highlight it next time for him? Or even more explicit - add the "you have logged in this way last time" under the appropriate button?
Tangentially related, for similar reasons Paypal remains my payment processor. Lots of people have Paypal accounts and find it much more convenient to use it rather than haul out their credit card and hand key all of their address and payment info. Every time I think about switching I review how many people use PayPal Express checkout rather than credit card DirectPay (both of which I offer), and I think about how many people simply wouldn't pay if the minimal friction of the PayPal Express button wasn't there on my checkout form.
I'm a technical person and I don't like social login and I don't like creating individual account for every site. What I would like is a decentralized single-login protocol like the article is talking about.
One example of this is pud's launching of fandalism.com. When he announced the site on HN[1] some HNers complained about Facebook only login. But he was still able to get 400,000+ signups within 3 month[2].
Agreed -- this article shows not one data point to back-up their argument, but if you do look users actually opt for social login due to ease of access and use. Hell it's what makes paypal so easy and popular -- you put your data in one trusted service, and it works with minimal pain points across any site that requires payments.
Technical person here, and I will use Facebook or Twitter login 10 times out of 10. I do not want to create a new account for your service unless you absolutely force me to.
The worst offenders are those that lead you into a social login, then post every page you view on your facebook wall. I've learned some fascinating things about my friends' reading tastes this way, but I'm sure they weren't happy about it.
> We also noticed that users dislike the NASCAR-style
> plastering of branded login buttons.
This reminds me quite vividly of Stack Overflow's login page. I can never remember if I signed up direct, with OpenID, or Google, or whatever else is there.
I've been starting to dig Mozilla and Firefox again lately (the last week of developer tools news cemented that), so I'd love to see their idea take off and gain full adoption.
If you want to run your own Persona Identity Provider (so you can login directly with your own email account and control the authentication from your own domain/site/server instead of having to remember yet another password for the fallback Identity Provider provided by persona.org), here's a tiny little piece of Python code that implements that:
We just implemented Persona across all our sites and are very happy with it.
We did it in a way that's completely independent of our normal email/password login as well, but integrates seamlessly. That made me really happy, as the reliability of our system hasn't decreased a bit.
The Persona team was also really helpful, though it turned out we didn't need much help implementing it.
While I'd like to agree, I'd also like to see something beyond anecdotal evidence on this. It'd give me a great excuse next time someone wants a Facebook login and a Twitter login and a Pinterest login [sic] on the same site.
I love the concept of Persona and hopes it catches on. One question I can't seem to find the answer to, though.
Users are allowed to have multiple emails tied to one Persona account. If they login to my site with one email I will see that email address and can bind their account data to it. If they sign in with their other email address, will I be able to identify them as the same person?
IMO, the whole point of tying multiple email addresses to one Persona account is to prevent websites from figuring out that both addresses are tied to the same person.
This is very important when you're trying to build an identity system that you want every website to adopt. Users want to split up their lives into distinct identities (e.g. one for professional settings, one for friends, one for family, one for a secret hobby...). A viable identity system should allow people to manage such identities with ease and switch between them at a moment's notice, without letting anybody else find out that @lubujackson on HN is the same person as @blowjobs on a porn site or a member of an unpopular political movement. Even if somebody carefully compared HN databases with the porn site databases.
Having said that, people do change their email addresses a lot more frequently than web devs assume. When this happens, they need to update their profiles in every single website where they used the old address. It would be better if my identity were linked to some sort of key that doesn't change, rather than an email address. Likewise, if there is a proliferation of Persona identity providers, some of them will inevitably go out of business after a while. It should be very easy to migrate one Persona account to another.
Alternatively, what happens when someone graduates, changes ISPs, a domain name expires, or they get a new job, and someone later takes control of their email address? As concrete example, if you attend UCSB, you can easily get them to give you saurik@ right now on various of their servers I used to use for vaguely-official UCSB uses.
The problem with Persona is that they simply don't seem to understand that for real people, email addresses are just a convenience, not a canonical way to maintain identity. They also fail to see that even people like myself, who have carefully tended an email address for well over a decade, are not immune to this problem.
Users always complain about social logins. On iOS apps that I've built, I've found Facebook login to have something like a 50% conversion. I'd be curious to hear whether or not the conversion is improved by using Mozilla's Persona product. Is the only sales pitch here that the login is managed by a non-profit organization?
Not sure how that makes this a better product overall. Can anybody clarify?
Major difference: Social auth outsources your user table. Persona outsources your password column. You still have your own users, and you still have a portable identifier for them.
What's more, Persona is built as a fully-decentralized architecture with a temporary centralized fallback. That means that one button can support all users, via their email provider's native authentication mechanisms (in the future) or via Mozilla's centralized fallback (for now).
This lets you use Persona to authenticate to non-web services such as IMAP, SMTP, SSH, NFS, CIFS, etc. We (or should I say, I) are pretty excited about it!
Just a random data point, but one of my apps with a definite non-technical demographic gets 97% of logins via facebook, 2.5% via twitter, and 0.5% via email/password registration. I haven't tested it obviously, but I don't think removing Facebook login would do much for conversions.
There's an "evil" incentive to have social logins such as Twitter + FB. It gives you a free access token, which can be extremely useful, especially if you're building a social media analytics service, or some sort of tool that requires making API calls.
[+] [-] jdlshore|13 years ago|reply
I use Persona on my costs-real-money subscription site[1] and I'm very happy with it. Integration was easy, the user experience is pretty good, and it's been stable and reliable. The best thing, of course, was not having to implement my own password-management infrastructure, which saved me a ton of time, as well as insulating me from the hard security problems that come along with such a beast.
If you decide to try Persona, I heartily recommend it. There are a couple of gotchas to be aware of:
1- On iOS, only Safari works due to Persona using a pop-up window for login. People using Chrome on iOS will get a confusing "relay frame not found" error.
2- Signup flow could be better. When users create an account, they get a confirmation email. Clicking the link in that confirmation email redirects them to the Persona site, not back to your site. It's possible this is configurable and I haven't figured it out yet.
3- Persona emails are case-sensitive. There's some rare issues that occur as a result. At one point, it could crash the login, but I believe that's been fixed.
Don't let these flaws stop you, though--Persona is very well done and constantly getting better. I've had hundreds of people sign up for paid accounts and only two have had trouble to the point of asking for help. (And nobody's cancelled their subscription because of login problems. :-) )
[1] Let's Code Test-Driven JavaScript, letscodejavascript.com
[+] [-] judofyr|13 years ago|reply
https://developer.mozilla.org/en-US/docs/DOM/navigator.id.re...
> returnTo: Absolute path to send new users to after they've completed email verification for the first time. The path must begin with '/'. This parameter only affects users who are certified by Mozilla's fallback Identity Provider.
[+] [-] callahad|13 years ago|reply
Upgrade to the Observer API (`.watch` and `.request`) and your users will automatically get a super smooth post-verification experience, just like you described.
[+] [-] adrianhoward|13 years ago|reply
Just as a point of info "only two have had trouble to the point of asking for help" is a really bad way of judging whether something is working well or not for your customers.
The vast majority of people do not complain if they hit problems. They just silently go away. From my experiences of optimising this sort of stuff I'd pretty much guarantee that you have at least 10x times than number failing and walking. Possibly much higher.
[+] [-] fmarier|13 years ago|reply
Of course, if you find anything we've missed, please file a bug :)
[+] [-] basicallydan|13 years ago|reply
I like it a lot, but at the end of the day I'm still relying on a single company to hold the keys to many accounts of mine on the web, which is still a bit jarring (not that it's going to stop me).
[+] [-] tracker1|13 years ago|reply
[+] [-] ancarda|13 years ago|reply
Perhaps I'm missing something.
[+] [-] martinced|13 years ago|reply
But you do realize it does definitely create another, much more serious, security problems right? What happens when the single sign-on server gets compromised? What happens when tokens aren't as secure as they should (like the recent OAuth SNAFUs, with an 's')? What happens when you don't pay attention to all the fineprints in the Persona docs stating things like:
"Be careful if you don't do this it's going to be easy to forge"
and:
"Guidelines to use Persona securely"
?
So it can be used not securely? Like OAuth? Do you think I find it re-assuring that I have to take steps so that things are not easy to forge? What when the latest JavaScript / browser exploits manages to forge requests?
Don't get me wrong: this seems very convenient. But you're trading time for something here. It saves you time by now having to roll your own security correctly (a DB into which you put emails and bcrypt encrypted passwords) but it comes at a price.
The price is the added insecurity that single sign-on adds.
[+] [-] callahad|13 years ago|reply
I'm also happy to answer questions in-thread or via email.
[+] [-] mrweasel|13 years ago|reply
I'm a developer on a e-commerce site, when we started out we assumed what Persona assumes, that email is a unique and stable identity. We found out the first day of production mode that this assumption is flawed. People changes email address all the time, it's at least as unstable as their home address, most peoples phone number is more stable.
As software developers we assumed that pretty much no one would ever change their email address, or that at least they wouldn't discard their old one. Regular people however do that. They do not care about their email address.
Is this something that the Persona team that given any thought. If so, what did you come up with?
[+] [-] jamesaguilar|13 years ago|reply
The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise. However, I'd be interested to know if you guys have some data that's not shared in the article that suggests it is.
[+] [-] hackernewbie|13 years ago|reply
[+] [-] mcovey|13 years ago|reply
[+] [-] JoshTriplett|13 years ago|reply
[+] [-] tlear|13 years ago|reply
[+] [-] yesimahuman|13 years ago|reply
It was one big mess not at all worth it. I'd like to try Persona and see how that compares, but I think normal email/pass is better than plain social auth.
[+] [-] snaky|13 years ago|reply
Technically that's easy to implement.
[+] [-] nicksergeant|13 years ago|reply
Real people (non-tech / nerd) prefer not having to create individual accounts for all sorts of different services.
I've seen proof of this time and time again.
[+] [-] badida|13 years ago|reply
[+] [-] patja|13 years ago|reply
Lowest friction wins.
[+] [-] TheCoelacanth|13 years ago|reply
[+] [-] mun2mun|13 years ago|reply
[1]https://news.ycombinator.com/item?id=3559081
[2]https://news.ycombinator.com/item?id=3850739
[+] [-] ed209|13 years ago|reply
https://blog.mailchimp.com/social-login-buttons-arent-worth-...
[+] [-] ozten|13 years ago|reply
Here is a presentation on one of their recent studies https://air.mozilla.org/online-identity/
[+] [-] arindone|13 years ago|reply
[+] [-] notJim|13 years ago|reply
[+] [-] dangoldin|13 years ago|reply
[+] [-] janus|13 years ago|reply
[+] [-] davidroberts|13 years ago|reply
[+] [-] anoncow|13 years ago|reply
[+] [-] FuzzyDunlop|13 years ago|reply
This reminds me quite vividly of Stack Overflow's login page. I can never remember if I signed up direct, with OpenID, or Google, or whatever else is there.
I've been starting to dig Mozilla and Firefox again lately (the last week of developer tools news cemented that), so I'd love to see their idea take off and gain full adoption.
[+] [-] dochtman|13 years ago|reply
https://bitbucket.org/djc/persona-totp
In particular, the authentication method I use is Google Authenticator-compatible TOTP (RFC 6238).
[+] [-] guan|13 years ago|reply
[+] [-] hp50g|13 years ago|reply
And that's the way I like it :)
[+] [-] breck|13 years ago|reply
We did it in a way that's completely independent of our normal email/password login as well, but integrates seamlessly. That made me really happy, as the reliability of our system hasn't decreased a bit.
The Persona team was also really helpful, though it turned out we didn't need much help implementing it.
[+] [-] jpdevereaux|13 years ago|reply
[+] [-] lubujackson|13 years ago|reply
Users are allowed to have multiple emails tied to one Persona account. If they login to my site with one email I will see that email address and can bind their account data to it. If they sign in with their other email address, will I be able to identify them as the same person?
[+] [-] kijin|13 years ago|reply
This is very important when you're trying to build an identity system that you want every website to adopt. Users want to split up their lives into distinct identities (e.g. one for professional settings, one for friends, one for family, one for a secret hobby...). A viable identity system should allow people to manage such identities with ease and switch between them at a moment's notice, without letting anybody else find out that @lubujackson on HN is the same person as @blowjobs on a porn site or a member of an unpopular political movement. Even if somebody carefully compared HN databases with the porn site databases.
Having said that, people do change their email addresses a lot more frequently than web devs assume. When this happens, they need to update their profiles in every single website where they used the old address. It would be better if my identity were linked to some sort of key that doesn't change, rather than an email address. Likewise, if there is a proliferation of Persona identity providers, some of them will inevitably go out of business after a while. It should be very easy to migrate one Persona account to another.
[+] [-] saurik|13 years ago|reply
The problem with Persona is that they simply don't seem to understand that for real people, email addresses are just a convenience, not a canonical way to maintain identity. They also fail to see that even people like myself, who have carefully tended an email address for well over a decade, are not immune to this problem.
I have previously commented on this here:
https://news.ycombinator.com/item?id=4233391
[+] [-] goronbjorn|13 years ago|reply
[+] [-] mikec3k|13 years ago|reply
[+] [-] shmerl|13 years ago|reply
[+] [-] biznickman|13 years ago|reply
Not sure how that makes this a better product overall. Can anybody clarify?
[+] [-] callahad|13 years ago|reply
What's more, Persona is built as a fully-decentralized architecture with a temporary centralized fallback. That means that one button can support all users, via their email provider's native authentication mechanisms (in the future) or via Mozilla's centralized fallback (for now).
[+] [-] bozho|13 years ago|reply
[+] [-] lukeh|13 years ago|reply
https://github.com/PADL/gss_browserid
Internet Draft here:
http://tools.ietf.org/html/draft-howard-gss-browserid-00
This lets you use Persona to authenticate to non-web services such as IMAP, SMTP, SSH, NFS, CIFS, etc. We (or should I say, I) are pretty excited about it!
[+] [-] StavrosK|13 years ago|reply
[+] [-] recurser|13 years ago|reply
[+] [-] AznHisoka|13 years ago|reply