Issues in verifying signature of bearer token generated for Azure AD

[effusion]

Describe the bug

Hello,
We tried to update the Quarkus BOM version from 3.8.3 to 3.9.5/3.10.0 and now get an error when logging in with Azure OIDC.

Expected behavior

The update of the BOM version should not break OIDC Authentication, and logging should be possible.

Actual behavior

The Azure login page is shown with a password prompt and 2FA when opening the app URL. After entering the 2FA code, the App responds with a 401. The following error is shown in the log:
ID token verification has failed: JWT rejected due to invalid signature. Additional details: [[9] Invalid JWS Signature: .....
We did not change any properties. Everything works with Version 3.8.3.

How to Reproduce?

1. Setup an OIDC App registration in Azure (Scopes, Redirects, Permission)
2. Configure the OIDC properties in the application.properties files. (See attached properties)
3. Start the App
4. Navigate to http://localhost:8080
5. Login with the Azure credentials

Output of uname -a or ver

Darwin ultima-thule.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk version "21.0.1" 2023-10-17 LTS OpenJDK Runtime Environment Zulu21.30+15-CA (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Zulu21.30+15-CA (build 21.0.1+12-LTS, mixed mode, sharing)

Quarkus version or git rev

3.9.5, 3.10.0

Build tool (ie. output of mvnw --version or gradlew --version)

------------------------------------------------------------ Gradle 8.7 ------------------------------------------------------------ Build time: 2024-03-22 15:52:46 UTC Revision: 650af14d7653aa949fce5e886e685efc9cf97c10 Kotlin: 1.9.22 Groovy: 3.0.17 Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023 JVM: 21.0.1 (Azul Systems, Inc. 21.0.1+12-LTS) OS: Mac OS X 14.4.1 aarch64

Additional information

Current app configuration.

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/<tenante-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-bot]

/cc @geoand (kotlin), @pedroigor (bearer-token), @sberyozkin (bearer-token)

[sberyozkin]

Hi @effusion AFAIK, nothing related to the signature verification process has changed.

Can you set up a test Azure account that I can use (in another issue closed just today it was confirmed it was working with Entra ID), you can forward the link to me at sbiarozk at redhat com or ping privately at zulip if you'd like, and CC to someone else ?

[sberyozkin]

@effusion Not sure if it is relevant, but there are some cases with Azure where the JWT token headers have to be preprocessed, which is achieved with https://github.com/quarkusio/quarkus/blob/main/integration-tests/oidc-wiremock/src/main/resources/application.properties#L179

You don't even have to share a test account link with me, but if you can share a test token whose signature is reported to be invalid and share a link to the test public JsonWebKkey set which contains the verification key then I'll test it

[effusion]

Hi @sberyozkin, I can provide you with an invalid token, but I need to figure out how to provide the public JsonWebKey.
Regarding the customizer, why would I need that? It all works fine with version 3.8.3.

I'll get back to you as soon as I have everything.

[sberyozkin]

@effusion Hi,

but I need to figure out how to provide the public JsonWebKey.

It is in /.well-known/openid-configuration, append it to your tenant address, and check jwks_uri, it will return a JSON array with each key having a kid or may be x5t or x5t#S256 property, your token headers will also have one of these properties, so find the matching JWK key and let me test this invalid token :-)

I'm not sure yet about the customizer, but something might have changed on the Azure end...Let's see what my test will show

[effusion]

@sberyozkin
Hi Sergey,

I just sent you a mail containing the info to your RedHat mail address, which is also the password for the zip file.

[sberyozkin]

Thanks @effusion, my tests show adding a customizer (the token header preprocessor) resolve the problem. It looks like Azure is changing the way it issues tokens depending on some factors

[sberyozkin]

I'll need to improve on the error message to make it clear that a code flow access token and not ID token verification which is failing