Azure AD authentication not working when access token verification is enabled.

[effusion]

Hello,

we currently face the issue of not getting Azure Authentication working with quarkus.oidc.authentication.verify-access-token set to true.

Our endpoint looks as follows:

@Path("/")
class IndexResource(val index: Template) {

    @GET
    @Produces(MediaType.TEXT_HTML)
    fun get(): TemplateInstance? {
        return index.instance()
    }
}

and the OIDC configuration like:

quarkus.http.auth.permission.root.enabled=true
quarkus.http.auth.permission.root.paths=/*
quarkus.http.auth.permission.root.policy=authenticated
quarkus.oidc.auth-server-url=https://login.microsoftonline.com/<tenant-id>/v2.0
quarkus.oidc.application-type=hybrid
quarkus.oidc.token.refresh-expired=true
quarkus.oidc.authentication.redirect-path=/signin
quarkus.oidc.authentication.restore-path-after-redirect=true
quarkus.http.auth.permission.callback.paths=/signin
quarkus.http.auth.permission.callback.policy=authenticated
quarkus.oidc.authentication.scopes=profile,email
quarkus.oidc.authentication.cookie-same-site=lax
quarkus.oidc.roles.role-claim-path=roles
quarkus.oidc.token-state-manager.split-tokens=true
quarkus.oidc.authentication.verify-access-token=true
quarkus.oidc.token.customizer-name=azure-access-token-customizer
quarkus.oidc.token.issuer=any
quarkus.oidc.token.audience=any

The main problem at the moment is that even if quarkus.oidc.token.audience is set to any, we always get an exception that the aud claim does not match the expected value. For the property quarkus.oidc.token.issuer the value any works. Azure gives out tokens with different claims for id and access token.

Thanks to @sberyozkin help, I also found out about the https://quarkus.io/guides/security-oidc-bearer-token-authentication#jose4j-validator to customize claim validation. Unfortunately, this does not prevent the token verification from failing.

Did anyone else face this issues?

[sberyozkin]

Thanks @effusion, let me check...

I'd like to clarify for everyone that what is described here, and which is what we briefly discussed with @effusion earlier, is the case where both Azure authorization code flow ID and access tokens have to be verified, with these two types of tokens having different issuer and audience claims.

The proposed plan has been to set both of these claims to any but compensate with the extra verification of these claims in a custom validator, depending on a token type.

[sberyozkin]

@effusion It would be great, you can put a breakpoint at https://github.com/quarkusio/quarkus/blob/main/extensions/oidc/runtime/src/main/java/io/quarkus/oidc/runtime/OidcProvider.java#L226 and see what happens, it will be called twice, once for ID token and once for the code flow access token

[effusion]

@sberyozkin, here are my findings from the debug session:
The variable always contains the value c81c4d29-cb5d-42f8-9a7d-dab0c020ac37 as if the property quarkus.oidc.token.audience does not get adequately loaded.

In the Screenshot, you can see that any is for issuers, but the value c81c4d29-cb5d-42f8-9a7d-dab0c020ac37 is for the audience.
The property was set to:
quarkus.oidc.token.audience=any

If i can debug further, just let me know where.

[sberyozkin]

@effusion Thanks, it feels like it is some kind of deployment issue, the c81c4d29-cb5d-42f8-9a7d-dab0c020ac37 you are seeing in the debug mode in the OidcTenantConfig.Token group can only be coming from application.properties, from quarkus.oidc.token.audience, so if you are still seeing c81c4d29-cb5d-42f8-9a7d-dab0c020ac37, despite resetting quarkus.oidc.token.audience to any, then it does look like you are seeing the stale configuration state.

Do you use env vars by any chance ?

[effusion]

We have an env file with a hardcoded audience value 😅. It works now with the list. I create the Josej4Validator to restrict the Issuer.

As an improvement, it would be nice if the issuer property is also a list like for audience.

[sberyozkin]

Hi @effusion , ok, glad you have got it working
I have been thinking of introducing a dedicated confg group specifically for code flow access tokens to support such cases easier, typically multiple issues implies different oidc tenants should be involved.

The fact both Azure tokens have different issuer and audience properties implies, that at least in theory, the AT is meant for the propagation 🙂.
I'll have a look later if listing multiple issuers may work
Thanks