Identity at Mozilla

Home of the Mozilla Identity team

  1. Users don’t like social login

    Mar 20, 2013 — by benadida

    We were very happy to see the revamped “Log In with Google Plus” product from our friends across town: big improvements in user experience, great mobile integration, and clearer privacy controls. Still, we think Identity on the Web can be better: easier for developers, true choice and control for users.

    In particular, we think login should be personal and minimal first, social later. We’re not the only ones who think so, as TechCrunch reported:

    Some people don’t have Facebook or Twitter accounts. Others have deleted them to live a more “real” existence. Then there are those with social accounts, but who don’t want to give their most private data to just any developer. Their biographical info, location, interests, and the ability to post things to their friends are not things they want to give away without some vetting.

    […]

    Rockmelt co-founder and CEO Vishria tells me his company learned a big lesson […]: “because of privacy implications, people want to try an app with email and then add social later if they like it.” I call this “try before you pry,” and Vishria explains “there’s a certain level of trust that builds over time.”

    That’s why a login with Mozilla Persona delivers only the user’s preferred identity to the site.

    Users, not Sites, should choose their Identity Provider

    We also noticed that users dislike the NASCAR-style plastering of branded login buttons. If the user recognizes none, she’s forced to use a new identity provider. If the user recognizes one, the others are distracting. If the user recognizes more than one, she’ll likely forget which one she used the first time, click another one the second time, fail to retrieve her data at the web site in question, groan, and start again.

    We can do better. The user should see only options relevant to her!

    With Persona, the user chooses any email address she wishes. Only the user’s own email addresses are ever displayed. When returning to a site, the last-used address is even pre-selected.

    Privacy, even from the Identity Provider

    When logging in with Google Plus, users choose how much to reveal to their friends. However, users still cannot choose how much to reveal to Google: Google learns every user’s login at every site. It’s as if a hotel receptionist called up the Department of Motor Vehicles to inform them of your checkin because you provided a driver’s license as identification. A bit jarring, in our opinion.

    We built the Persona protocol to reduce data sharing to the minimum needed for the user to easily log in: the browser mediates the login without leaking data to the identity provider. In the end, Persona is the easy login solution that respects users.

    Want to add Persona login to your site? Read our quickstart. Or, if you’re more adventurous, you can turn your domain a Persona Identity Provider and directly certify your domain’s users.

    As always, we welcome your questions and comments on our mailing list, or via the #MozillaPersona hash-tag on Twitter.

  2. Persona plays well with Firefox’s third-party cookie policy

    Feb 25, 2013 — by benadida

    Firefox is experimenting with a new third-party cookie policy. Alex Fowler, Mozilla’s Lead on Privacy and Public Policy, puts it this way:

    On Friday, Mozilla released a Firefox patch into its “Nightly” channel that changes how cookies from third party companies function. Users of this build of Firefox must directly interact with a site or company for a cookie to be installed on their machine.

    Firefox is exploring this change because we believe it’s good for the Web. We did not test other Mozilla web sites first, because we do not play favorites. For example we didn’t know for sure, when the change was applied to Firefox Nightly, whether Persona would continue to function as expected. We believe this Firefox cookie policy change is good for users, and all of our products should live by the rule we’re proposing.

    Of course, since Persona is built to respect user privacy, we don’t set a cookie unless you directly interact with Persona. So it is without much surprise that our first tests indicate that Persona works just fine with Firefox’s new third-party cookie policy.

    Persona will always strive to provide the easiest login solution for users and developers, all the while protecting user privacy. It’s good to see that our approach meets the criteria set by Mozilla’s very best privacy minds.

  3. A Node.js Holiday Season

    Dec 20, 2012 — by callahad

    JavaScript is at the very heart of Persona: even its server-side components are written in JavaScript, thanks to Node.js.

    The Persona team is currently writing a series of fortnightly blog posts on our experience with Node.js, and the first four articles are already available:

    1. Tracking Down Memory Leaks in Node.js
    2. Fully Loaded Node
    3. Using Secure Client-Side Sessions to Build Simple and Scalable Node.js Applications
    4. Fantastic Front-End Performance Part 1 – Concatenate, Compress & Cache

    This is just the beginning of the Node.js Holiday Season blog series — we have eight more articles planned.

  4. Announcing the First Beta Release of Persona

    Sep 27, 2012 — by callahad

    For the past year Mozilla has been working on an experimental login system that completely eliminates passwords on websites while being safe, secure, and easy to use. Today we’re casting off the “experimental” label and announcing the first “beta” release of Persona.

    Persona is ready to use for authentication: it works in all major smartphone, tablet, and desktop browsers, the user experience has been thoroughly reviewed and polished, we’re committed to the core APIs, and its infrastructure is highly available and stable.

    What’s it like to integrate Persona? Check out this video from The Times Crossword:

    “[Persona] was definitely easier than OpenID or OAuth because it can almost all be done on the client side in JavaScript.” — David Somers, News International

    We haven’t just refined Persona, we’ve also significantly improved it since we first introduced it. Over the past few months we:

    These changes have been well received and we’re seeing Persona gain traction outside of Mozilla. If you are a developer, now is the time to try Persona out. Persona is an open source project and we gladly welcome input and collaboration from the broader community via our mailing list or our IRC channel (#identity on irc.mozilla.org).

    This is the first of many beta releases, and we have some fantastic things planned for the future.

    So, what are you waiting for? Persona coexists well with existing login systems and only takes a single afternoon to integrate. What’s more, because Persona logins are based on email addresses, sites still maintain a direct relationship with their users. Check out the documentation and add Persona to your site today!

  5. Committing to a Stable API for Persona

    Sep 17, 2012 — by callahad

    Later this month, we will be announcing the first “beta” release of Persona. Part of that announcement will include committing to long-term support for our APIs, so that developers can more confidently rely on Persona in their sites and applications. This post will serve to outline the deprecation strategy that Persona will adopt for its beta releases.

    How is deprecation handled?

    Before deprecating or making backwards incompatible changes to stable APIs, the Persona team will announce the change on the Persona-notices mailing list. The team will also add deprecation warnings to the relevant code and documentation.

    The notice will be posted at least six months prior to the change taking effect. After posting the notice, the team will listen for feedback and monitor the ongoing use of the API. Depending on these metrics, the deadline may be extended once by an additional six months. Any extension will be communicated via the Persona-notices mailing list.

    Can changes happen more quickly?

    Yes. If a security vulnerability necessitates a backwards incompatible change to a stable API, then that change may be expedited and a message will be sent to Persona-notices.

    Backwards compatible and cosmetic changes may also be expedited.

    What APIs are covered?

    Beta 1 will only stabilize the subset of Persona APIs that are necessary for authenticating users. Subsequent beta releases will eventually extend this commitment to the remaining APIs, Persona’s data formats, and the cross-browser shim.

    Specifically, the first beta release will only commit to:

    1. id.watch() and its loggedInUser, onlogin, and onlogout options.
    2. id.logout() without any parameters.
    3. id.request() with its oncancel, privacyPolicy, termsOfService, returnTo, siteName, and siteLogo options.
    4. id.get() with its privacyPolicy, termsOfService, siteName, and siteLogo options.

    What about APIs that are already deprecated?

    APIs that are undocumented or already marked as deprecated may be removed more rapidly. This includes:

    1. id.getVerifiedEmail().
    2. The loggedInEmail and onready options for id.watch().
    3. The privacyURL and tosURL options for id.request().
    4. id.logout() when passed a callback as its first parameter.
    5. The requiredEmail, silent, privacyURL, and tosURL options for id.get().

    If you are using any of these undocumented or deprecated APIs, please update your code. As per usual, backwards incompatible deprecations will be announced on the Persona-notices mailing list in advance.

    What resources are available to help with upgrades?

    While the APIs are fully documented on MDN, the Persona team is committed to supporting developers that rely on Persona.

    If you have questions regarding upgrading your code in response to a deprecation notice, please contact us via the dev-identity mailing list or stop by our IRC channel: #identity on irc.mozilla.org.

    Lastly, if your site depends on Persona, or you are supporting people who do, please subscribe to the Persona-notices mailing list.

  6. Application and Platform Integration of Persona

    Sep 6, 2012 — by callahad

    We are happy to see Persona gaining traction in the developer community, with dozens of sites and services integrating Persona to simplify and speed up the login process while simultaneously eliminating site-specific passwords for users. Some recent Persona adopters include:

    • LoginRadius, an embeddable authentication widget, permits quick integration of Persona and other authentication systems within many platforms, languages, and frameworks. We’re excited to see Persona amongst their login offerings, giving their partners a new, simple way to authenticate users.
    • Mahara, an open source e-portfolio system used by educational institutions around the world, has implemented Persona as an authentication system to allow users to log in to their portfolios and collaborate with others in groups on projects. Persona is included by default as of version 1.5 which was released in April 2012.
    • Koha, a popular integrated library system, is planning to include Persona as one of the default login mechanisms as of version 3.12. With this integration, both librarians and visitors will be able to access library resources using Persona.
    • The Eclipse Foundation is building Persona into the 1.0 release of Orion, an IDE that runs as a web application. By logging in with Persona, users will be able to organize projects and collaboratively develop software from the comfort of their browser.

    For Ruby developers, OmniAuth offers a Persona module courtesy of Intridea. It’s available on GitHub at https://github.com/intridea/omniauth-browserid.

    Similarly, Node.js developers can leverage Persona thanks to a Passport module from Jared Hanson of Helixent Technologies. The module is available on GitHub at https://github.com/jaredhanson/passport-browserid.

    Lastly, a groundswell of community support has helped produce many more libraries and plugins, which you can find on our GitHub Wiki. If you’re curious about Mozilla’s own use of Persona, we’ll blog about that shortly. Until then, check out the django-browserid library — it already handles the authentication on sites like MDN.

    If you’re considering adding Persona to your application or website, you can find documentation on MDN. Don’t forget to keep in touch via our mailing list or by tweeting with the #mozPersona hash-tag.

  7. A new API for Persona

    Aug 1, 2012 — by callahad

    After gathering feedback from our users and our User Experience team, we’re excited to announce that we’ve implemented several important new features in Persona. These features include showing your website’s name and logo in the login dialog, a streamlined experience for first-time Persona users, and greater security thanks to global logout from any device.

    In order to make these features a reality, we had to change our JavaScript API. Working with the community on our public mailing list, we’ve come up with a brand new way to use Persona on your site. We call it the “Observer API,” and we believe it’s the future of Persona.

    We’ll be announcing a “Beta” release of Persona before the end of September, at which point the Observer API will become the recommended means of integrating Persona into your website. We do not plan to deprecate the previous API (navigator.id.get()) at this time. Nevertheless, we’re committed to working with our community to get everyone up and running with—and reaping the benefits of—the Observer API.

    How Does It Work?

    The Observer API consists of just three functions: At the time your page loads, you watch() for login/logout notifications from Persona. Whenever a user clicks the login button on your site, you request() a verified email from your user, which opens the Persona dialog. Finally, when a user logs out of your site, you tell Persona by calling logout().

    This new structure is a great foundation for future refinements and improvements to the Persona experience: we couldn’t have delivered all of the aforementioned features without it! You can find out more by reading our documentation on MDN.

    Where Can I Get Help Upgrading My Site?

    As always, start with the docs. If you’re still stuck, drop us a line on our mailing list or stop by our IRC channel: #identity on irc.mozilla.org.

    Let us know know what you think by tweeting with the hashtag #mozPersona!

  8. Improvements to the First Time Sign-up Flow

    Jul 24, 2012 — by stomlinsonmoz

    The Persona team has always been interested in optimizing the user experience for developers and users alike. Some time ago we identified one area where we could improve: the first-time sign-up flow. We’ve been hard at work making this process as smooth as possible, read on to find out how!

    The Challenge

    The Persona sign-up flow is designed to leverage the user’s existing accounts and passwords if their email provider supports our protocol. For unsupported providers, we verify identities by sending a confirmation email. This flow potentially causes the user to leave the destination site to check their email, an action that can make it difficult to navigate back.

    The Goal - Increase Completion Rates

    The goal is simple - increase the completion rate. A completed user is one who has verified their email address, is viewing the destination site, and is authenticated to that site.

    We previously experimented with redirecting users back to the destination site, but until recently there was no way to sign the user in. The new Observer API makes this possible - everything is now lined up to complete the flow.

    The Observer API makes user verification seamless. Once a user completes* the Persona verification they are redirected to the destination site and automatically signed in.  Information about the Observer API can be found on MDN.

    Simplifying the Persona Sign Up Flow from Shane Tomlinson on Vimeo.

    Redirect Verified Users to Alternate Endpoints

    The new returnTo option to navigator.id.request allows a site to send users to an alternate endpoint after address verification.

    returnTo is an absolute path, meaning it *must* start with “/”. Neither relative paths nor alternate domains can be specified.

    navigator.id.request({ 
    ...
    returnTo: '/pathToReturnTo.html',
    ...
    });


    Support for returnTo and the other post-verification updates are live in production now. Check out the docs, give it a try, and let us know what you think. You can contact us through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”.

    ===

    * Only users who verify their email address using the same browser they used to start the signup will be redirected and signed in.

  9. New Feature: Adding Your Website’s Name and Logo to the Persona Login

    Jul 13, 2012 — by warnermoz

    One of the features we’ve added to Persona’s new Observer API is the ability for websites that use Persona (“Relying Parties”) to add their name and logo to the login screen. To do this, just add a siteName and/or siteLogo property to your navigator.id.request() call.

    The default login screen only shows the website’s domain name, as illustrated below:

    By adding siteName, you can put additional text in the right-hand RP area:

    navigator.id.request({ siteName: "Tahoe LAFS" }); 

    Or you can use siteLogo to add an image:

    navigator.id.request({ siteLogo: "/logo.png" }); 

    You can also use both, in which case the name will appear below the logo.

    In all cases, the website’s domain name is displayed below the siteName and siteLogo, so the user knows for sure which site is going to receive their email address.

    Restrictions (Use SSL!)

    There are a few restrictions to be aware of:

    • siteName must be plain text: no markup is allowed. Unicode and whitespace is ok, but keep it short or the dialog box may clip.
    • siteLogo must be a site-relative URL with an absolute path (i.e. it must start with a ‘/’ slash). In the future, we’ll probably relax this requirement and enable absolute URLs and even data: URIs. Images larger than 100*100 pixels will be scaled down to fit.
    • siteLogo requires SSL. The login dialog is served over HTTPS, so the logo image must also be served over HTTPS (to avoid mixed-content warnings), which means your login page (the one that calls navigator.id.request()) must be served over HTTPS too. If you try to use siteLogo from an HTTP-served page, your users will actually get an “improper usage of API” error from the Persona code. But, as a respectable RP who cares about your user’s privacy, your whole site is already being served with HTTPS, right? Right?

    Support for siteName and siteLogo rolled to production yesterday, so take a look at the docs and give it a spin. And let us know how it works for you, through our mailing list, the #identity IRC channel on irc.mozilla.org, or on Twitter with “#browserid”.

  10. Mozilla Persona rebranding is live

    Jul 11, 2012 — by benadida

    You may have noticed that, as of tonight, https://browserid.org redirects to https://login.persona.org. The main site and login dialog have been re-branded, as we announced a few months ago, to Mozilla Persona. This is one big step in preparation for our Beta Launch in mid-August. If you used BrowserID before today, you will automatically inherit the new look-and-feel, and everything will continue to work for your users without interruption.

    In the process, we added some great new features, which we’ll tell you about on this blog over the next few days. As always, we welcome your feedback via Twitter using #mozpersona or #browserid, and on our mailing list.