feat: Add web auth type

[jumoel]

What

Add the more generic web for the registry to use, instead of the implementation-specific webauthn authentication type.

Why

It's more generic and sounds better.

References

• Closes https://github.com/github/npm/issues/5499

[npm-cli-bot]

found 2 benchmarks with statistically significant performance improvements

• app-large: modules-only, no-lock

timing results

app-large	clean	lock-only	cache-only	cache-only peer-deps	modules-only	no-lock	no-cache	no-modules	no-clean	no-clean audit
npm@8	45.119 ±0.85	25.349 ±0.33	22.980 ±0.02	26.219 ±0.89	4.001 ±0.03	4.129 ±0.20	3.126 ±0.00	16.040 ±0.11	3.037 ±0.04	4.119 ±0.17
#5076	45.775 ±0.89	24.831 ±0.27	21.938 ±0.29	25.913 ±1.29	3.570 ±0.13	3.534 ±0.06	3.131 ±0.02	15.788 ±0.55	3.218 ±0.13	4.508 ±0.39

app-medium	clean	lock-only	cache-only	cache-only peer-deps	modules-only	no-lock	no-cache	no-modules	no-clean	no-clean audit
npm@8	69.035 ±44.16	18.783 ±0.60	16.726 ±0.18	18.371 ±0.02	3.577 ±0.01	3.509 ±0.09	3.215 ±0.01	11.562 ±0.15	2.982 ±0.04	4.079 ±0.06
#5076	33.534 ±2.31	18.641 ±0.24	16.398 ±0.75	17.649 ±0.21	3.489 ±0.01	3.517 ±0.09	3.094 ±0.27	10.748 ±0.21	3.060 ±0.16	3.962 ±0.02

[ljharb]

wouldn’t this be a breaking change? Also there’s tons of kinds of web auth that isn’t webauthn.

[jumoel]

@ljharb:

wouldn’t this be a breaking change?

Technically yes, but it’s never been enabled on the registry, except in staging, so it won’t be a problem.

We’ve already enabled the new header on the registry (and kept support for the old one).

Also there’s tons of kinds of web auth that isn’t webauthn.

Which is one of the reasons it’s changing. It’s not only webauthn that’s supported.

[ljharb]

What about private registries that may have implemented support in the meantime?

[darcyclarke]

@jumoel @MylesBorins as @ljharb notes, this is a breaking change now so we should probably just keep this as "webauthn" & not introduce another value for auth-type in the same major (ref. https://docs.npmjs.com/cli/v8/using-npm/config#auth-type).

[darcyclarke]

!Breaking change

[jumoel]

@darcyclarke what if we just add web as another alias?

[MylesBorins]

What about private registries that may have implemented support in the meantime?

There is 0 chance anyone has implemented this. If they had they likely would have reached out to clarify why the field is called webauthn.

The auth flow we are implementing is to "authenticate via website" not specific to WebAuthn. Our enhanced 2FA experience was launched explicitly as a beta. IMHO such beta services do not have to adhere to Semver (similar to the experimental status in Node.js). With that said, I recognize there is ambiguity here and we should be thoughtful about SemVer, but I also want to be pragmatic about committing the CLI to permanent legacy behavior for something that isn't currently supported by any registry.

I think we need to introduce --auth-type web in npm 8 for this feature with the proper header being sent to the registry, it does not make sense for us to have incorrect functionality or internals due to miscommunication during product design.

It seems like what we do need to decide is "what to do with the --auth-type webauthn flag. There seem to be two options

1. Remove --auth-type webauthn in npm 8

This is the cleanest approach imho, and operates under the assumption that the new 2FA experience and related functionality are beta. It is being a bit cavalier about SemVer and has a non-zero risk of breaking things... but I would bet a steak dinner that nothing breaks and this is a much cleaner solution

2. Deprecate --auth-type webauthn in npm 8 and remove it in npm 9.

In this approach we doc deprecate + warn for webauthn and remove it in 9.

---

Thoughts?

[darcyclarke]

@jumoel are you going to be updating this PR from the feedback above? Based on internal discussions & this thread, I believe the path forward here is to leave webauthn as a valid auth-type & just add web separately (the two should not coerce to eachother & you'll have to update this PR to not remove webauthn).

Our team can/will deprecate & remove the webauthn value in future versions.

[MylesBorins]

I believe the path forward here is to leave webauthn as a valid auth-type & just add web separately (the two should not coerce to eachother & you'll have to update this PR to not remove webauthn).

@darcyclarke I believe that is what this PR does in it's current implementation. We can ignore my comments about updating docs

[wraithgar]

This is going to collide with #5149 when that one lands. We'll have to rebase and update the copy, since we have switched to being able to deprecate certain config values instead of the entire config option.

[MylesBorins]

LGTM with a tiny nit

[MylesBorins]

Suggested change

	What authentication strategy to use with \`login\`.
	Pass \`web\` to use a web-based login.

[wraithgar]

I don't think removing the actual description is what we want here.