feat: Storage Backend for jwt cache

[iamasmith]

First read the README Would you be receptive to a merge request that enabled jwt caching to be shared amongst instances?

Describe the problem I have a deployment at work using vouch proxy alongside nginx as sidecars to one of my pods on Kubernetes. This works really well and in my app I use a group claim to provide a certain level of access to users configured in Okta and as such I can hand off to the team assignment to the correct groups to generate appropriate claims that my app can then just process via headers recevied.

I noticed when multiple instances of this configuration run, however, that the auth gets revoked depending upon the instance that the auth lands upon. This appears to be related to the jwt missing from cache that the existing client cookie presents.

It would seem, without doing more testing in code, that distributing the caching or allowing pull through from a shared persistent storage, might solve the problem but I would need to commit more time to it.

My question then, prior to committing time to this is would this be a feature that you would welcome and wish to include? I prefer to contribute upsteam rather than derive forks for such work.

wrt backend, Redis would be convenient for me but I'm willing to look at another if that works out and seems useful.

During a cursary inspection this code appears to be responsible for bouncing connections not cached but the enhancement would be in the caching code of course

https://github.com/vouch/vouch-proxy/blob/ad2e9ac8ad03e7d22cdbb44abc47c74ad046071a/handlers/validate.go#L36-L40

Expected behavior Each pod can pass the check for the jwt cache presented by the client.

Desktop (please complete the following information): n/a

Smartphone (please complete the following information): n/a

Additional context Add any other context about the problem here.

[iamasmith]

Re-examined some of the code, this FR is not ready and -slightly- wholly inaccurate. I'll dig into this issue further before considering reopening.

[iamasmith]

Thought I would report back on this for anybody missing the same thing wrt multiple instances. Check the sample config files, some values are randomly generated by vouch if not provided and these need to be provided consistently for all instances of the service. In my case these were session.key and jwt.secret which I now generate as 32 random bytes in Terraform, base64 encode that to 44 bytes and provide that in the config.yaml as a Kubernetes secret shared between each pod. The feature originally discussed is not required.