Identity Articles

Sort by:


  1. Account Manager coming to Firefox

    Update: The Account Manager is no longer maintained. Building on this experiment, we have conceived BrowserID. Please consider using it instead.

    Last month Mozilla Labs announced a new concept series on online identity. As part of this exploration, we developed the Account Manager.

    The Account Manager makes it incredibly easy for users to create new accounts with optional randomly generated passwords, and log into and out of them with just a click. As a web developer, adding support for this feature could take as little as fifteen minutes of hacking (in fact, we’ll mention the first 5 people to add support – read below to learn more.).

    We want to make signing into websites easier for all Firefox users, and are looking to ship this feature as soon as possible in Firefox. As part of that process we’re looking for feedback to refine the specification. Now is a really good time to get involved in defining the spec.

    There are three things that you can do right now:

    This feature is currently available as an experimental add-on, available on the Account Manager homepage.

    Here’s a video where you can get a basic idea of how Account Manager works today:

    How Does It Work?

    The Account Manager specification proposes two small changes to Web sites:

    1. The browser needs to know how to register, sign in, and sign out of your site. You will need a static JSON document, automatically discovered by the browser, which describes what methods the site supports and how they should be executed. For example, a web site might describe their support of “connect” (sign in) like this:

        "methods": {
          "username-password-form": {
            "connect": {
              "method": "POST",
              "path": "/accounts/LoginAuth",
              "params": {
                "username": "Email",
                "password": "Passwd"

      This example tells the browser that the site supports signing in with a form POST to /accounts/LoginAuth, and what parameter names to use for the username and password (Email and Passwd respectively).

    2. The browser needs a way to check which user (if any) is currently signed in. To do this, you need to set an HTTP header in the same code where you would set a cookie with a session ID. If you can’t set an HTTP header, you can also supply a URL the browser will ping.

      The header would look like this:

      X-Account-Management-Status: active; name="Joe User"

      That would tell the browser that “Joe User” is now signed in, so it can provide the appropriate UI (to switch users or sign out).

      How do I try it?

      • Install the demo add-on.
      • Place a host-meta document to your website at /.well-known/host-meta (it must be at this location). This tells the browser where to find the JSON file we described above. For examples, check the spec or Yahoo!’s host-meta.
      • Add the JSON file itself to your site. We call this the Account Manager Control Document, or AMCD for short. The AMCD should contain your form end-points for sign-in and sign-out. Note that you don’t need to change the end-points, just describe them. Check the spec for a complete example.
      • Change your site to set the correct headers when users sign in or out.
      • Make sure you have a password saved in the password manager; you may need to sign in manually once to do that if you haven’t already (this requirement will go away in the future).
      • When we add sign-up support in Account Manager, you will likely need to make minor changes to your registration code.

      Update, 5:45PM PST: Just realized while debugging an intrepid first adopter’s site that there is one more requirement:

      • You can send the status header with every request, or if you don’t want to do that, then you need to provide a sessionstatus method (see the spec) that the browser can ping to find out the user’s signed-in status.

      That’s it, folks! Be one of the first to try implementing the specification on your website, and let us know, and let us know how long it took you to add support for it. We’ll put the first five people to implement this on the @mozhacks twitter account with a link to your site!

      Next time we will go into more depth on how discovery works, our plans to support other auth schemes (like HTTP Auth, OpenID, etc), as well as other neat features we plan to add. Stay tuned! And don’t forget to tell us what you think.

      Web Developer FAQ

      • Do I need to redo all of my authentication code?

        No. Account Manager is designed to require minimal server-side changes. You do have a couple of options, but the minimal setup is just a flat file and a couple of extra headers you need to send out.

      • Do I need to redo all of my account creation code?

        Registration will require some small changes to your registration flow, but we have put extra thought into making it as simple as possible for both Web sites and users alike. Check out our discussion group and specification for the details, and let us know what you think!

      • How is this going to help my users?

        Account Manager is great for users. Here are a few highlights:

        • Simple, convenient, user control

          The browser has a couple of advantages when it comes to making this kind of UI. First, it can dedicate a spot in the browser chrome that will look and behave the same for every site, making it a convenient and automatic go-to place for users to check or change their sign-in status.

          The browser also has deep knowledge about the user. For example, the browser could implement fast user switching with just a click. Or think about picking a username: the browser can look at usernames for other accounts and make some pretty good guesses about what usernames are preferred.

        • Secure

          Many security researchers will tell you: one of the biggest security problems on the Web today is that usernames and passwords are often short and easily guessed. Account Manager makes it so that users don’t need to remember their passwords, and in fact can automatically generate strong passwords when signing up.

          Moreover, Account Manager begins the process of abstracting the plumbing of account management from the UI, making it possible in the future to support cryptographically strong protocols without any major UI changes.

        • Works on top of current and emerging solutions

          Lastly, Account Manager is not a new ID for the Web. Rather, it is designed to work on top of current and emerging solutions like OpenID or others, to bring them all under the same user experience. Users shouldn’t have to care what the underlying technology is.

      • How is this going to help me get more users?

        The easier it is to sign up and sign into your site, the more users you will get. It’s pretty much that simple.

        Note that Account Manager doesn’t force your users to make a choice: you can keep all of your current content-based flows intact, so there is really no downside to adding Account Manager support to your site.

      • Do I need to have special content for Firefox only?

        No! First of all, you don’t need to do *any* changes to your current content at all. Account Manager works behind the scenes using a sitemap and headers to communicate with your site and present the right UI to the user.

        On the other hand, we hope that Account Manager will not be a Firefox-only technology. We’re working towards defining the protocol as a formal specification that other Web browsers can implement.

  2. Introducing BrowserID – easier and safer authentication on the web

    Security on the web is more important than ever. Almost weekly reports of exploits of information and leaks into the public make it hard for a lot of people to trust the internet.

    One of the main annoyances is that every service expect us to have a login and password. As we use lots of services this means we have to remember a lot of login names and passwords. People deal with this in various ways. The most dangerous is using a simple password across different services. Another way is to not bother remembering your secure password and instead re-set it every time you come back to the site you want to access by going through a verification by email. This could also be a very dangerous approach – especially when the site you log in to sends your password as plain text rather than forcing you to create a new one. In any case, you spend a lot of time running in circles between you, the site you want to access and your email client.

    There were a few ideas in the past how to work around the issue of logins and passwords. OpenID was the most ambitious one, but failed to get traction in the main market as having a URL as your identifier seemed alien to a lot of end users.

    Taking the lessons and learnings from the mistakes of OpenID and other approaches Mozilla Labs is now proposing BrowserID which moves from domains and sites to emails as your main identifier. In essence, we promote the “password recovery” mechanism of the traditional login approach to your main point of access.

    What is BrowserID?

    BrowserID aims to offer you one single log-in to web sites and services, connected through your e-mail address (with the option to add more than one e-mail to the same account). The core idea is that you will always remember your e-mail address instead of a made-up user name or URL.

    The main pillars of BrowserID are:

    • Ease of use
    • Security
    • Cross-browser implementation
    • Decentralized, web-wide validation
    • Improved experience in future browsers
    • Respecting the privacy of the user

    Using one e-mail address and a master password, you only need to activate and verify your account once. As BrowserID is implemented with the Verified E-mail Protocol it has built-in security. Furthermore it offers a verification service to check against.

    It works cross-browser, both on desktop and mobile, and it’s decentralized so that anyone can chose to implement it on their web site. Respecting user privacy is a very important factor for Mozilla. Therefore no information is shared with any service about your BrowserID usage (check the BrowserID Privacy statement for more information).

    What makes it even more enticing in the long run is that BrowserID could be implemented natively in the web browser, for example through the URL bar, where the user could choose to log in/out. This will make it an even more secure measure against phishing and other attacks, and give end users the most consistent and reliable experience.

    Try it out

    If you want to try an example, you can go to the TextChannels web site, create a BrowserID account and sign in with it.

    After you have created a BrowserID account at TextChannels, you can go to our other test web site and see how easy the experience is when you have a BrowserID account.

    Here is a video explaining the procedure:

    How to implement BrowserID

    If you want to use BrowserID in a web site, you have to go through three main steps:

    1. Enable BrowserID
    2. Identify the user
    3. Verify the User’s Identity

    Enabling BrowserID is quite easy: simply include the BrowserID JavaScript in your web page. Then add an event handler to a sign in button in your web page. This button will be used to identify the user. When that is done, you need to verify that user’s identity on the server-side. This can be easily done through the BrowserID verification service.

    Here’s some complete sample code:

    <img id="sign-in" src="" alt="Sign in">
    <script src=""></script>
      document.getElementById("sign-in").addEventListener("click", function () { {
          if (assertion) {
                  User has successfully selected an email
                  address they control to sign in with.
          } else {
              // The user is not logged in
      }, false);

    When you successfully received the assertion, send a request to with two GET parameters. For instance:

    $ curl "<assertion>&"
      "status": "okay",
      "email": "",
      "audience": "",
      "valid-until": 1308859352261,
      "issuer": ""

    How does it work?

    If you want to delve deeper into the flow and inner workings of BrowserID, check the How BrowserID Works article.

    BrowserID is experimental – help us

    Please note that while Mozilla Labs is putting a lot of work and thought into BrowserID, its current state is experimental. That means that it is not recommended to use in any real-world production web sites at this moment.

    BrowserID is something Mozilla believe to be very beneficial to the web, but we need your help! Please try BrowserID out as a user, play around with the code and give us feedback! We are working on making this a great asset for users and developers alike, and any input we get will make it easier and faster to reach that goal!

  3. An interesting way to determine if you are logged into social web sites

    Do you remember the trick how to find out that you went to certain web sites by analysing link colour (now patched in Firefox)? There is much your browser tells about you if you just create a few HTML elements.

    Mike Cardwell has found an interesting way to detect if you are logged into social web sites. The easiest trick lies with GMail. Mike created a photo and uploaded it to Google. If you add this image to an HTML document and add event handlers for the success and failure case you can check if the visitor is logged in or not – as the photo gets delivered when you are and GMail delivers a 404 document when you are not:

    <img style="display:none;"

    This works in all browsers and can be used to for example send mailto: links to GMail directly. Notice that this just checks that you are logged in, it doesn’t mean you get access to content.

    For Facebook and Twitter, this doesn’t quite work. Instead, Mike tries to read content with the APIs and relies on errors to be thrown on 404 responses:

    <script type="text/javascript"
    <script type="text/javascript"

    This fails to work in Internet Explorer and Opera, but still works nicely for the other browsers. In Firefox you can work around this using the Request Policy add-on.

    It’d be interesting to see what other social web sites can be detected with some simple onload and onerror handlers. Know any others?

  4. First Beta release of Mozilla Persona – Login without Passwords

    For the past year, we’ve been rapidly improving Mozilla Persona (previously BrowserID). Our goal is simple: we want to eliminate passwords on the Web. Today, after many iterations based on community implementation feedback, Persona enters Beta. This first beta means:

    1. we’ve produced and are committing to a much improved API
    2. the first-user experience is significantly improved and streamlined: it’s actually hard to get lost
    3. critical new features, including support for showing your site’s name and logo, as well as terms of service and privacy policy, are live

    Since the beginning, Mozilla Persona was designed to work across browsers. Our commitment to this continues: Persona Beta 1 supports all major mobile, tablet, and desktop browsers. In fact, we’re working to build an extensive library of automated regression tests across all browser platforms to ensure that this support remains rock solid as we continue to add features.

    Persona is not just a great product, it’s also designed with the Mozilla Values in mind. When you deploy Persona on your web site (in an afternoon or, sometimes, only 15 minutes), you’re showing respect for your users and their data. You’re only asking for the data needed to log them in, and users know they’re only sharing exactly what’s shown on the screen.

    The technology behind Persona is interesting in its own right. We’ve built and scaled Mozilla’s first serious node.js-based service. We’ll be writing a few more posts on the specifics of our technology in the weeks and months to come. In the meantime, check out our source code, and join us on email or irc.

    And if you’re building or upgrading a web site, don’t forget to add Persona login support! Our quick setup guide should help you get off the ground in minutes.

  5. Ben Adida on BrowserID and identity

    This is the second installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. Today Ben Adida is in the hot seat to discuss BrowserID, Mozilla’s identity initiative.

    Tristan Nitot – Hi Ben, can you briefly introduce yourself?

    Ben Adida – I’ve been hacking since high school and, since college, I’ve been fascinated with cryptography, security, and controlling my data. I built my first DB-backed web site before cookies. I ran my own IMAP mail server starting in 1997 because no one else was doing it the way I wanted it. I started an open-source web dev shop in 2000, went back to grad school in 2003 to work on secure voting, explored security and privacy of health data at Harvard Med for a few years, and joined Mozilla in March 2011. I’m now Tech Lead on Identity and User Data, and I’m having a blast.

    TN – Oh my… running your own IMAP server in 1997? That’s the kind of thing that gives instant nerd credibility ;-)

    BA – Oh yes, big nerd and proud of it!

    TN – So you’re now with Mozilla, focusing on Identity and User data. Can you update us on what’s Mozilla is doing on these fronts?

    BA – Everyone I talk to within Mozilla realizes that the Open Web depends on more than just the Firefox web browser. People are storing massive quantities of their personal data online, using dozens of services, and an open browser is not enough to ensure that they have true choice, true control, that they can shape the Web to their liking. So we need to be working towards providing user choice in web-based services, too. The first piece of the puzzle is a usable, federated, and distributed identity system. That’s what we’re doing with BrowserID.

    TN – “federated, distributed”, with users having control… Sounds like the original pillars of the Web, right? I mean, as opposed to what we tend to see these days, with identity being concentrated into the hands of very large commercial organizations… How do you plan to achieve this?

    BA – That’s right, distributed/federated *is* the way of the Web, but when you look at today’s identity solutions, most are incredibly centralized, and those that are more distributed in terms of protocol tend to become centralized in implementation because of the so-called NASCAR problem: you get to log in with Google or Yahoo, and if you’re *really* knowledgeable then maybe you can log in with your own Identity Provider. We think we can do better for users and developers in terms of ease of use and adoption.

    TN – And what about privacy?

    BA – We’ve specifically designed BrowserID to reduce the amount of private data that changes hands to the bare minimum required for authentication. For example, in every other web-based identity system today, the site you log into phones home to your identity provider. In the real world, the equivalent is: you check into a hotel, present your ID to confirm your name, and the receptionist calls the issuing government agency and says “Hi, this is the Hyatt San Francisco, Tristan is checking in just now, is that okay?” Why does the government agency or, in the case of a privately issued identifier, the commercial entity, need to know where and when you’re checking in? In the real world, the receptionist just checks the seal on the ID without phoning anyone. BrowserID recreates this more restrained, more privacy-protecting data flow for web logins.

    TN – So how do you manage to get the best of both worlds: user experience and user control?

    BA – First we’re making the browser an important part of the protocol. After all, the browser is the User’s Agent. Isn’t it a little bit silly on today’s Web that you typically have a tab open to your gmail, and then another site asks you to log in with Google or Yahoo? Why can’t the browser help coordinate those two tabs? You’re logged into gmail, of course you have a gmail email address you can use to authenticate! And in the enterprise setting, you’re logged into your company webmail, of course you can authenticate using that enterprise identity! The browser can help reduce user complexity significantly.

    TN – But I could want to use another email address, than the one I use for my Webmail…

    BA – Right, so we’re always going to give users a choice. Users can choose exactly which persona they want to present. And one major BrowserID design point is simply that users understand email addresses as personas. They typically have home and work email addresses, and they don’t use them the same way. If they have a moonlighting job, they often have a separate email address for that. So BrowserID is based on this concept users already understand: logging in is simply delivering an email address to a web site in a way that the web site can easily verify.

    TN – Cool. Say I’m a Web developer that wants to use BrowserID on my site. How hard is that? How much do I have to relinquish control of my users to Mozilla?

    BA – It takes about 5 lines of JavaScript and 10 lines of backend code to integrate BrowserID, and it works today. It’s by far the easiest of the available identity solutions. In the short term, it means you’re relying on Mozilla servers to provide the BrowserID interface and verify users’ email addresses. That said, this is only temporary scaffolding for our distributed system.

    TN – But as BrowserID becomes native in browsers and identity providers appear, this will change?

    BA – We’ve taken great care to design the system so that, as browsers begin to support the BrowserID APIs natively, we can remove our scaffolding and leave standing a truly distributed protocol. Best of all, web sites don’t have to change a line of code for that to happen: as the identity providers and browsers start supporting BrowserID, our scaffolding automatically fades away. And let’s say you’re a web developer and you want to stop using BrowserID for whatever reason: just send your users an email with their new password, and you’re done. No other identity system minimizes lock-in this much, for both users and web developers.

    TN – So minimizing lock-in is part of the BrowserID design goals?

    BA – Absolutely! This is part of our mission and manifesto. We don’t want to own users, we want to empower them. Mozilla is in a unique position to build this kind of identity system because, as we all like to say, Mozilla answers only to users, and we can leverage Firefox to deploy these pro-user designs.

    TN – Fantastic! What would you recommend to Websites who want to do a test-run on their site? And for users who want to experience BrowserID right away?

    BA – Web developers can check out our documentation. Users can check out, a very promising distributed photo storage system shepherded by WebFWD that chose BrowserID. Just click the distinctive BrowserID login button to get a taste of the user experience.

    TN – I’m sure our readers will try it right away! Thanks a lot Ben for your time. Long live BrowserID!

  6. Getting involved with Account Manager

    It’s been a couple of weeks since we originally posted about Account Manager and we’ve gotten a lot of feedback. We’ve got a few opportunities for people to get more involved with the project, listed below.

    Join us at the Account Manager Meet-up or at IIW

    We are hosting an Account Manager Meet-up on Friday, May 21st at Mozilla’s Mountain View Headquarters. This meetup will be an excellent opportunity to give your feedback on the draft specification as we prepare to finalize it. So, if you are a web developer, sysadmin, protocol or security expert, RSVP here.

    The summit will be from 1PM to 4PM followed by a “cantina” during which you’ll get a chance to meet with other Mozilla developers over informal drinks and snacks.

    We’ll also be presenting at the Internet Identity Workshop next week; if you are planning on attending IIW look for the Account Manager talk and come and say hello!

    Browser-assisted registration

    Another way to help out is to add reigistration support to your site. The latest version of the Account Manager add-on adds support for a basic registration flow, and we’re very interested in finding out what the Web development community thinks about it. Here’s what you need to do:

    Add a snippet to the username-password-form profile in your AMCD:

    "register": {
        "method": "POST",
        "path": "/register-endpoint",
        "id-type": "email"

    Then you need to add a method at /register-endpoint which will receive the user id and secret as POST parameters. Your method should return 200 if the id and secret are OK, otherwise return 400 with a snippet of JSON (see the spec for details and examples).

    You might need to change your content to accomodate this new model: after you return 200 the expectation is that there is a username+password pair which is valid, even though it might map to a disabled account. For example, if you need to ask for additional information, have the user solve a captcha, or require email verification, simply keep the account disabled until those additional requirements have been met.

    Addressing cross-site request forgeries

    Based on feedback from the community, we’ve been investigating several possibilities for preventing CSRF attacks with Account Manager. In addition to supporting CSRF tokens, the latest proposal leverages headers to achieve the same goal with fewer requests and without a session cookie. Interested? Join the discussion on our forum.

    Join us online

    Join our online community, visit the Account Manager feature page to learn more about Account Manager, and to subscribe to our mailing list/forum.

    If you add support for Account Manager to your site, please add yourself to the the wiki page for early Account Manager sites.