Single sign-on brainstorm (or, SSO SOS)

Tags: #<Tag:0x00007fe3d1ed22b0>


SSO has been on the table for a while now and, so far as I know, there’s no consensus yet on even the broad strokes of how it should be done or what it should look like. The way I’ve been thinking about this is in three parts: what does auth get used for, what should these experiences look like from the user end, and what are the consequences of various implementations? I’ve got some ideas and outlines, but this is far from complete and could use some thought and feedback. Not all of this is new, either.

Categories of Authentication

Interactive Login

This is the typical case for a site user. A user wants to go to a project, sign up, and contribute or peruse data. They may or may not want to use more than one MetaBrainz project.

User Applications

These are user-facing applications that make use of data stored in MetaBrainz to accomplish some task, such as tagging music, managing collections, or submitting processed data (e.g. to AcousticBrainz). Individual users interact with these applications and may want them to have access to user-specific information.

Organizational Applications

Larger-scale data consumers or contributors which are not tied to user interaction, such as sites which make use of live data feeds or make heavy use of web services. No user-specific information.


Each of the above categories will need to interact with the site in a different way. I’m providing some brief discussion of what I think would be useful for providing these.

Interactive Login

Users may or may not want to use multiple MetaBrainz projects. Allowing users to create an account on any given MetaBrainz project site would allow users who only want to use one project to not have to go to another project’s site to sign up. Having this account then centralized would allow people who do want to use more than one project move seamlessly between them.

Additionally, signing in at one project should carry over to other projects if at all possible. Entering credentials multiple times is unnecessary interaction and can be an annoyance. The same goes for signing in and manually acknowledging account sharing via a “Do you want to allow MusicBrainz to access your account?” dialog.

User Applications

This is where we should ask users if they want to allow access to their account. We probably don’t want to provide API that requires or encourages prompting users for credentials, as this creates trust problems. Instead, applications should register and define what privileges they require and users must grant them permission.

Organizational Applications

These can be registered/stored in the same manner as user applications, without the need to define a set of permissions that users must grant.

Implementation and Consequences

The above interactions suggest a divide in handling between application and user handling, but it seems to me that handling for both should take place centrally. Users register in a decentralized fashion and cross-project information, such as credentials, is stored centrally, allowing decentralized login. Applications, however, should most likely be registered centrally in a sort of “developer hub”.

The decentralized, cross-project sign-in for users has some non-trivial technical hurdles to clear, but seems likely to provide the best overall experience. Prompting users to allow access could create difficulty for applications like which should be able to run headless, but I’m not sure how best to ease this. Perhaps asking the user to generate some sort of token to provide the app for headless use would work, but I haven’t thought about this extensively.


Some of these ideas, like the basic requirements for user interaction, I’m rather attached to. Most of them I’m not. I also haven’t provided any concrete ideas for implementation as I think it’s important to reach a consensus on what things should look like for users and applications before we decide how to make it look like that


One thing I was wondering about is how to handle access to data in all of our projects. Do we make all these projects provide their own implementation of OAuth protocol or do we keep it all within MetaBrainz website? There are two big things to consider (that I found so far):

  • Scopes. Some projects that already implement OAuth project has a set of scopes. See, Do we prefix them like mb_* and cb_*? Might be worth taking a look at how big projects like Google do that. I quite like how they present you with details that you are giving access to in different projects.

  • Access to data. After user approves the application, what’s next? How does the project know which data application has access to? Do we have an internal API for this?

These are two big things I’m concerned about. I actually have plans to maybe implement OAuth stuff on MetaBrainz for some project.


Will SSO replace OAuth2 or run along side it?


I think that part of a comprehensive SSO solution will be continuing to provide OAuth2 and, in particular, providing a consistent way to interact with OAuth2 across projects (both from a user perspective and an application perspective).