OIDC clustering

[Scott Cantor]

> 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).

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.

> 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).

Using JDBC or Memcache is necessary for revocation and other such features, which is also why I wouldn't support those features if I were operating an IdP. There wasn't enough money in the world to convince me to run an IdP with a database, and I managed to get to retirement without having to.

-- Scott