I’m not sure we save a lot of effort by going with Google, GitHub, etc.
auth for BrowserCompat (BC), especially if that’s what we’re going to do
for MDN as well. I think it is better to decide on what MDN auth will be,
and then rely on MDN authentication for BC.
“Authentication” covers a lot of concerns, and you can’t cleanly split them
up and treat them independently. Some of the aspects:
* Identity - Who is the user? Is this the same user on this site as the
other site? How do I identify this user to other users?
* Clients - What technology is a user using to access the system? What are
the capabilities? What is the interface?
* User Authentication - In what ways can a user assert their identify? Is
there one or more than one? Can they add and remove them?
* Authorization - What is a user allowed to do on a system? What is the
process for adding and removing authorization? Who can do it?
* Request Credentials - How does a user assert their identity when making a
request? How does this change with different clients?
* Login and Account Setup - What is the user interface for creating an
account? For logging into a system? For modifying their account? For
recovering lost credentials?
Here’s the situation today with MDN (
developer.mozilla.org):
*Identity - MDN users have a unique username (public) and a primary email
(private, changeable) that they choose at signup. They have a profile page
where they can add a bio and photo, as well as links to themselves on other
websites.
* Clients - MDN users use a web browser to access the site.
* User Authentication - MDN users can use Persona and GitHub to
authenticate.
* Authorization - MDN uses Django’s authorization system, with superusers,
staff users, and permission groups. There are also feature flags that can
be tied to users, groups, etc.
* Request Credentials - A session cookie is used for browser access
* Login and Account Setup - Browser sign in starts with authenticating with
GitHub or Persona. If the GitHub/Persona account is known, a session cookie
is sent for the associated user. If unknown, new account setup begins,
perhaps using the username and email for defaults (it has been a while
since I setup my MDN account). Account recovery is through a Bugzilla bug
and administrator intervention.
Here’s today’s situation on BrowserCompat (
browsercompat.herokuapp.com):
* Identify - BC users have a unique username (public) and a primary email
(private, changeable) that they choose at signup. The system chooses a
database ID that is their primary identifier.
* Clients - BC users primarily interact with the API through HTTP requests,
such as JavaScript requests from the (browser-based) contribution and
moderation (C&M) interface. A web interface is provided for prototypes,
login, and account maintenance.
* User Authentication - BC users can use a username and password or Firefox
Accounts to log in. The FxA account auth is currently broken (bug 1229037)
* Authorization - BC uses Django’s authorization system, with superusers,
staff users, and permissions groups. The permission groups are mapped to
API permissions, currently“change-resource”, “delete-resource” and
“import-mdn”.
* Request Credentials - An OAuth2 token provisioned by the API is used for
most HTTP requests. A session cookie is used for web clients directly on
the API server, including when visiting the API server to provision an
OAuth2 token.
* Login and Account Setup - With Firefox Accounts (FxA), a user
authenticates with FxA, which is a login for a known FxA account, and goes
to account creation for an unknown FxA account. With username and password,
a user has to pick if they are logging in or creating an account first. A
user can recover an account by requesting a password reset through their
primary email.
Here’s what I’d like:
* Identify - Users have a unique username and primary email on MDN. BC
users have an MDN username and a BC UUID.
* Clients - Users use a web browser to access MDN and BC web-based sites.
Users primarily access the BC API through JS and backend HTTP requests,
such as from the C&M UI.
* User Authentication - MDN users can use FxA and GitHub to authenticate.
More auth methods are added using a test-first process similar to this one:
https://medium.com/on-startups/how-adding-one-button-increased-our-signups-by-3x-27988ea3d254
. BC users authenticate through their MDN account.
* Authorization - MDN uses Django’s authentication system. BC permissions
are based on permissions in MDN’s system, communicated through a non-public
MDN API.
* Request Credentials - MDN and BC uses local session cookies for browser
access. The BC API uses an OAuth2 token provisioned by MDN.
* Login and Account Setup - MDN sign-in begins with authenticating with
GitHub or FxA. Known credentials means a login, new credentials a signup.
BC sign-in begins with MDN sign-in., automatically creating an BC
UUID-based account for new MDN credentials. BC is a trusted OAuth2 relier,
and is provided OAuth2 tokens without user approval. Account recovery is
via the user’s chosen auth providers, or Bugzilla bug.
With this, a typical user interaction could be:
* A logged-in MDN visitor sees out-of-date contribution data on a reference
page. They click a “edit this data” button.
* Their browser flashes as it bounces between MDN and BC. They land on the
BC C&M site, logged in and displaying their MDN username.
* They edit the data, save, and click “return to MDN”
* Their new contribution appears on the MDN reference page
The work, in rough order, would be:
* MDN adds OAuth2 provider support.
* BC adds MDN as an OAuth2 provider. MDN marks BC as a trusted OAuth2
relier.
* BC drops FxA
* BC drops username+password auth
* BC drops usernames, email
* MDN adds a user data API, authenticated with OAuth2 for non-public
information, and maybe supporting JSON Web Token for detailing permissions
* BC drops local permissions, and relies on MDN user data API for BC
permissions
* MDN drops Persona auth
* MDN adds FxA auth
* Detail work around new account creation (for example, a user without an
MDN account wants to contribute BC data)
The benefits are:
* Identity is simple - your identity is your MDN account
* One place to add or change user authentication
* One place to add or change user authorization
* Most login and account interface work is on one website
* No PII at all stored in BC database
The costs are:
* MDN grows an OAuth2 provider
* MDN grows a user data API
* Manual migration of 14 current browsercompat accounts.
* Additional corner cases around account creation
* Local BC development requires configuring MDN auth, or using a
non-production auth system
As one of the people who will probably have to migrate MDN away from
Persona, this feels like less work to me, since I only need to setup FxA
and other auth providers for one website. It is also extendable to future
micro-services. I think the time to do this is now, when the number of BC
user accounts is still small.
John