Describe the bug
Given the configuration :
quarkus.oidc.auth-server-url=https://myauthtenant.eu.auth0.com/
On start-up Quarkus tries to access URL : https://myauthtenant.eu.auth0.com//.well-known/openid-configuration (see double //) which causes an exception
OIDC server is not available at the 'quarkus.oidc.auth-server-url' URL (...)
(...)
Cannot GET //.well-known/openid-configuration
Alternatively, when removing trailing slash:
quarkus.oidc.auth-server-url=https://myauthtenant.eu.auth0.com
an error is thrown
issuer validation failed: received [https://myauthtenant.eu.auth0.com/]
as the issuer field in the OIDC JSON has the trailing slash
"issuer": "https://myauthtenant.eu.auth0.com/",
I've tried adding
quarkus.oidc.introspection-path=.well-known/openid-configuration
quarkus.oidc.jwks-path=.well-known/jwks.json
with no effect
Expected behavior
Quarkus could be smart enough not to add another "/" before .well-known when the auth-server-url ends with trailing /
Actual behavior
Quarkus start up error
To Reproduce
Steps to reproduce the behavior:
Configuration
quarkus.oidc.auth-server-url=https://myauthtenant.eu.auth0.com
quarkus.oidc.introspection-path=.well-known/openid-configuration
quarkus.oidc.jwks-path=.well-known/jwks.json
quarkus.oidc.client-id=XXX
quarkus.oidc.credentials.secret=XXX
quarkus.oidc.application-type=web-app
quarkus.oidc.authentication.scopes=email,profile,roles
Screenshots
(If applicable, add screenshots to help explain your problem.)
Environment (please complete the following information):
uname -a or ver: java -version: Additional context
(Add any other context about the problem here.)
/cc @sberyozkin @pedroigor
Thanks, @gsmet. I was just about to comment :)
@sberyozkin It seems the suggestion from @piotrgwiazda makes sense.
However, I'm wondering if we should also have a quarkus.oidc.issuer property to specify the issuer. The reason being that there is no implicit relation between the root URL we use to fetch the discovery document and the issuer. It should work for most implementations (what may be fine for now) but may fail for others if they don't use the root URL as the issuer.
The problem of adding that property is that issuer verification is performed within the Vert.x OAuth library. So, I'm not sure if it would work without disabling issuer verification and doing it by ourselves. Or maybe there is some alternative in Vert.X OAuth to define the issuer (not the site).
@sberyozkin Sorry if I'm going to mix topics here ... But I'm also wondering whether or not we are verifying the issuer when validating tokens. I think the same question applies to the token's audience.
@pedroigor sure, I'll make sure we have an issue to get the issuer/audience/etc validated, VertxOAuth2 seems to validate the expiry, but not sure about the rest
@pedroigor I've just read the description again and the issuer is definitely validated.
@sberyozkin for bearer tokens too ?
@pedroigor don't know :-). yeah, I'll get an issue opened to confirm
@piotrgwiazda The problem is at the VertxOauth2 level and to fix it at the Quarkus level we'll need to disable the issuer validation done at the VertxOauth2 level because it compares it directly against the issuer endpoint address and introduce our own issuer property (which if set will indirectly disable the Vertx validation), and while a fix at the VertxOauth2 level would be good anyway (I'll open an issue), it would still make sense to introduce several expected claim values at the quarkus-oidc level as per @pedroigor suggestion
Now I think that the issuer in the JWT tokens will be there with a trailing slash as well. Validating bearer tokens and a web app might be worth checking as well.
@piotrgwiazda PR #5944 will offer an alternative where you'd just set an issuer as a quarkus.oidc.claims.issuer property which will disable the default Vertx Oauth2 issuer validation which only does a comparison based on the site URL. (FYI, Vertx OAuth2 fix for this issue has also been merged by Paulo) but going forward I think we will encourage the users to set the expected issuer, audience, etc directly as trhe quarkus properties.
CC @pedroigor
Thanks. That sounds like a good idea. The OIDC providers have these minor, painful differences in implementation.
@piotrgwiazda thanks, so we have this solution and with the VertxOauth2 update it will work OOB anyway, though with the merged PR you can also check the audience which would be a good idea, cheers
@piotrgwiazda FYI, the fix at the Vertx Auth level has also been backported to 3.8.5-SNAPSHOT branch by @pmlopes. If you can confirm it fixes it independently then it would be good,
Updated bom/runtime/pom.xml and do mvn clean install -DskipTests, thanks
@piotrgwiazda just checking, did you manage to get this work with Auth0?
@MrShish try change dependencies:
...
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-oidc</artifactId>
<exclusions>
<exclusion>
<groupId>io.vertx</groupId>
<artifactId>vertx-auth-oauth2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-auth-oauth2</artifactId>
<version>3.8.5</version>
</dependency>
...
and
quarkus.oidc.auth-server-url=https://YOUR_APP.auth0.com
without slash in the end.
@MrShish New released Quarkus 1.3.0.Final has already vertx-auth-oauth2 3.8.5 included.