bug: openid-connect token introspection client_secret_basic, secret sent in header and body

[cortex35]

Current Behavior

Hello,
I'm experiencing an issue with the openid-connect plugin. I'm using client credentials with token introspection, but it doesn't seem to be working as expected.
When I enable Nginx logs, I notice that client_secret and client_id are being sent in the request body along with the token, even though the plugin is configured to use client_secret_basic (the basic auth is send as well).

I have debugged the conf object passed to the openidc.introspect(conf) method, and I couldn't identify any problematic values. Do you have any idea what might be causing this ?

My Authorization Server rejects the request if the client credentials are sent simultaneously in the Authorization header and the request body.

Is it possible that the issue lies within the OpenResty layer (resty.openidc)? It seems the introspect function is duplicating the credentials in the POST body even when the authentication method is explicitly set to Basic

Thanks.

Expected Behavior

When use "introspection_endpoint_auth_method": "client_secret_basic", only basic authentification is use ( without client info in body )

Error Logs

nginx logs :

[debug] openidc.lua:456: call_token_endpoint(): client_secret_basic: authorization header 'Basic xxxxxx'
[debug] openidc.lua:511: call_token_endpoint(): request body for introspection endpoint call: client_secret=xxxxxx&token=xxxxxxx&client_id=my.client.id
[debug] openidc.lua:430: openidc_configure_proxy(): openidc_configure_proxy : don't use http proxy
[info] client.lua:123: dns_parse(): dns resolve myauthserver, result: {"address":"xx.x.xxx.xxx","type":1,"class":1,"name":"myauthserver","ttl":3600,"section":1}, client: xx.x.xxx.xxx, server: _, request: "GET /apisix-openid-connect/v1/response/ok HTTP/1.1", host: "myapisix.com"
[info] resolver.lua:84: parse_domain(): parse addr: {"address":"xx.x.xxx.xxx","type":1,"class":1,"name":"myauthserver","section":1,"ttl":3600}, client: xx.x.xxx.xxx, server: _, request: "GET /apisix-openid-connect/v1/response/ok HTTP/1.1", host: "myapisix.com"
[info] resolver.lua:85: parse_domain(): resolver: ["xx.x.xxx.xxx","xx.x.xxx.xxx","xx.x.xxx.xxx"], client: xx.x.xxx.xxx, server: _, request: "GET /apisix-openid-connect/v1/response/ok HTTP/1.1", host: "myapisix.com"
[info] resolver.lua:86: parse_domain(): host: myauthserver, client: xx.x.xxx.xxx, server: _, request: "GET /apisix-openid-connect/v1/response/ok HTTP/1.1", host: "myapisix.com"
[info] resolver.lua:88: parse_domain(): dns resolver domain: myauthserver to xx.x.xxx.xxx, client: xx.x.xxx.xxx, server: _, request: "GET /apisix-openid-connect/v1/response/ok HTTP/1.1", host: "myapisix.com"
[debug] openidc.lua:529: call_token_endpoint(): introspection endpoint response: {"error":"invalid_client"}

conf object parameter in call "openidc.introspect(conf)"
{
"unauth_action": "auth",
"timeout": 3000,
"client_jwt_assertion_expires_in": 60,
"discovery": "https://myauthserver/.well-known/openid-configuration",
"renew_access_token_on_expiry": true,
"bearer_only": true,
"client_secret": "xxxxxxxx",
"use_pkce": false,
"introspection_interval": 0,
"introspection_endpoint_auth_method": "client_secret_basic",
"iat_slack": 120,
"client_id": "my.client.id",
"access_token_in_authorization_header": false,
"set_access_token_header": true,
"realm": "apisix",
"ssl_verify": "no",
"access_token_expires_leeway": 0,
"set_id_token_header": true,
"force_reauthorize": false,
"token_endpoint_auth_method": "client_secret_basic",
"use_nonce": false,
"set_refresh_token_header": false,
"revoke_tokens_on_logout": false,
"jwt_verification_cache_ignore": false,
"jwk_expires_in": 86400,
"accept_none_alg": false,
"logout_path": "/logout",
"accept_unsupported_alg": true,
"redirect_uri": "/apisix-openid-connect/v1/response/ok/.apisix/redirect",
"set_userinfo_header": true,
"scope": "openid profile email",
"_meta": {}
}

Steps to Reproduce

Here is my configuration:

curl http://localhost:9180/apisix/admin/routes/00000000000000021323
-H "X-API-KEY:$ADC_TOKEN" -X PUT -i -d '
{
"uri": "/apisix-openid-connect/*",
"name": "apisix-openid-connect",
"plugins": {
"openid-connect": {
"bearer_only": true,
"client_id": "my.client.id",
"client_secret": "xxxxxxxxx",
"discovery": "https://myauthserver/.well-known/openid-configuration",
"scope": "openid profile email",
"introspection_endpoint_auth_method": "client_secret_basic"
}
},
"upstream": {
"name": "server-api-test",
"nodes": [
{
"host": "server-api-test",
"port": 3003,
"weight": 100
}
],
"timeout": {
"connect": 60,
"send": 60,
"read": 60
}
}
}'

Environment

• APISIX version (run apisix version): 3.14
• Operating system (run uname -a): Debian 5.10.249-1
• OpenResty / Nginx version (run openresty -V or nginx -V): openresty/1.27.1.2
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info): 3.5.24
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[Baoyuantop]

The issue appears to be in the upstream lua-resty-openidc library. APISIX passes configuration directly to openidc.introspect() without manipulating credentials.

https://github.com/zmartzone/lua-resty-openidc/blob/v1.8.0/lib/resty/openidc.lua#L1789-L1811
The code above adds credentials repeatedly to the request body, causing authentication to fail.

Set introspection_endpoint_auth_method to client_secret_post in your APISIX plugin configuration. This avoids the duplicate because call_token_endpoint() doesn't add an Authorization header for client_secret_post, so the body credentials are the only copy — which is correct behavior for that auth method.
{
"introspection_endpoint_auth_method": "client_secret_post"
}

Awaiting confirmation from the upstream repository: zmartzone/lua-resty-openidc#556

[cortex35]

Thank you very much for the quick response and action.
Basic authentication was the method provided in my authorization server's documentation, I tested client_secret_post and it works perfectly—thanks, you solve my issue.
I'm keeping this open for tracking purposes regarding the client_secret_basic fix.

[kevinlzw]

Thanks for reporting this. I have included the related fix in #13649, and that PR now references this issue with Fixes #13085 so it should be closed automatically once the PR is merged.