help request: openid-connect plugin X-Id-Token header contains only payload part of JWT

[TheManWhoStaresAtCode]

Description

When configuring the openid-connect plugin to provide the respective Id-Token in a header using the set_id_token_header property a X-Id-Token header is set. However, to my surprise the header contains not the whole Id-Token (i.e. header, payload and signature if present) but rather just the payload part of that JWT. This leads to two questions

1. Is this the intended behavior, that the header contains only the payload part of the ID-JWT. In that case I suggest to update the parameter description accordingly.
2. I need the actual ID-Token for my use-case. Is there a way to obtain it via a header or similar approach, once the openid-connect plugin has processed the incoming request?

Best regards

Environment

• APISIX version (run apisix version): 3.11.0
• Operating system (run uname -a): Linux apisix-745bddfc75-frbx6 5.15.0-1087-azure test: check the service config with json schema after fetched it form etcd. #96-Ubuntu SMP Fri Mar 28 20:31:27 UTC 2025 x86_64 GNU/Linux
• OpenResty / Nginx version (run openresty -V or nginx -V): openresty/1.25.3.2

[Baoyuantop]

For most scenarios, it is more practical and secure only to pass the payload content. Downstream services do not need to handle JWT signature verification, reducing implementation complexity.

I need the actual ID-Token for my use-case.

Can you describe this requirement in detail?

[TheManWhoStaresAtCode]

In our case we need to send the whole Id-token to our authorization server in order to exchange it for another token. The request to this endpoint obviously fails if only the token payload is provided. I'm aware that this use-case might be rather special and rare but still would love to get support for it here.

In the mean time I also found this issue where also the complete id-token is required based on another use-case. From my point of view the suggested implementation solves our issue. Therefore a colleague of mine provided this PR.

[Baoyuantop]

Got it. I'll take the time to review this PR.

[bzp2010]

I do not understand the reasonableness of this requirement.

If you use bearer_only = true, that means that anything related to token generation is handled outside the gateway, whether it's token generation or token rotation, and the gateway will always only validate it and decide if the traffic should go through or not.

If you use bearer_only = false, that means APISIX will use sessions to store authentication information and passthrough access_token/id_token to the backend. if the information in those sessions is outdated, it first tries to refresh the cached access_tokens using refresh_token token, and if it succeeds, the user does not feel the interruption; if the refresh fails, it jumps to the IDP and asks the user to re-authenticate.
This is the intended design, and in this model it seems that the user shouldn't and doesn't need to get the original value of the token whenever it is available (and passing it upstream seems to lack justification), and the token expiration date will be maintained by the gateway and transparent to the downstream.

You'll need to do more to justify it broadly, the "my organization needs it" rationale doesn't seem to be general enough to justify such a security-related change.