4 ms·
Honestly there's only one proper way to do it cross domain: Your Single Sign-On mechanism needs to pass a session identifier. Whether that's via a claim on an O
by krinchan 5y ago
Honestly there's only one proper way to do it cross domain: Your Single Sign-On mechanism needs to pass a session identifier. Whether that's via a claim on an OAuth2 token (or an OIDC ID token) or an attribute in a SAML assertion, it needs to represent a particular session your IdP holds with the user agent.
Applications leveraging the SSO solution must check that the session identifier is still valid via some sort of API call.
When a client logs out and hits your SLO process, the session ID is marked as revoked. Queries to the API for that session ID will reveal it is revoked and all other interested parties will now know that the session is no longer valid and can take action.
Practically, this usually means checking the API on every page render or in the case of an SPA, every time a request is made. If you are willing to accept a delay in the log out propagating to other domains, you can cut back to every X requests or a particular interval of time, say 5 minutes.
- cj 5y agoOn the SP side, I frequently see extremely short session lengths as the simple (but annoying) alternative to checking if a session is revoked. GitHub requires SAML re-auth every 24 hours. AWS defaults to 1 hour but customizable. Do many SP’s even support SLO in a standardized manner? I believe there is a spec/standard for it, but I could be mistaken.
- krinchan 5y agoThere is no good spec. There are several conventions that are almost always IdP specific. That said, you hit on the main point: The best way to handle Single Log Out is to not handle single log out. If I log out of a federated AWS session, I am not logged out of Okta. If I log out of Okta, I am not logged out AWS. Unfortunately, someone saw SLO was a feature and ordered us to enable it and provide support to the SPs to implement it against my recommendations to do otherwise and here we are.