jsr icon indicating copy to clipboard operation
jsr copied to clipboard
verified publisher icon jsr-io

Support login via passkeys

Open atjn opened this issue 1 year ago • 1 comments

JSR currently only supports login via a GitHub user. GitHub is a private for-profit company. This has a lot of negative effects:

  • People that do not want to be tracked by GitHub (and by extension the U.S government) cannot participate in the JS ecosystem.
  • People that cannot use GitHub (e.g. government restrictions, accessibility issues) cannot participate in the JS ecosystem.
  • If GitHub chooses not to allow certain people to use their service, those people cannot participate in the JS ecosystem.
  • People that do not wish to be affiliated with GitHub (e.g. https://github.com/isaacs/github/issues/1679) cannot participate in the JS ecosystem.
  • The GitHub login system is closed source and there is no way to verify how GitHub has authenticated a user. This goes against the JSR goal of being open source.
  • If GitHub is temporarily down, the entire JS ecosystem is unable to publish packages. This goes against the JSR goal of being robust.
  • Any time the GitHub login API is changed, immediate effort must be made to support the new API or it will be impossible to publish JS packages. The JSR team cannot control when this happens. This goes against the JSR goals of being robust and low-maintenance.
  • If the GitHub API permanently breaks for any reason, it will be near-impossible to reauthenticate publishers, causing a major disruption to the entire JS ecosystem. This goes against the JSR goals of being robust and low-maintenance.

TL;DR I think it is very dangerous to have GitHub login be the one and only source of access to something that is supposed to be open to everyone.

I propose that you support login via Passkeys. Passkeys are a well-established login standard across all major OS'es and browser vendors. It is a fully open standard that you can use open-source libraries to support. It does not require any third-party services and anyone can implement their own login system for it, enabling customized support for many minorities and bypassing any restrictions set by private firms or governments.

Passkeys are very safe, they provide many options for 2-factor authentication and hardware-based authentication, so they will not be a downgrade from GitHub users.

Passkey support also creates new opportunities. For example, to get a 100% quality score on a package, devs could be required to use a passkey with the latest encryption algorithm and some sort of 2-factor.

Additional notes

I know that JSR is a very new project, and developing a custom login system is a lot of work, so that is probably why you launched with a GitHub login as the only solution. I think this is fair, but it does not solve all the problems I have listed above, so I think it is good to be tracking and prioritizing this feature now.

In the above examples I treat JSR as the one and only publishing method for JS packages. This is obviously not true today, but I believe the ambition is to make JSR so good that everybody uses it, and therefore I am treating it as such.

I also think it is a problem that JSR development is GitHub-only, that transparency logs are GitHub-only, and that JSR itself is only accessible from servers controlled by a single for-profit company. But I believe that the login issue is a much bigger issue than the others and that is why I am focusing on this issue for the time being.

I do not expect you to completely remove support for GitHub logins, but I think passkeys should be the default and recommended way to login.

atjn avatar Apr 11 '24 09:04 atjn

@crowlKats

Passkeys (or WebAuthn) is a very powerful way of authenticating users without the drawbacks of traditional password authentication^passwords

Requirements

  • A place to store user passkeys (database)
  • A place to store generated challenges (database)
  • Some UI for the user to manage their stored passkeys

How it works

There's several ways to implement passkeys, but from my knowledge the general gist is this:

Register

  1. The user clicks Register
  2. (optional, but recommended) The user enters their email
  3. (optional, but recommended) The email address is validated (with a code or similar)
  4. The website requests a challenge (random string) from the server
  5. The server response allows building a PublicKeyCredentialCreationOptions object
  6. The website calls navigator.credentials.create(options)
  7. The website sends the response to the server
  8. The server validates the response by checking the challenge
  9. The server stores the validated passkey

The reason the email address is obtained is to allow a user to create a new passkey when signing in from a new device, or to recover from deleting their passkey, from a link sent to their email.

You can also encourage a user to create a second passkey on a different "roaming" device for the same purposes as above,

Login

  1. The user clicks Login
  2. The website requests a challenge (random string) from the server
  3. The server response allows building a PublicKeyCredentialRequestOptions object
  4. The website calls navigator.credentials.get(options)
  5. The website sends the response to the server
  6. The server fetches the stored passkey from the received ID
  7. The server validates the response by checking the challenge against the stored passkey

The documentation of PublicKeyCredentialCreationOptions and PublicKeyCredentialRequestOptions can be pretty dense, I've tried to make it understandable (mostly for myself): https://github.com/Ionaru/webauthn-demo/blob/main/apps/client/src/app/utils/webauthn.ts

Ionaru avatar Oct 30 '25 21:10 Ionaru