You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a successful login on my IdP, it returns access, id and refresh tokens. However, with the above configuration, Quarkus fails to verify the access token:
2024-04-11 07:15:54,001 DEBUG [io.qua.oid.run.OidcProvider] (vert.x-eventloop-thread-3) Verification of the token issued to client myclient has failed: Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: JWK with kid 'mykid' is not available): JsonWebSignature{"alg":"RS256","kid":"mykid"}->....
Expected behavior
Quarkus does not verify the access token, since I'm not actually using it in the application code (is it used by OIDC beans?).
OR
Quarkus verifies the token using the correct JWKS (which differs between access and ID tokens, see below).
Actual behavior
If I specify
quarkus.oidc.discovery-enabled=true
without quarkus.oidc.jwks-path, then Quarkus fails to validate the access token:
2024-04-11 07:27:12,076 DEBUG [io.qua.oid.run.OidcProvider] (vert.x-eventloop-thread-2) Verification of
the token issued to client my_client_id has failed: Unable to process JOSE object (cause:
org.jose4j.lang.UnresolvableKeyException: JWK with kid 'my_access_token_kid' is not available):
JsonWebSignature{"alg":"RS256","kid":"my_access_token_kid","pi.atm":"2w9k"}->...
2024-04-11 07:27:12,076 DEBUG [io.qua.oid.run.OidcProvider] (vert.x-eventloop-thread-2) Verification of
the token issued to client my_client_id has failed: Unable to process JOSE object (cause:
org.jose4j.lang.UnresolvableKeyException: JWK with kid 'my_id_token_kid' is not available):
JsonWebSignature{"alg":"RS256","kid":"my_id_token_kid","pi.atm":"2w9k"}->...
Relative path or absolute URL of the OIDC JSON Web Key Set (JWKS) endpoint which returns a JSON Web Key Verification Set. This property should be set if OIDC discovery is disabled and the local JWT verification is required. This property is ignored if the discovery is enabled.
How to Reproduce?
No response
Output of uname -a or ver
No response
Output of java -version
21
Quarkus version or git rev
3.9.0
Build tool (ie. output of mvnw --version or gradlew --version)
mvnw
Additional information
PingFederate provides JWKs on different endpoints for ID and access token:
For ID tokens they are all provided through the discovery endpoint (.well-known/openid-configuration/jwks_uri).
For access tokens, the key is instead exposed on an endpoint specific for the given OAuth client.
(This may make sense, since the discovery endpoint is part of OIDC, not OAuth 2.0.)
The text was updated successfully, but these errors were encountered:
Describe the bug
Since Quarkus 3.9.0, with the enforced access token verification, my applications no longer work with PingFederate IdP.
I have:
After a successful login on my IdP, it returns access, id and refresh tokens. However, with the above configuration, Quarkus fails to verify the access token:
Expected behavior
Quarkus does not verify the access token, since I'm not actually using it in the application code (is it used by OIDC beans?).
OR
Quarkus verifies the token using the correct JWKS (which differs between access and ID tokens, see below).
Actual behavior
If I specify
quarkus.oidc.discovery-enabled=true
without
quarkus.oidc.jwks-path
, then Quarkus fails to validate the access token:If I also add the jwks path:
then Quarkus fails to validate the ID token:
This also contradicts what the documentation says about
quarkus.oidc.jwks-path
:How to Reproduce?
No response
Output of
uname -a
orver
No response
Output of
java -version
21
Quarkus version or git rev
3.9.0
Build tool (ie. output of
mvnw --version
orgradlew --version
)mvnw
Additional information
PingFederate provides JWKs on different endpoints for ID and access token:
.well-known/openid-configuration
/jwks_uri
).(This may make sense, since the discovery endpoint is part of OIDC, not OAuth 2.0.)
The text was updated successfully, but these errors were encountered: