Quarkus OIDC does not work with Auth0

[piotrgwiazda]

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:

1. Create a free Auth0 tenant
2. Configure Quarkus as in https://quarkus.io/guides/security-openid-connect-web-authentication
3. Configure properties to point to Auth0
4. Start app

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):

• Output of uname -a or ver:
• Output of java -version:
• GraalVM version (if different from Java):
• Quarkus version or git rev:

Additional context
(Add any other context about the problem here.)

[gsmet]

/cc @sberyozkin @pedroigor

[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).

[pedroigor]

@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.

[sberyozkin]

@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

[sberyozkin]

@pedroigor I've just read the description again and the issuer is definitely validated.

[pedroigor]

@sberyozkin for bearer tokens too ?

[sberyozkin]

@pedroigor don't know :-). yeah, I'll get an issue opened to confirm

[sberyozkin]

@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

[piotrgwiazda]

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.