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.
Interaction
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 isrcsubmit.py 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.
Concluding
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