And the info is appreciated. As noted, this appears to be on the backend of the identity provider, and is not browser-related.
It’s an intermittent issue, and troubleshooting it (which I and another member of the Heroes team have spent the better part of the past 2 days digging deep into, with some assistance from a couple other folks). We’ve got a couple ideas of things to try, but it’s going to take some time to resolve.
With regards to the logout - the way OIDC works, single log-out (which is conceptually feasible) is pretty challenging to implement effectively. What happens is the identity provider (IdP, id.o.o in our case) has its own authentication token. The Ipsilon identity provider system doesn’t provide a SLO endpoint as part of its well-known endpoints, so software that depends on that for knowing where to redirect for a full logout doesn’t know where to go to do that.
In the case of Discourse, it issues its own authorization token, and that’s what the Logout link clears here - but when the token for id.o.o is still valid (as it is because the Discourse OIDC plugin doesn’t know about it), when you hit the IdP a second time, it says you’re already logged in, and essentially refreshes the token for forums.o.o without requiring a login.
The same can hold true if the logout goes the other way - while forums.o.o won’t cause id.o.o to issue a new token for itself, forums.o.o will retain its own token, and thus can remain authenticated.
There’s a lot of work that ultimately has to go into making SLO work, including ensuring that the token lifetimes for the application (Relying Party or Service Provider) and the IdP don’t cause each other issues.
Most sites don’t end up implementing it across all systems because doing is is incredibly challenging.
(FYI, I spent nearly a decade working for a company that makes an Identity Provider and got deep into IAM solutions - and prior to that, I was a SME on Novell’s directory technology - wrote a couple of books on it.)
