OIDC authorization code flow, was SAML2 artifact and IdP clustering

[Cantor, Scott]

On 2/14/19, 9:54 AM, "dev on behalf of Janne Lauros" <dev-bounces at shibboleth.net on behalf of janne.lauros at csc.fi> wrote:

> We use replay cache (standard shibboleth cache) and revocation cache (cache to store information of revoked
> tokens). Those are the only parts of the extension that should have impact on clustering.

And I haven't fully grokked all the interactions that OIDC or OAuth presume are going on so I wasn't sure what would end up being practical or not. My feeling is that OIDC is being misused if it's issuing anything but 5 minute bearer tokens (whether they're pulled back channel or not). I think if it's used that way, there shouldn't be any real barriers.

But if that's not how apps insist on (mis)using the technology, I think the need for token validity tracking will cause problems, though one probably can live with more loosely consistent clustered state allowing for a wider range of approaches that don't just reintroduce a single point of failure.

-- Scott