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.

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:

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:

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).

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).

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.

@Dan re Basic Auth; Yes, really a great suggestion! That way this new login/logout feature would be useful immediately, and those using HTTP Basic Auth can stop closing down the whole browser just to unlogin as they are today accustomed to. And basic auth logout is still very much needed — even recent products like Netgear ReadyNAS use Basic Auth for remote file access.

[…] It is remarkable what the passage of time can do. Not only are we furthering common goals for the betterment of the web, as we have in the past, but now we’re both working in various capacities for Mozilla. Tantek will help us out with the CSS3 Flex Box Model, figuring out what the right thing to do with respect to stylable HTML5 form controls are, and help us with fundamental questions of identity and the open social web in connection with the account manager initiative in Firefox. […]

How do you plan to incorporate authentication schemes where steps have been already taken to prevent passwords from being sent in the clear. One such technique is described here, but there are many others:

@Anthony, if you’re thinking of checking session tokens and referer headers, then it seems a valid question. It does seem that people run a risk of implementing unprotected login methods meant only for account manager, which would be bad indeed.

Obviously nobody should disable CSRF protection for the sake of Firefox. Account manager must not depend on that.

Surely session tokens done as cookies will continue to work like always. That leats tokens inside a form (type=hidden and theoretically also url parameters) and referer headers. Perhaps add a referer: key to the JSON document? That same referer entry could be used to fish out tokens hidden in a form, but this seems an ugly hack and doesn’t really give much more protection than a session cookie.

Currently, I do CSRF protection via hidden form field (with a session-unique token, stored as part of the server’s session info). It doesn’t look like the login manager spec allows that; the login (“connect”) request has anything more than the username & password. So token-based CSRF prevention doesn’t seem possible.

This doesn’t seem to going to be working exactly one hundred percent to me. My site for example(still in the drafting stages) requires you to get a one time use form token that’s generated any time a user needs to login and it HAS to of course match the one on the serverside. Also i just looked over the comments and someone’s already said it for me. So good job in bringing the web back a step in security mozilla labs. Be sure to change it up to work with CSRF like methods as stated above or else only the most stupid sites will be doing it. Ie those that store passes in plain text(ie pizza hut and other online sites that i don’t give any “real” information too). Also what about those sites that are stupid and require a maximum length? What about that then mozilla labs? Also i hash my passwords in sha512 after adding in some obscuring(based upon the password input sot hat it’s the same each and ever time) how would this work out for me then? It’d not work out since you’re just going to be posting a plaintext password which = bad.

To me, it seems like you guys are just trying to make it “seem” more secure than what it really is.Yeah the passes will be better but it sure as hell won’t help prevent a mitm attack since the passwords have to be posted as plaintext and with the many many ways to strip ssl relying on it alone isn’t going to be enough.

Also i normally don’t comment or sign up on sites that use recaptcha since i am not google’s worker but this seems to be something that you as in you and all of the other firefox devs need to rethink.

Currently, I do CSRF protection via hidden form field (with a session-unique token, stored as part of the server’s session info). It doesn’t look like the login manager spec allows that; the login (“connect”) request has anything more than the username & password.