JWT validation logs no error

[FroMage]

I tried to reproduce the JWT guide but inadvertantly got a space in my config:

mp.jwt.verify.publickey.location=META-INF/resources/publicKey.pem 
mp.jwt.verify.issuer=https://quarkus.io/using-jwt-rbac 

Do you see it? Me neither. It got there while copy pasting it from https://quarkus.io/guides/security-jwt#setting-up-application-properties

As a result, no amount of fiddling on my part with passing a JWT token on my test led to anything than a 401. I lost hours assuming I generated my token wrong, and only after launching the debugger did I realise that it was validation that was bogus.

MpJwtValidator will catch the exception and forward it up in the Uni, but there were zero logs shown.

In my opinion, when configuration is wrong, which is the case here, because it's pointing at a file that does not exist (not with the space), we should get a SUPER VISIBLE error logged, because it's not the token that is wrong. It's the server config.

Note that I did get a second validation error once I fixed that, because mp.jwt.verify.issuer also had a space at the end. Now, as it turns out, unless it's meant to be a valid URI (spec says string or URI, so we can't validate), we can't verify that one because the space is a valid value, but it makes no sense at all.

I'd argue that we should just trim those property values to avoid surprises like those, especially if they don't result in logs.

And last, I suggest we add a logging property to JWT to log all token validation failures with the reason they failed. This is super useful for dev.

So, to recap:

• Validate the value of mp.jwt.verify.publickey.location and log if it does not exist
• Trim property values
• Add a logging property, such as quarkus.smallrye-jwt.log.claims.invalid to log all invalid claims on INFO with why they were invalid.

[FroMage]

Is it for you @sberyozkin?

[sberyozkin]

Hi @FroMage

lost hours assuming I generated my token wrong, and only after launching the debugger did I realise that it was validation that was bogus.

Oh dear :-). This must be fixed :-). We'll have a look, cheers

[FroMage]

Thanks a lot :)

[stuartwdouglas]

@sberyozkin is this still an issue?

[sberyozkin]

@stuartwdouglas yes, I'll resolve it with the update to smallrye-jwt 2.2.0, working on it now

[sberyozkin]

@FroMage Hi Stephane, so smallrye-jwt-2.2.0 does trim the location properties, and it also loads the classpath/file resources early, so the exception will be reported on the very startup. Re the logging property, both MpJwtValidator logs the exceptions in the debug mode, in general we try to avoid raising the level to avoid potential DOS attacks as recommended by @stuartwdouglas. But I promise you, there will be no more cases of users spending hours chasing the issue when they have mistyped the classpath/file resource location :-). (Note https locations are currently treated at at the request time but we will be optimizing it as well)
Thanks

[FroMage]

OK great, thanks!