Authorization code flow with OIDCProviderTokenEndpointAuth client_secret_basic not working

[samueldc]

Hi everyone,
I'm trying to use mod_auth_openidc against a OAuth2 provider using authorization code flow.
Here's my httpd configuration:

<IfModule mod_auth_openidc.c>
    OIDCScope "openid"
    OIDCResponseType "code"
    OIDCResponseMode query
    OIDCRedirectURI http://localhost2/otrs/redirect_uri
    OIDCProviderIssuer https://sepop-login-cidadao-tes.camara.leg.br
    OIDCProviderAuthorizationEndpoint https://sepop-login-cidadao-tes.camara.leg.br/oauth/authorize
    OIDCProviderTokenEndpoint https://sepop-login-cidadao-tes.camara.leg.br/oauth/token
    #OIDCProviderTokenEndpointAuth client_secret_post
    #OIDCProviderUserInfoEndpoint https://sepop-login-cidadao-tes.camara.leg.br/api/infoconta
    OIDCClientID ****
    OIDCClientSecret ****
    OIDCCryptoPassphrase ****
</IfModule>

<Location /otrs>
    AuthType openid-connect
    Require valid-user
</Location>

After login, I'm getting the following response:

Error:

OpenID Connect Provider error: Error in handling response type.

Here are the httpd log:

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.22.0.3. Set the 'ServerName' directive globally to suppress this message
AH00558: /opt/: Could not reliably determine the server's fully qualified domain name, using 172.22.0.3. Set the 'ServerName' directive globally to suppress this message
[Tue Mar 14 12:31:53.767867 2023] [auth_openidc:warn] [pid 35] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCRedirectURI SHOULD be "https" for security reasons (moreover: some Providers may reject non-HTTPS URLs)
[Tue Mar 14 12:31:53.777361 2023] [mpm_prefork:notice] [pid 35] AH00163: Apache/2.4.54 (Unix) mod_perl/2.0.11 Perl/v5.32.1 configured -- resuming normal operations
[Tue Mar 14 12:31:53.780392 2023] [core:notice] [pid 35] AH00094: Command line: '/opt/ -D FOREGROUND'
172.22.0.1 - - [14/Mar/2023:12:32:11 +0000] "GET /otrs/ HTTP/1.1" 302 486
[Tue Mar 14 12:32:16.958505 2023] [auth_openidc:error] [pid 41] [client 172.22.0.1:58200] oidc_proto_validate_code_response: requested flow is "code" but no "id_token" parameter found in the code response
[Tue Mar 14 12:32:16.958575 2023] [auth_openidc:error] [pid 41] [client 172.22.0.1:58200] oidc_proto_resolve_code_and_validate_response: code response validation failed
172.22.0.1 - "" [14/Mar/2023:12:32:16 +0000] "GET /otrs/redirect_uri?code=RUKMX6&state=fRAxIDiBt49ao-jOPXGsK9vD7ms HTTP/1.1" 200 335

Having a look at specs here, looks like the provider response is correct with code and state for response type code.

The redirect from provider to the client looks like this:

Request URL: http://localhost2/otrs/redirect_uri?code=82MgZx&state=ids3FmUl87bY_p9JVDCYKcMWxIw
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:80
Referrer Policy: strict-origin-when-cross-origin
Connection: Keep-Alive
Content-Length: 335
Content-Type: text/html
Date: Tue, 14 Mar 2023 13:24:32 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.54 (Unix) mod_perl/2.0.11 Perl/v5.32.1
Set-Cookie: mod_auth_openidc_state_ids3FmUl87bY_p9JVDCYKcMWxIw=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Domain=localhost2; HttpOnly
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7,es;q=0.6,gl;q=0.5
Cache-Control: max-age=0
Connection: keep-alive
Cookie: mod_auth_openidc_state_ids3FmUl87bY_p9JVDCYKcMWxIw=zF_bHru22ZAjodiG.3XFt0Wq4lxnbuRC2D5cE-_dzeXVBDODM7RwAVp75tUCgtay_IEqYl394PXw400uyIBKpVN3vHu4KfJkq4tcBukPt4bksuoIfm2bZcMNSaPqOJSDe7y95kGLipxxVRpNJee5Vo6aALIkpoYC_lUHJfvyWBPmBKV2y3EnYTweCfruEcH7-N_VnfBeHrWiyXyg2tJt1xZj3QGcwNsWkJDJxiJHf4CSRxLrN9P6I8eFqvy8z1RnJmgHDuAj57vo-ubD8g7Qp8lN5gVs4AUlgoIMCkiRj51LZxth24NFHCnR8UEdBzRoHp7rJKTs-otZ-3Zdce0PF2taSG5u-LxsHfcJa4l4Z_r7jLOIGCTC2sZIF6DW_i9zRHZSRNiDhMZUbtsiF3uoAXflmI8vDW8rPP8-uAvYE8ME_iIqdXLY.ugXZ3kivF6YQw-zXWkjK5w
Host: localhost2
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36

So I think the cookie domain is not the problem.

Any help will be appreciated.

[samueldc]

Looks like mod_auth_openidc code flow does not work with OIDCProviderTokenEndpointAuth client_secret_basic. If I change to OIDCProviderTokenEndpointAuth client_secret_post I got another error (401 unauthorized), because my provider does not support this client authentication method. Any chances to fix this?

[samueldc]

Using libapache2-mod-auth-openidc/stable,now 2.4.9.4-0+deb11u1 amd64 [installed].

[zandbelt]

this line in your log:

[Tue Mar 14 12:32:16.958505 2023] [auth_openidc:error] [pid 41] [client 172.22.0.1:58200] oidc_proto_validate_code_response: requested flow is "code" but no "id_token" parameter found in the code response

says that your Provider is not returning and "id_token" so it seems it is not an OpenID Connect provider, or your Provider's config for mod_auth_openidc has not enabled it as an OpenID Connect client

[samueldc]

Hi @zandbelt,

Thank you for replying. But reading the specs, looks like the response is correct when using flow (response_type) code:

https://openid.net/specs/openid-connect-core-1_0.html#codeExample

After that the client could exchange the code for a access_token using another post request and grant_type=authorization_code.

I thought an id_token was only supposed to be returned by the provider when using any of the id_token response_type. Am I not right?

[zandbelt]

no, that's not correct

[samueldc]

Sorry. After reading a little more, now I see the provider, since it's a OAuth2 Provider, is not required to include the id_token in the response. That's a Openid Connect spec only:

3.1.3.3. Successful Token Response
After receiving and validating a valid and authorized Token Request from the Client, the Authorization Server returns a successful response that includes an ID Token and an Access Token. The parameters in the successful response are defined in Section 4.1.4 of OAuth 2.0 [RFC6749]. The response uses the application/json media type.

The OAuth 2.0 token_type response parameter value MUST be Bearer, as specified in OAuth 2.0 Bearer Token Usage [RFC6750], unless another Token Type has been negotiated with the Client. Servers SHOULD support the Bearer Token Type; use of other Token Types is outside the scope of this specification.

In addition to the response parameters specified by OAuth 2.0, the following parameters MUST be included in the response:

id_token
ID Token value associated with the authenticated session.

Sorry to bother. Marking this question as solved.

Thanks!

[MonroeLarkzvg]

The error message "OpenID Connect Provider error: Error in handling response type" suggests that there is a problem with the response type received from the provider. Looking at the logs, it seems that the requested flow is "code" but no "id_token" parameter is found in the code response, which causes the code response validation to fail.

One possible reason for this error could be a misconfiguration in the httpd configuration. For example, the OIDCRedirectURI is configured to use "http" instead of "https", which could be rejected by some providers for security reasons.

You may want to double-check your configuration and ensure that all required parameters are set correctly, including the "OIDCClientID" and "OIDCClientSecret". Also, make sure that the "OIDCProviderIssuer" and "OIDCProviderAuthorizationEndpoint" are correct.

Additionally, you can try enabling debug logging to get more detailed information about the error. This can be done by setting "OIDCLogLevel debug" in the httpd configuration.

I hope this helps! Let me know if you have any other questions.