OIDC clustering

[B]

On Friday, July 17th, 2026 at 1:19 PM, Scott Cantor via users <users at shibboleth.net> wrote:

> 
> > On Jul 17, 2026, at 12:33 PM, B via users <users at shibboleth.net> wrote:
> >
> > What's the recommended way to configure a multi-node deployment to ensure that an OIDC RP's back-channel calls to /idp/profile/oidc/token and /idp/profile/oidc/userinfo succeed, regardless of which node the user authenticated to?
> 
> We default to that for the most part using the existing secret key management to self-encrypt data, other than use cases like revocation (or if you really want to be struct with replay prevention).

But that doesn't apply to attributes for claims, where the data stays on the node, correct?

> 
> The real problem is testing, the inability to route requests from RPs to non-production systems for validation. That requires a ton of fancy load balancer scripting, but all I could do/did was extend the original code to add a "prefixing" feature so that codes and tokens can be issued with prefixes that can serve to identify them later for special handling.
> 
> In practice the fact that there are 687 different ways to pass tokens around in requests makes it very hard, if not impossible to do that. My perspective is this fact makes back-channel protocols unsupportable. YMMV of course.
> 

Yes.  For example, a request to /idp/profile/oidc/token could be a POST, and now the load balancer has to inspect the body, if it can even do that, to find the code and look at the prefix to decide how to route it.

Understood about back-channel protocols, testing and multi-node deployments.

> > Can this be done via idp.artifact.StorageService with the JDBC storage service?
> 
> Artifacts are a SAML feature, that property isn't relevant (a lot of early properties don't have "saml" in them due to history).

I don't see attributes included as part of session storage.  Is there a way to specify a non-default storage service for them?

Thanks,

Lotic