ayoho
commented
2 months ago Thanks for opening an issue, @kiefinger. The authentication being performed with the token endpoint is strictly authentication of the OAuth client, not another entity. Both the OAuth and OpenID Connect specifications always speak in terms of the client interacting with the token endpoint. Section 3.1.3.1 (Token Request) of the OpenID Connect specification says
If the Client is a Confidential Client, then it MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as described in Section 9.
Section 9 (Client Authentication) says this for the client_secret_basic authentication method:
Clients that have received a client_secret value from the Authorization Server authenticate with the Authorization Server in accordance with Section 2.3.1 of OAuth 2.0 [RFC6749] using the HTTP Basic authentication scheme.
And following on to Section 2.3.1 of the OAuth spec, that section starts with
Clients in possession of a client password MAY use the HTTP Basic authentication scheme as defined in [RFC2617] to authenticate with the authorization server. The client identifier is encoded using the "application/x-www-form-urlencoded" encoding algorithm per Appendix B, and the encoded value is used as the username; the client password is encoded using the same algorithm and used as the password. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.
I'm not aware of any OpenID Connect Providers that authenticate token endpoint requests using any credentials other than those issued to or associated with the OAuth client initiating the token request.
The openidConnectClient configuation for OAuth should be equipted with two new parameter to provide user and password for Basic Authentication if tokenEndpointAuthMethod="basic". instead of using clientId and clientSecret.
Currently the the Basic Authentication to access the token endpoint is computed from the clientId (as user) and the clientSecret (as password). But this implies that the user name used for basic authentication is the same as the ClientId. But this a curious assumption.
The user could be a technical user where the name is not the same as the clientId. (Of course this is exactly the case in my current situation, where this is currently a blocking issue)
In code the com.ibm.ws.security.openidconnect.clients.common.AuthorizationCodeHandler instantiates a tokenRequestBuilder in the method by using the clientId and the clientConfig.getClientSecret(). This method should use new parameter instead.