OIDC: more flexible token forwarding configuration in SecurityPolicy

[rolandkool]

Currently, the SecurityPolicy does not support forwarding the ID token and using a different header name for the forwarded token. Our use case requires the forwarding of the ID token into a custom header. We can work around this through a custom Lua script that adds cookies to the DYNAMIC_METADATA and use a requestHeaderModifier in a HTTPRoute to add it to a header. However, it feels like this is something that the SecurityPolicy should be able to do as well.

For inspiration, check out how Gloo Gateway (the commercial 2.x is based on KGateway) is supporting this: https://docs.solo.io/gloo-edge/main/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/enterprise/options/extauth/v1/extauth.proto.sk/#headerconfiguration

Would be nice to have something similar in Envoy Gateway.

[zhaohuabing]

Depend on envoyproxy/envoy#15489

[zhaohuabing]

Hi @rolandkool Could you please elaborate your ID token use case so we can hopefully push this upstream?

[tvandinther]

In OIDC the ID token is the proof of identity for the system to which this identity is issued against. The audience (aud claim) is therefore a unique identifier of the system being logged in to. To be able to properly use an OIDC middleware, the audience needs to be verifiable to prevent token reuse attacks.

Access tokens do not inherently share this property with ID tokens. The audience for an access token is that of the OAuth2 resource server which is not defined explicitly in the spec to be that of the system you are logging in to as that is only defined in OIDC of which the ID token is created for. It can therefore not be expected that the audience of an access token will match the unique identifier of the system being logged in to.

An example of this is with Microsoft Entra ID, where performing an OAuth flow requesting openid and User.Read scopes returns both an ID token and an access token. In this example, the audience of the ID token is the UUID of the client and the audience of the access token is the UUID of the Microsoft Graph API.

In summary, these are two completely different tokens for completely different use cases and any systems using the OIDC middleware need to be able to be able to utilise the tokens independently.

[johnvox]

I do have same usecase for argocd for example. Forwarding IdToken make argo able to logging and perform claim validation over idtoken retreive by envoy.
It avoid duplicate oidc config and have a single login process at the gateway level.

[zhaohuabing]

@rolandkool @jynolen Currently, the id token cookie is forwarded to the upstream, and you can specify the cookie names via securitypolicy.spec.oidc.cookieNames. Can you use that cookie to get the id token?

[rolandkool]

Yes, like I mentioned in the description, there is a way to work around it using a Lua script to add cookies to dynamic metadata and then a request header modifier in the HTTPRoute to add it as an header. But it saves a lot of config if you could just add a single setting in the SecurityPolicy to add the id token to a configurable header name.

[johnvox]

Main issue right now is not envoygateway project itself.
Envoy oauth2 filter support only AccessToken for the moment (see https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/http/oauth2/filter.cc#L1197)

I'm working on a patch here envoyproxy/envoy#41863, to allow specify witch type of token you want to forward.

However my c++ skill are a bit rusty. In struggle with unittest for the moment.

[johnvox]

PR Ready for review waiting for reviewer. TY

[rolandkool]

@jynolen thanks for helping out with the patch. Would you be interested in extending the PR to also support forwarding the token to a customized header name instead of the standard Authorization header?

[tvandinther]

It would be particularly useful to be able to forward both the ID token and access token at the same time to 2 different and configurable headers. Even if we could opt to forward the ID token, in the proposed changes we would then lose the access token. They both have unique use cases which warrant having them both forwarded.

[johnvox]

@jynolen thanks for helping out with the patch. Would you be interested in extending the PR to also support forwarding the token to a customized header name instead of the standard Authorization header?

It would be particularly useful to be able to forward both the ID token and access token at the same time to 2 different and configurable headers. Even if we could opt to forward the ID token, in the proposed changes we would then lose the access token. They both have unique use cases which warrant having them both forwarded.

My 2c it's probably better to have another PR to add the feature as it change the first behaviour of options however good idea.

Because in fact in this cutstom header is only the token / prefix with bearer string etc. it's not "as trivial" as changing the value of Authorization