[quarkus-oidc] Wrong client id sent to introspection endpoint when introspection credentials are given

[DCCSKrezovic]

Describe the bug

This has been mentioned by a colleague that's using the same OIDC provider as I am

When setting the form field "client_id" in the introspection call, it must match the introspection_client_id introduced in quarkus 2.12 (see pr #26917 (comment))

Otherwise, the following error is shown:

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

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.12.0.CR1

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

No response

Additional information

No response

[quarkus-bot]

/cc @pedroigor, @sberyozkin

[sberyozkin]

@DCCSKrezovic I'm not sure about it. This rule that your provider is implementing does not look correct to me. The whole concept of using a custom authentication for the token introspection (avoiding the client id) is non standard, but in any case if the client id is present then I see no problems with your provider ignoring this field in the introspection request since it has no impact on the actual introspection authentication. We can imagine that other users would expect that the client id is also provided as per the standard introspection request spec even if the basic authentication is configured. With the custom authentication the concept of the Quarkus endpoint being a confidential OIDC client with a specific id has not gone away.

Or drop the client id from the configuration completely - it is optional for the bearer token authentication.

[DCCSKrezovic]

HI @sberyozkin

According to the spec, only the token and token_type_hint are defined and expected. Everything else is optional and OIDC provider specific. Can providing the client id be made into a turnable?

https://www.rfc-editor.org/rfc/rfc7662#page-4

[mqs24d]

@sberyozkin the oidc provider we are using defines two clients:

• one client which is for token/userinfo retrieval
• and a second one just for the introspection (so basically the custom authentication is just a separate client-id/client-secret)
  So when the introspection is done the oidc provider expects the client id of the introspection client. I also don't know why our provider is doing that.

[DCCSKrezovic]

@mqs24d the rule is quite simple:

• You can use authorization code flow only. JWKS check is sufficient, so no need for introspection.
• You can use client credential grant only. Auth code flow not needed in this case, but Introspection is required. Hence, another kind of credentials. And you can switch the order from one to the other as you like.

[sberyozkin]

@DCCSKrezovic Hi, as far as the other optional parameters are concerned they are not really about the client authentication, but about some extra properties related to the actual introspection input. The client authentication implied there refers to the OIDC client.

Can providing the client id be made into a turnable?

I guess so, I can just add one more property to the IntrospectionCredentials config group to skip it if required

[DCCSKrezovic]

@DCCSKrezovic Hi, as far as the other optional parameters are concerned they are not really about the client authentication, but about some extra properties related to the actual introspection input. The client authentication implied there refers to the OIDC client.

Can providing the client id be made into a turnable?

I guess so, I can just add one more property to the IntrospectionCredentials config group to skip it if required

Please, if not a big deal, and thank you very much.

[sberyozkin]

No problems, we'd like to support various OIDC provider setups, whenever possible

[DCCSKrezovic]

Thanks for quick fix!