Web Authn Extension

[sberyozkin]

Describe the extension
Have been planning to open the issue for a while:
https://en.wikipedia.org/wiki/WebAuthn

I've noticed recently Vertx Auth ships the extension (cc @pmlopes) so we can have an extension which builds on top of it. And then may be recommend it as the main option when no SSO is involved

Interested in this extension, please +1 via the emoji/reaction feature of GitHub (top right).

CC @stuartwdouglas @pedroigor

[sberyozkin]

Note: there is no plan to integrate it into quarkus-oidc as it would better be done at the level of the user authenticating into Keycloak when OIDC is involved

[amitrajpushkar]

sir how can i fix the issue?

[renegrob]

@sberyozkin What is the scope? 2nd-Factor, passwordless, support for biometric authentication / username-less (resident-keys /client-side discoverable credentials)? My goal is to support all of them.

[renegrob]

@sberyozkin @pmlopes I had a look at https://github.com/vert-x3/vertx-auth/tree/master/vertx-auth-webauthn it is based on Vertx 4.0.0 while Quarkus is using Vertx 3.9.5. I don't know if it makes sense to backport Vertx WebAuthn to Verx 3.9.5 or if it is possible to upgrade Quarkus to Vertx 4.0.0.
Currently I get:

WebAuthn webAuthN = WebAuthn.create(
  class file for io.vertx.ext.auth.authentication.AuthenticationProvider not found

Else an alternative would be https://github.com/webauthn4j/webauthn4j which is also used by Keycloak. However that is not a reactive implementation.

[cescoffier]

FYI Vert.x 4 has webauthn support.

[sberyozkin]

@renegrob Hi, yes the priority is for it to be reactive - can you please investigate the idea of having a Vert.x 4.x based WebAuthn extension in Quarkus 2.0.x ? It would be a very valuable addition to Quarkus Sec.

[sberyozkin]

@renegrob

What is the scope? 2nd-Factor, passwordless, support for biometric authentication / username-less (resident-keys /client-side discoverable credentials)? My goal is to support all of them.

I guess we need to start from the most mainstream case which can be used as a recommended alternative to BasicAuth/FormAuth for cases where OpenId Connect providers such as Keycloak can not be used (if they can be used then they'll take care of WebAuthn).

passwordless is probably the best fit to start with

[pmlopes]

@sberyozkin I'm trying to create a vertx howto on webauthn the next week. The most common use case is authentication of interactive applications. It is not intended to be used on APIs (machine to machine) so it shall replace Form login screens, and it can replace OAuth2/OIDC if the only use of the IdP is to authenticate, not to perform any kind of RBAC as webauthn is not designed for such use cases.

[renegrob]

Yes unless for https://fidoalliance.org/specifications/download-iot-specifications/ you need user presence / verification to login. It can't be used on a request base like BasicAuth or OAuth2. But it could for instance be used to issue a JWT token.
The question is how it should be integrated in Quarkus: just as a component you can use to build your own solution or as a ready-to-go solution. I think it should only be building blocks plus examples how it can be used.
I see four parts:

• Javascript / Client
• Registration
• Login
• Persistence of token data associated with a user

Also FIDO is often still used as 2nd factor and not (yet) passwordless. Passwordless authentication requires user verification if you want to end up with a strong authentication. User verification is only supported with on newer generations of tokens and by a few browsers. Not being passworldless means having a first factor authentication e.g. BasicAuth / FormAuth.
But I guess this is all up to the user.

[sberyozkin]

@renegrob Agreed it should be the building blocks only for now. I'll reread the texts for me to contribute better to this discussion, thanks

[pmlopes]

@renegrob the vert.x module already covers the 4 items:

• JS: https://github.com/vert-x3/vertx-auth/blob/master/vertx-auth-webauthn/src/main/js/vertx-auth-webauthn.js
• Registration + Login: https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/main/java/io/vertx/ext/web/handler/WebAuthnHandler.java
• Persistence of token data: https://github.com/vert-x3/vertx-auth/blob/master/vertx-auth-webauthn/src/main/java/io/vertx/ext/auth/webauthn/Authenticator.java

By webauthn I'm referring to FIDO2 spec, not the U2F. The FIDO2 spec allows you to perform strong authentication. The reason why most services use it as 2nd factor is because by design you can't really "recover" a lost token, if you lose the token, there is no way to recover the private keys. If that was possible it would defeat the whole security model of the token.

Nothing really forbids you to work the reverse way, FIDO2 first and fallback to "magic links": https://www.okta.com/blog/2020/09/magic-links/ which are also not that hard to implement.

[pmlopes]

FYI: https://how-to.vertx.io/fido2-webauthn-howto/ the basic how-to is here

[renegrob]

I currently don't have enough spare time to start this.

[sberyozkin]

@renegrob Sure, np at all, I'll still have to catch up. I'm sure we'll have another good discussion and some progress soon enough.

[pjgg]

+1 !

[FroMage]

I'm working on this one ATM, I already have it working in Renarde, but would like an extension.

[FroMage]

I have a ton of questions related to this extension, actually. Because I'm trying to make it fit in the Quarkus Security model, which decouples those two aspects:

• the user provides credentials, so we attempt authentication (eg. Form or Basic auth)
• an authentication attempt occurs, and we have to validate it and create a SecurityIdentity (eg. JPA security)

The Vert.x extension does both. I could decouple it, but fact of the matter is that JPA can only authenticate username/password credentials, not WebAuthn ones. Or I'd have to extend that extension.

The bigger question is how we remember that the user is logged in, because:

• Quarkus FORM auth has a TrustedIdentityCredential method it uses to store a signed user cookie, but all that is configured in the FORM auth config, and not accessible
• In Renarde, I tell users to provide their own login/logout/register endpoints, because there's interactive validation that the Quarkus-provided endpoints can't handle, so JPA security and even FORM auth are out for those reasons, and so I store the user cookie using the JWT extension
• WebAuthn also needs a user cookie, but should I use the FORM cookie, and extract its settings, or depend on JWT and rely on it?

Any opinion @sberyozkin @stuartwdouglas ?

I've also noticed a disconnect between what I am trying to do in Renarde, which is that I handle my own login and registration endpoints, and there's no API in Quarkus Security that lets me tell the system that I've created a user, or logged one in, and that I don't care how that user is remembered, because I'd like it to be Quarkus' job: session cookie or JWT, whatever.

[stuartwdouglas]

We can move the TrustedIdentityCredential logic/config out, but TBH I am kinda surprised it is needed. Cookie based auth is kinda frowned upon a these days. JPA can also authenticate TrustedAuthenticationRequest so it should just work.

JWT can also work here, the TrustedAuthenticationRequest is just simpler as it does not require certificates to be setup.

In terms of how you map the request to the SecurityIdentity that is really up to the user, they can use a SecurityIdentityAugmentor to create whatever SecurityIdentity they require based on the provided information.

[FroMage]

Cookie based auth is kinda frowned upon a these days

Well, I don't think there's any other way to keep people logged in a website. Not for REST, but for a website. OIDC relies on cookies, so does JWT. I can't imagine any other way to do it, frankly.

JPA does indeed handle TrustedAuthenticationRequest, but that's username/password. I won't work for WebAuthn which requires different data to be stored.

I'm not sure what you're trying to tell me with SecurityIdentityAugmentor. The bit that I'm lacking is for the user to be able to declare in an endpoint that we're good, the user is logged in now, and so Quarkus can save the user cookie. I have to manually create the cookie in my endpoints, by knowing how Quarkus reads it.

This is something I need to do when I create the user account, and after login. Because I can't use the Quarkus login endpoints due to interactive validation.

[renegrob]

I think the issue is that Quarkus does not have a concept of a 2nd-factor/step-up authentication. Unless you use the passwordless option, you need first to authenticate with a first factor and that should - at least in my point of view - be any factor that the user configured. The first factor login should be handled independently whether its BasicAuth, JWT or OAuth2.

[renegrob]

Cookie based auth is kinda frowned upon a these days

It is for backend to backend service authentication, but it isn't for browser to backend authentication. The times when the browser directly authenticated against the backend are over (except for some internal tools). Usually the browser accesses the services through a gateway which uses cookies to track the session and delegates the authentication and authorization to a service (such as KeyCloack). That's were also WebAuthN comes into play. WebAuthN always needs to communicate with the browser - at least indirectly, that's why there has to be a concept of a session. Often the gateway offers a way to use cookies that are not returned to the end user but held by the gateway. However, different systems have slightly different concepts. Therefore it would be good to not depend on a single way of associating a session but e.g. use a @Default bean that can be replaced.

[stuartwdouglas]

JPA does indeed handle TrustedAuthenticationRequest, but that's username/password. I won't work for WebAuthn which requires different data to be stored.

TrustedAuthenticationRequest just has a principal, after the initial authentication the password does not come into it.

I'm not sure what you're trying to tell me with SecurityIdentityAugmentor. The bit that I'm lacking is for the user to be able to declare in an endpoint that we're good, the user is logged in now, and so Quarkus can save the user cookie. I have to manually create the cookie in my endpoints, by knowing how Quarkus reads it.

I am not 100% sure what you are asking for here, it sounds like you want to be able to use io.quarkus.vertx.http.runtime.security.PersistentLoginManager outside of form based auth?

[FroMage]

I am not 100% sure what you are asking for here, it sounds like you want to be able to use io.quarkus.vertx.http.runtime.security.PersistentLoginManager outside of form based auth?

Yes, and that's what I've done, actually. But with a separate key, config and cookie name. Not sure if we should keep them separate or regroup under a non-form config.