OIDC clustering

[Matt Brennan]

I can't speak to the official recommended way to do this, but I am running
a local instance of MariaDB with Galera on each node as my StorageService.
Galera syncs the tables across all of the nodes so they all have the
session information regardless of which node in the cluster is hit by the
request. This doesn't help if a node fails during authentication (i.e.
between the password and MFA steps), but once the session is established
the user (or the RP) can hit any node in the cluster and that node can
validate the token / cookie / etc.

You could also point all your nodes to a single data source, but then you'd
have a single point of failure.

-Matt

On Mon, 20 Jul 2026 at 12:01, B via users <users at shibboleth.net> wrote:

>
> On Saturday, July 18th, 2026 at 10:28 AM, Scott Cantor via users <
> users at shibboleth.net> wrote:
>
> >
> > > But that doesn't apply to attributes for claims, where the data stays
> on the node, correct?
> >
> > Attributes generally come from elsewhere, and get resolved at a lot of
> different points in different requests. In the rare cases that the data
> only exists during a authorization reques, it can be encoded into the
> tokens issued for recovery later, so it's trivial (size aside) to resolve
> data on one server and reissue it from the UserInfo endpoint on another by
> pulling it from the access token.
> >
>
> So going back to your first reply, and keeping in mind the testing
> problem, by default does the code returned to the browser by
> /idp/profile/oidc/authorize on node A contain enough information for node B
> to run the resolver, so it can respond to a token or userinfo request?
>
> Thanks
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260720/fa90c19c/attachment.htm>