Expose keyval timeouts for the OIDC integration via NIC's configmap & helm chart.

[jo-carter]

Is your feature request related to a problem? Please describe.
When extending expiration duration for ID Token beyond 1 hour, the default OIDC configuration will delete the ID token from associated keyval zone after exactly 1 hour.

Refresh of tokens (using refresh token) are not guaranteed to return ID Token (even if still active/expiration has not passed) - in the use-case that prompted this feature request - the IDP did not.

This effectively limited session duration to 1 hour before a re-login flow was required.

Describe the solution you'd like
Expose keyval timeouts found here as NIC configmap keys, and via helm values file key.

Describe alternatives you've considered
This issue was resolved in the short term by adjusting and manually overriding the oidc_common.conf file in the NIC container using a configmap injected via volume mount.

Other options included building custom NIC images, with that file adjusted with desired timeouts.

Both approaches are less convenient / require more ongoing maintaincence than configuration via configmap key / helm values file key.

[shaun-nx]

Hi @jo-carter

When it comes to files in /internal/configs/oidc we don't ever modify or configure those files directly in this project.
These files are maintained and updated in the nginx-openid-connect repo. Any time there is an update to these files, we will sync those changes with our repo.

That being said, we do understand that there are some times use-cases that require updates to these files.

There are two main ways to go about this:

1. Update the value you wish to update (in this case the timeout value for oidc_access_token) and then re-build the project.
   This, of course, will require you to maintain your own build of the ingress controller, which might not be ideal. This is usually why we would recommend the 2nd option.

2. We have a document here which details how use a custom OIDC configuration. I would advise looking at that document and see if that approach fits this purpose. This option does not require you to build a custom image