Allow for registered clients to set client-specific expiry

[JoelGoh92]

Preflight Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

The expiry configuration currently contains a global setting for Dex token behaviour.

However, for a single organization using Dex, there can be apps that have different requirements towards such time windows, which can be non-negotiable, e.g. due to regulatory requirements. The limitation of a global setting means that client apps having such requirements are effectively blocked from using a single Dex provider as the IDP for their respective use case.

Proposed Solution

Allow for per-client opt-inexpiry settings. If this setting is not set on the static client, it fallbacks to the original global configuration.

This allows customised client use cases to be supported, and a central Dex provider to be used

Alternatives Considered

An alternative could be to spin up multiple Dex providers with different time window requirements within the organization, but it is costly to maintain, and difficult to reason about, when these should be utilising the same central provider.

Additional Information

No response

[nabokihms]

I think this is a great feature request, but it may be hard to implement because signing keys rotation and token expiration options are connected. Dex keep keys as long as there are tokens signed by the key.

Client settings can be changed dynamically, so the expiration parameters can. For each signing key Dex will need to track the lifespan of the last token signed by this key and decide whether to evict the key basing on this metric.

Yet still a good feature.