Quarkus webauthn

[madocx]

Working on a webauthn poc, utilizing webauthn4j (https://github.com/webauthn4j/webauthn4j). Everything works perfectly running in a JVM, but after compiling natively, the library fails verification of the signature. Specifically, com.webauthn4j.validator.AssertionSignatureValidator.verifySignature().

Under the covers, it seems webauthn4j is using JCASecurityServices. However, none of the recommendations here seem to help : https://www.graalvm.org/latest/reference-manual/native-image/dynamic-features/JCASecurityServices/

Has anyone else faced something like this, or have any recommendations on what might possibly be causing it? This is the first time I've run into something like this where it natively compiles without any issues, but just behaves entirely differently (and incorrectly) at runtime.

[quarkus-bot[bot]]

/cc @zakkak (native-image)

[sberyozkin]

@madocx Can you consider experimenting with the Quarkus extension, see its https://quarkus.io/guides/security-webauthn description, it needs some updates, main one is that the tutorial code is now missing, but @FroMage put a lot of effort into it, it is based on Vert.x WebAuthn code, and it does compile in native. IMHO it would be nice to have this extension evolved a bit more.
Also note, prod quality OIDC providers will support WebAuthn.

[FroMage]

I'm sorry, I don't understand exactly what you're trying to do :(

[madocx]

No worries, that's my fault. After reviewing the documentation again realized I was misunderstanding the order of operations on the endpoints. Since /q/challenge isn't invoked until after /q/login or /q/register, we really don't have any need for a custom implementation as long as the URI is configurable.

[FroMage]

Yeah, the names are a bit confusing.

• /q/webauthn/login gets you a login challenge
• /q/webauthn/register gets you a registration challenge
• /q/webauthn/callback authenticates you, with a login or registration body. You can override this endpoint and implement it yourself with the help of WebAuthnSecurity

At the moment, you can't easily override the challenge endpoints, because they reimplement some of the Vert.x WebAuthn logic to bypass the lack of sessions (using cookies).

If you intend to override the /q/webauthn/callback endpoint (like we document you can do), then you don't need to customise any URI, you can place your endpoint where you want, since you're the ones calling them, Quarkus WebAuthn doesn't have to know where they are.

If you intend to override the /q/webauthn/register|login challenges, then you'll probably need that I expose their equivalents in WebAuthnSecurity to deal with the session cookies.

If you don't, and you just want them to be registered on different URIs, then that's a configuration option we need to add.

So, is this clearer? What do you want, then? :)

[madocx]

I was with you half way through, but then I got lost - probably because I don't understand the inner workings of the extension. regiseter/login are already exposed in WebAuthnSecurity from what I see in the source. Am I missing something about what you're suggesting? https://github.com/quarkusio/quarkus/blob/main/extensions/security-webauthn/runtime/src/main/java/io/quarkus/security/webauthn/WebAuthnSecurity.java

[FroMage]

Yeah, the names are confusing, I should have changed all that at the start.

The /q/webauthn/login endpoint gets you a challenge that you need on the client in order to call an authenticator, and then you trigger the login action by calling the /q/webauthn/login endpoint.

So, one is the challenge, followed by the action. The two challenges have separate endpoints, while the two actions share the same endpoint. By default.

WebAuthnSecurity.login is an override of the action, not the challenge. In case you want to have different actions, or customise what you do in the action. ATM there's no way to let you write custom challenges.