Support new npm WebAuthn

[ThisIsMissEm]

Is your feature request related to a problem?
Currently how Verdaccio handles authentication is via the older methods of using HTTP Headers or Couchdb style authentication; These methods, whilst working aren't as secure as using the user's web browser for authentication, and mean that integrating with SSO systems is much more complicated.

Describe the solution you'd like
npm now has a method known as "WebAuth" which is kind of like the OAuth Device Code Flow — Essentially, you make a request to an endpoint on the registry, which returns you two URLs. One is the URL to open in the user's browser, in order for them to log in; the other is a URL which the client polls in order to ascertain as to if a user has completed the login.

These are:

1. POST /-/v1/login with a body include the os.hostname()
2. the above call returns a data structure of { doneUrl: String, loginUrl: String } once the loginUrl is opened, then the client starts polling on doneUrl in order to check if the user has completed the login.

Note: This flow isn't exactly finalised yet, as it looks like npm actually does something different in it's implementation to that in libnpm: https://github.com/npm/cli/blob/latest/lib/auth/sso.js#L21 vs https://github.com/npm/npm-profile/blob/latest/lib/index.js#L69

Describe alternatives you've considered
Whilst the alternative is to use a purely CLI based approach, this has various other complexities involved, especially when dealing with SSO, so the browser-based approach would be preferential

Additional context
I'm mostly adding this here so I can reference it from another bug tracker; I'd be intending on contributing this authentication strategy to verdaccio, but it'll require npm & yarn also being in sync with this.

[juanpicado]

hi @ThisIsMissEm thanks for your detailed ticket, I appreciate it.

I've seen this over Twitter and read the discussion. Somehow, WebAuth is an internal npmjs implementation and I'd rather do not have it here unless there as eg #913 is a standard and I'm not forced to do reverse engineering again.

[ThisIsMissEm]

Hi @juanpicado, yes, the idea is to make this a standard. I'm trying to work on getting that to happen.

[juanpicado]

I understand and I respect it, but I guess other public entities are made for achieve such things. I don't know what you have on mind, but I'm not pretty much interested on this unless a big amount of 👍 change my mind and is being based in a web standard.

[juanpicado]

I wonder the future of this request based on the recent news, the progress was promising.

[ThisIsMissEm]

I think it's still going to be positive! In the announcement they did say they wanted to improve the multi-factor Authentication experience, and this could get them further along that path.

…

On 18. Mar 2020, at 19:46, Juan Picado @jotadeveloper ***@***.***> wrote: I wonder the future of this request based on the recent news, the progress was promising. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[juanpicado]

Ok, I just read npm/rfcs#93 (comment) so I guess we can close this one, not on my plans also to pursue this feature.

[ThisIsMissEm]

@juanpicado hold up a moment, whilst I've not had time, I am working to still make sure this gets into npm.

[ThisIsMissEm]

@juanpicado perhaps we can reword this issue, or close and open a new issue for supporting browser-based auth. It will be built with OAuth 2.0 Device Code Grants, it's just going to take some time to have an RFC and then start to get the changes into various CLIs and Registries.

[juanpicado]

I'd prefer to close this ticket and at any point in the future create a new one when the RCF gets more clarity what's their position, always we can reopen it. I'm just trying to house cleaning on this repo of tickets which has no clear path.