Travis Glenn Hansen

Ah I see, currently no, the expectation if that value is set is that it's a full uri, not just a path. You could create distinct tokens for each domain...

Good point. I didn’t realize those never got documented properly. The `CONFIG_` are required for everything. The issuer/cookie/session stuff is currently only for oauth/oidc use. Having said that, the deployment...

Here's the breakdown: - `EAS_CONFIG_TOKEN_SIGN_SECRET` - used to check the signature of `config_tokens` (ensure operators cannot just created arbitrary config tokens to be used by the service) - `EAS_CONFIG_TOKEN_ENCRYPT_SECRET` -...

Yeah, but you should not need a new deployment per app if that concept was not clear. It's designed to have a single installation to handle many many configs/apps.

Sorry, been super busy. So the key is cached yes and it's based on the header sent by the provider. In short it will 'just work'.

https://github.com/auth0/node-jwks-rsa/blob/master/EXAMPLES.md#caching I want to say that doc has changed from what it was the last time I looked at it so it may be slightly different. The documented behavior there...

Yeah fair enough. The context of that comment was more about multiple apps within a single cluster. I can look into making the value of that property a handlebars template.

You can use server-side tokens: https://github.com/travisghansen/external-auth-server/blob/master/CONFIG_TOKENS.md#server-side-tokens I think it would be pretty easy to add additional store types/adapters for either or both of k8s secrets and vault.

Reading through some docs and rfcs I think it can be removed. It appears to me that field in the id token is not necessarily common (may be a keycloak-centric...

Can you test using the `next` image tag? It’s a mutable tag so make sure your cluster pulls the newest revision.