> The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation… T

> The main problem is the way these standards are implemented. OAuth 2.0 (on which OIDC is based) does define a reliable back channel for session revocation… The larger issue is that even if you had a reliable revocation system - most relying parties wouldn't use it. The typical relying party supports logins from Facebook, Google, Apple and the like because the user chose to use those as authentication systems. However, the relying party is independent. The user would not expect other sites and desktop apps to suddenly stop working because the user hadn't visited Facebook for a certain number of hours. There were efforts in the past using transparent pixels on the identity domain to do distributed session tracking - e.g. if I'm interacting with _any site_ using the login, that will encourage the session to stay alive. Turns out that was way too much visibility for social login providers to have.