AuthorizationCodeAffinity

The main reason why SAML relies primarily on the front-channel for SSO despite some additional security risks is that it makes deployability better over time by a couple orders of magnitude. The ability to freely deploy changes or new software versions internally and test against essentially any SP through simple /etc/hosts file manipulation is a massive benefit that is practically mandatory if you care about IdP reliability over time at all.

The reliance on a back-channel breaks this completely without additional features and deployment steps. V3.1 of the OP introduces a small change that allows for some of this testing capability to be restored with some (non-trivial) additional work on load balancer configuration.

The property idp.oidc.nodePrefix can be set to assign a specific tag to a particular server node. Typically this would be done via a dedicated property file, to avoid accidentally duplicating the value on two servers. The value must be no longer than 10 characters.

If set, authorization codes and opaque access/refresh tokens issued by the OP will be prefixed with a signal value and the node prefix value (padded to 10 if required). A load balancer with sufficient flexibility (like most) can be configured to recognize specific prefix values in the queries or bodies of requests and direct them to a specific server. Doing this allows a “staging” deployment server to prefix its codes and tokens such that requests from clients can be routed back to that server, ideally while not routing any other requests to it. This allows the staging server to be exercised against applications without generally impacting other users, as is commonly done with SAML.

Note that the tokens can be decrypted by any server with the shared key, as before, so if a mistake is made and a client connects to the wrong server, it should not result in failures strictly due to inability to unwrap the data, though it will warn about the issue.