Currently we only expect a registry to be private and the only authentication we do is a simple bearer token. Anyone with this token can publish anything. No good for a public registry. Authentication on a public registry is a large overreaching issue and I'd like to start the implementation discussion here.

Inspiration

As a source of inspiration we can look towards crates.io's approach. They simply give you a Github OAuth flow and use the resultant token to verify your identity. This is very appealing as it offloads the scary security stuff to Github and lets us just deal with tokens. I'd like to propose this as our initial candidate for authentication.

Using an OAuth flow gives us a token<->account mapping we can then use to authenticate publish requests. For us this will likely look like "everyone can read a package but only owners/editors can write". Whoever publishes the first version of a package gets to be the owner. Owners can then add editors or transfer ownership so multiple people can publish to the same package. We could probably cleanly track this ownership in the git index.

Just like crates.io we can even support team ownership of packages however the read:org scope grants quite a broad view of what a team is up to (you can see all their projects) so anyone with private projects may want to avoid giving that scope. I don’t think team ownership is something we should go for straight away but it’s nice to know we could support it in the future if we take this route.

While I’ve not handled OAuth authentication flows before I believe I have a pretty good grasp of how it works. All we would need is a database (probably Postgres) to store OAuth tokens and some frontend to serve the OAuth request. The rest will then just be throwing those tokens around in the right places. There are also pretty good, easy to follow, guidelines on how to do this safely/securely. I don’t expect we would run into any significant issues.

Current concerns

The main thing that concerns me at the moment is not how we would implement this, it's actually the scope concept we have. The scope is not currently bound by anything and people are free to declare their scope however they want. I think we need to more strongly consider what this scope is backed by.

Should scopes be able to be changed?

• This seems nasty and I don’t think we should support it:
  • If we do support it then dependants can no longer resolve their packages. We could create a user id mapping or do scope forwarding but this gets nasty so fast I don't think we can even consider it an option.
  • If we don't support it then how should we consider people's changing identities? "Just keep using their original identity" is an option, but is it the right option?

Should a scope be claimed by an individual/team?

• I think so but how do we determine who can claim what scope?
  • Only allowing Github user or team name seems ok, if a little restrictive. But again what happens if they change their name?
  • First come first serve has easy semantics and it’s reasonable to expect the scope to never change. This is scary though as “scope parking” may become a problem, ie I go and claim the Roblox scope just to be annoying. How can we determine if it’s ok for them to claim a scope?
  • Maybe first come first serve but it has to be your github user/team name and it cannot change is ok? (at least on a public registry)