THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Proposal to convert AMO to use Firefox Accounts

Converting AMO to use FxA would increase FxA numbers, simplify the AMO code, centralize our authentication at Mozilla, and reduce our vulnerability footprint by keeping all account info in one place. AMO has had 50,000 unique successful logins in April and 200,000 since the start of the year (stats as of the end of April).

This is a work in progress. Feedback encouraged.

Proposed Flow

This is based heavily on the Marketplace transition to Firefox Accounts.

Engineering Considerations

• Engineering Estimate

• AMO is old enough to have several evolutions of login code in it (including browserid, several sha hash types, a migration from getpersonas, as well as external services like builder.amo and the forums). Removing all that code will be very good.

Q & A

• On certain administrative forms and when users try to delete their add-on we re-prompt for their password. FxA doesn't support this functionality. How will we deal with that?
  • I think we'll just omit it for now. Most administrative actions have moved to the CLI, and we have backups and logs for the other use cases.

• The AMO forums still talk directly to the AMO database to log in. This has been annoying for a very long time and there will likely be support for moving off this system. Three active proposals include: letting phpbb manage it's own authentication, writing an FxA plugin for phpbb, or moving off of phpbb altogether (likely to discourse).

• What if someone uses an FxA account that doesn't match their AMO account?
  • Do we need to worry about this case? If someone hit it we could build an admin tool to merge accounts or they could manually set their new accounts as owners of their add-ons.

• FxA supports creating a "pre-verified" account which essentially means you don't need to confirm your email address. If we know a user has confirmed their address (or we confirm it first) and they are logged in (or we email them a link to follow) this could be used to avoid an email. It also allows the user to change their email address during the transition if perhaps they signed up to AMO with me@work.com and want to switch to me@personal.com.
  • This sounds like it may be more trouble than it's worth. I'm going to sketch out the proposal without it and get feedback.