luarx opened a new issue, #13615:
URL: https://github.com/apache/apisix/issues/13615
### Description
## Summary
The `openid-connect` plugin currently exposes the ID token via the
`X-ID-Token` header, which
contains `base64(JSON(decoded_claims))`. This representation carries **no
cryptographic
signature** and cannot be verified by downstream services.
## Problem
Downstream services that need to verify the identity of the caller cannot
use `X-ID-Token`
for this purpose — the token is already decoded and stripped of its
signature. The only way
to cryptographically verify the caller's identity is to have access to the
original
RS256-signed JWT from the identity provider, verifiable against the
provider's JWKS endpoint.
## Proposed Solution
enabled, forwards the raw signed ID token JWT to upstream via the
`X-Enc-ID-Token` request
header.
Key design points:
- The header is cleared at rewrite entry to prevent client-supplied values
from bleeding
through.
- When `session_contents` is explicitly restricted by the user, the plugin
automatically
ensures `enc_id_token` is included so the raw JWT is persisted in the
session by
lua-resty-openidc.
- Only available in the full OIDC session flow (not in
bearer/introspection path).
## Use Case
A backend service sits behind an APISIX route protected by the
`openid-connect` plugin. The
service reads `X-Enc-ID-Token`, verifies the RS256 signature against the
identity provider's
JWKS endpoint, and extracts claims to enforce access control (e.g.
restricting access to
users from a specific domain).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
