Federated Logout and SLO
Update: Auth0 now supports OIDC backchannel logout which adds additional flexibility for logout in situations where a user has sessions across multiple independent applications.
This document discusses Federated Logout and Single Log Out (SLO) and links to some commonly implemented patterns. For purposes of this document the following definitions are used:
Federated Logout: Signing a user out of the upstream identity provider by using the ?federated
querystring parameter on the Auth0 logout endpoint.
Single Log Out or SLO: Signing a user out of the upstream identity provider and any other applications they are signed in to. This is only available in the context of SAML interactions.
Logout: Refers to both Federated Logout and SLO
Other terms used in this document are:
IdP: Identity provider. Auth0 is acting as the IdP if the SAML2 Web App Add On is enabled for an application.
SP: Service provider. Usually an application, but can also be an identity service like Auth0 when an external IdP is configured as a SAML connection. Auth0 is acting as the SP if an Enterprise SAML connection is configured.
A thorough understanding of session layers is critical before this document can be useful. Please reference the Auth0 session layers document as needed.
Federated Logout
Auth0 is able to sign the user out of certain upstream identity providers. See the list of IdPs for which federated logout is supported.
Additional configuration is not required. Applications can redirect the user to the following endpoint to initiate federated logout:
https://YOUR_DOMAIN/v2/logout?federated
The application is responsible for terminating the user’s session before redirecting the user to the auth0 /logout
endpoint.
Auth0 will terminate the user’s Auth0 session and then redirect the user to the IdP’s logout endpoint, which will terminate the session with the IdP. The returnTo
parameter can be specified to redirect the user after logout is complete. See this document: Redirect Users After Logout. Note not all IdPs support returnTo
.
Please note the limitations of federated logout.
SAML SLO
True SAML SLO is only available when Auth0 is acting as a SAML IdP. When Auth0 is acting as a SAML SP, a SAML logout request can be sent to the upstream IdP, but other applications won’t be notified.
SAML supports initiating the SLO flow either from the SP or the IdP.
Auth0 as SAML SP
In many ways, when Auth0 is the SP “SLO” is more like “federated logout”, especially for SP-initiated SLO.
Configuration
A SAML logout URL should be configured in the SAML connection (the SLO endpoint is called “SingleLogoutService” in the SAML metadata). If no logout URL is configured, SAML logout requests will be sent to the SAML sign-in endpoint.
The SAML IdP should be configured to send SAML logout responses to the following URL:
https://YOUR_DOMAIN/logout
Operation
This section describes the mechanics of initiating SLO. The terms SP-initiated and IdP-initiated are used here. Do not conflate these terms with IdP and SP initiated login. This section only describes SLO flows, and the SLO flow need not be the same as the initial login flow (e.g. Idp-initiated SLO could follow an SP-initiated sign in).
SP-initiated SLO
Applications can make a simple GET request to the Auth0 /logout
endpoint with the federated
parameter:
https://YOUR_DOMAIN/v2/logout?federated
Auth0 will send a logout request to the appropriate endpoint on the SAML IdP. On receiving the request, the IdP may or may not do a full SLO flow to any other saml SPs associated with the session (this is entirely up to how the IdP manages sessions and SLO and not related to Auth0 in any way). Eventually, the IdP will return a logout response to Auth0. If the status of this response is “success” then Auth0 terminates the user’s Auth0 session. If the response does not indicate success then the user’s session remains active.
The following sequence diagram shows an SP-initiated SLO flow:
IdP-initiated SLO
If the application redirects the user to the SLO endpoint on the upstream IdP, the IdP can send a SAML logout request to the Auth0 tenant at:
https://YOUR_DOMAIN/logout
While this the correct configuration, there is a known bug in Auth0 that the Auth0 user session will not be terminated (put another way, the SAML SP session at Auth0 will still exist). What should happen is Auth0 would terminate the user’s session and return a SAML logout response to the SLO endpoint on the IdP (note the SAML logout response is returned despite the bug). Note the following:
- In IdP-initiated SLO the application does not directly call any Auth0 endpoints.
- The endpoint to initiate SLO on the IdP or SP may not be the same as the “SingleLogoutService” endpoint that receives SAML logout requests. This is the case for Auth0, where the “SingeLogoutService” endpoint is “/logout” and the endpoint to request SLO is “/v2/logout?federated”.
Despite the bug, we recommend configuring your IdP as above, so the correct thing will happen when the bug is fixed. Consider Forced Reauthentication and short session lengths in the interim.
Auth0 as SAML IdP
Configuration
The SAML2 Web App Add On must be configured for SLO. The document SAML single logout scenarios has more details, but to summarize, the settings should contain:
{
…
"logout": {
"callback": "CALLBACK_URL",
"slo_enabled": true
}
…
}
Where CALLBACK_URL
is the endpoint on the SAML SP that will consume the SAML logout response. Additionally, the SAML SP should be configured to send SAML logout requests to the following URL:
https://YOUR_DOMAIN/samlp/CLIENT_ID/logout
Where CLIENT_ID is the client_id of the application where the SAML2 Web App Addon is configured.
Operation
This section describes the mechanics of initiating SLO. The terms SP-initiated and IdP-initiated are used here. Do not conflate these terms with IdP and SP initiated login. This section only describes SLO flows, and the SLO flow need not be the same as the initial login flow (e.g. Idp-initiated SLO could follow an SP-initiated sign in).
SP-initiated SLO
The SP will initiate SLO by sending a SAML logout request to the following endpoint:
https://YOUR_DOMAIN/samlp/CLIENT_ID/logout
Auth0 will use the logout response to look up the user’s session. If the user has sessions with other SAML SPs, Auth0 will redirect the user to all of those SPs in turn[^1]. Eventually, Auth0 will send a SAML logout response to the SP (hopefully with status “success”). It is the responsibility of the SP to display the results of the SLO attempt to the user.
[^1] This is a redirect-based flow and Auth0 will, via the browser, send logout requests to and receive responses from all of the SPs with an active SAML session.
Only SAML applications will be notified. If the user has application-level sessions open with applications using other protocols (e.g. OIDC), those sessions will remain active.
IdP-initiated SLO
Auth0 does not support Idp-initiated SLO when Auth0 is configured as the SAML IdP. The user can be redirected to do a GET on:
https://YOUR_DOMAIN/v2/logout?federated
This will terminate the user’s Auth0 session and the session with an upstream IdP (if applicable). No other applications will be notified.
See the section “Federated Logout” for more information.
Logout Patterns
The following are links to other documents demonstrating frequent use cases:
Common Questions
What is the difference between requesting SLO vs sending a SAML logout request?
Requesting SLO is when an application (usually one that isn’t SAML-native) requests SLO via a special endpoint. At Auth0 that endpoint is:
https://YOUR_DOMAIN/v2/logout?federated
If Auth0 is the SAML SP and the browser sends a GET to this URL, the Auth0 tenant will generate a SAML logout request and direct the browser to send it to the SLO endpoint on the SAML IdP.
This is shown in a sequence diagram linked here.
SAML applications can generate a logout request directly and send it to the SLO endpoint of a SAML IdP or SP. So if Auth0 is the SAML IdP, a SAML application can generate a logout request and direct the browser to send it to:
https://YOUR_DOMAIN/v2/logout?federated
What if a user has signed into Auth0 with multiple IdPs?
Auth0 only tracks the session from the most recent upstream IdP interaction. If federated logout is requested, the upstream IdP from the most recent interaction will be notified.