Strange token generation/authentication behavior (oidc client)

[IvanPuntev]

Describe the bug

Regarding https://github.com/quarkusio/quarkus/issues/40905

If the assertion property is set to true and secret is also provided, quarkus oidc client will try to use basic authentication header instead of the assertion form parameter. It generates opaque token instead of jwt bearer.

!!! If the secret is removed then the jwt bearer auth is ok.

Maybe when assertion is used then the secret just needs to be ignored if provided?

quarkus.oidc-client.salesforce.auth-server-url= quarkus.oidc-client.salesforce.client-id= quarkus.oidc-client.salesforce.credentials.jwt.key= quarkus.oidc-client.salesforce.credentials.jwt.audience= quarkus.oidc-client.salesforce.credentials.jwt.subject= quarkus.oidc-client.salesforce.credentials.jwt.issuer= quarkus.oidc-client.salesforce.credentials.jwt.lifespan=3600 quarkus.oidc-client.salesforce.grant.type=jwt quarkus.oidc-client.salesforce.credentials.jwt.assertion=true #quarkus.oidc-client.salesforce.credentials.jwt.secret= quarkus.oidc-client.salesforce.token-path=/services/oauth2/token quarkus.oidc-client.salesforce.discovery-enabled=false

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

3.13.0

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

No response

Additional information

No response

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@IvanPuntev It can't really generate an opaque token. Are you sure this opaque token you are seeing is produced by OIDC client ?

Also, do you mean you have both quarkus.oidc-client.salesforce.credentials.jwt.key=... and quarkus.oidc-client.salesforce.credentials.jwt.secret= set at the same time ?

My guess is that when jwt.secret is set, it causes a client_secret_jwt authentication, see https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication, and Salesforces returns an opaque access token as a result...

Maybe when assertion is used then the secret just needs to be ignored if provided?

We should fail the start up if multiple JWT key material options are set at the same time...

[sberyozkin]

The link to the OIDC spec is only relevant for showing how the token is signed in this case, it is not meant to be an authentication token since you are choosing to use a JWT bearer authorization grant

[IvanPuntev]

@sberyozkin The opaque token is returned from Salesforce indeed. I have both key and secret set. Every property I used is in the description.

[sberyozkin]

@IvanPuntev Thanks, so this configuration should cause a startup failure to avoid the confusions, I'll have a look