api(oidc): Allow override of all OIDC CookieNames

[coro]

What type of PR is this?

What this PR does / why we need it:

Allows for:

• removal of the internal OAuthFilter cookies before forwarding the request to upstream
• migrations from other OIDC providers with preemptible cookie names

Which issue(s) this PR fixes:

Fixes #5152

Release Notes: No

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.22%. Comparing base (2f81596) to head (f6f3acc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5655      +/-   ##
==========================================
- Coverage   65.28%   65.22%   -0.07%     
==========================================
  Files         213      213              
  Lines       34132    34132              
==========================================
- Hits        22282    22261      -21     
- Misses      10515    10531      +16     
- Partials     1335     1340       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zhaohuabing]

@coro Thanks for picking this up. Could you please also add CodeVerifier cookie?

reference: envoyproxy/envoy#37849

[zhaohuabing]

A second thought, we probably shouldn't expose these cookies to the API - not like the ID and Access tokens, they're some trivial internal implementation details.

I'd rather remove these cookies by default in the OAuth2 filter.

[coro]

@zhaohuabing so just to confirm, you'd like no configurability for any of the Oauth* cookie names? But configurability is OK for RefreshToken-* and CodeVerifier-*?

[zhaohuabing]

@coro sorry for the confusion. I meant that the existing AccessToken and IDToken cookies are needed in the API because some backend applications may need them for auth purposes/getting user identity, but all the other cookies should not be exposed to the user-facing API and just be deleted before forwarding the request to the Backend applications. We should fix this in the Envoy OAuth2 filter.

Does this make sense?