Configure Single Logout

Identity Engine
Early Access

This guide discusses how to configure the Single Logout (SLO) feature for your

apps

.

---

Learning outcome

Understand the purpose of Single Logout (SLO) and set it up for your

apps

.

What you need

• Okta Integrator Free Plan org (opens new window)
• Existing

  OpenID Connect (OIDC) app integration

  to update for SLO. See

  Create OIDC app integrations (opens new window)

  if you don’t have one configured.

• The SLO feature enabled for your org. In the Admin Console, go to Settings > Features, locate Front-channel Single Logout, and enable it

  .

---

Overview

The Single Logout (SLO) feature allows a user to sign out of an SLO-participating app on their device and end their Okta session. The user is then automatically signed out of all other SLO-participating apps.

Okta supports service provider initiated (SP-initiated) SLO for third-party SAML 2.0 and OpenID Connect (OIDC) apps. When an end user clicks sign out in your app, the app directs the browser to Okta while making an inbound sign-out request. This indicates to Okta that the user wants to sign out of the app. In response, Okta ends the user’s Okta session.

The multiple device SLO feature supports outbound sign out requests (IdP-initiated SLO) after the SP app makes the SP-initiated inbound sign-out request to Okta. Okta sends outbound sign-out requests to any other apps participating in SLO that didn't initiate the sign-out flow. This applies only to the downstream apps where the user has previously established a session. Requests are communicated from Okta to apps using front-channel logout, which means that the browser does the communicating.

SLO is especially useful in scenarios where users share computers or use public kiosks. A user may sign in to a computer portal, and then open multiple apps. The user sign-in process for each app happens behind the scenes.

Ideally, when the user wants to sign out, they should sign out of every app to keep the next user from accessing their information. But, most users don’t do that. SLO signs the user out of everything at once.

SLO

diagram

Event 1

• The user signs out of App 1 using Browser 1.

• App 1 initiates the logout (SP-initiated) by sending a front-channel inbound logout request to Okta using Browser 1. For example:

  GET https://{yourOktaDomain}/oauth2/v1/logout?id_token_hint=<idToken>&post_logout_redirect_uri=<configuredPostLogoutRedirectUri>&state=<someState>

• Okta ends Okta session 1. The user can still access Apps 2 and 3 within the scope of each app session.

Event 2

• Okta determines that Apps 2 and 3 were also part of Okta session 1.

• Okta initiates the outbound logout request (IdP-initiated) to the downstream apps (Apps 2 and 3) in an embedded IFrame that’s invisible to the user. For example:

  POST https://myapp.exampleco.com/slo/logout

  Note: This URL is whatever the logoutRequestUrl is that you configure in the app integration.

• Okta makes a GET or POST redirection request to App 1.

• If a downstream app is a SAML app, the SAML app makes a POST or REDIRECT request to the Okta /app/{app}/{key}/slo/saml/callback endpoint in response to the Okta outbound logout request. The SAML logout response is included in the request body.

Note: Only Okta session 1 is terminated. Okta Sessions 2 and 3 are still active despite Apps 2 and 3 no longer having a valid session in Browsers 2 and 3. It’s up to the apps to kill the sessions for that user.

Event 3

Because Apps 2 and 3 have user sessions in other browsers, and on other devices, the apps may terminate these sessions from the server side. When the user tries to use these apps in the respective browsers, the user discovers the apps have invalidated the user’s browser sessions.

Downstream SAML apps terminate a specific session associated with the user or terminate all sessions associated with the user. This depends on whether sessionIndex (SAML) is included in the IdP-initiated logout request. For OIDC apps, this depends on whether the session ID (sid) and issuer (iss) are included.

Configure

SLO

SLO supports web and single-page (SPA) OIDC apps and OAuth 2.0 client apps. The following steps explain how to configure your apps for SLO using the API.

Note: See Configure Single Logout in app integrations (opens new window) to update your app using the Admin Console.

1. Send a GET app request and copy the response body for use in the PUT request.

   GET https://{yourOktaDomain}/api/v1/apps/{appID}

2. Update the response body by editing the settings.oauthClient object:

   • Update the participateSlo property to true.
   • Add the following new properties:
     • frontchannel_logout_uri: Enter the URL where Okta sends the IdP-initiated logout request.
     • frontchannel_logout_session_required: Set to true to include the session ID (sid) and issuer (iss) as part of the IdP-initiated logout request. This ends a specific user’s session rather than all active user sessions within that browser.

   Example request

   The request is truncated for brevity.

   { ...
       "settings" { ...
           "oauthClient": {
               "client_uri": null,
               "logo_uri": null,
               "redirect_uris": [
               "http://myapp.exampleco.com/authorization-code/callback"
               ],
               "post_logout_redirect_uris": [
                   "http://myapp.exampleco.com"
               ],
               "response_types": [
                   "code"
               ],
               "grant_types": [
                   "authorization_code"
               ],
               "application_type": "web",
               "consent_method": "REQUIRED",
               "issuer_mode": "DYNAMIC",
               "idp_initiated_login": {
               "mode": "DISABLED",
               "default_scope": []
               },
               "wildcard_redirect": "DISABLED",
               "participateSlo": true,
               "frontchannel_logout_uri": "http://myapp.exampleco.com/logout/callback",
               "frontchannel_logout_session_required": true
           }
       }
   }
   

3. Use the updated response body in a PUT request.

   PUT https://${yourOktaDomain}/api/v1/apps/${appID}

   Example response

   The response is truncated for brevity.

   { ...
       "settings": { ...
           "oauthClient": {
               "client_uri": null,
               "logo_uri": null,
               "redirect_uris": [
                   "http://myapp.exampleco.com/authorization-code/callback"
               ],
               "post_logout_redirect_uris": [
                   "http://myapp.exampleco.com"
               ],
               "response_types": [
                   "code"
               ],
               "grant_types": [
                   "authorization_code"
               ],
               "application_type": "web",
               "consent_method": "REQUIRED",
               "issuer_mode": "DYNAMIC",
               "idp_initiated_login": {
                   "mode": "DISABLED",
                   "default_scope": []
               },
               "wildcard_redirect": "DISABLED",
               "participateSlo": true,
               "frontchannel_logout_uri": "http://myapp.exampleco.com/logout/callback",
               "frontchannel_logout_session_required": true
           }
       } ...
   }
   

Events

After Okta initiates the outbound logout request to

downstream apps

, Okta includes the number of OIDC and SAML app and IdP logouts that occurred with SLO. Those numbers are found in the System Log event user.session.end under DebugData:

• TotalOidcLogoutRequests: Lists the total number of logout requests for OIDC apps and IdPs
• TotalSamlLogoutRequests: Lists the total number of logout requests for SAML apps and IdPs

See also

• Okta developer blog that explains an inbound Single Logout request using Spring Boot for an OIDC app (opens new window)
• Spring Boot offers a Spring Security SAML Extension (opens new window) that's configured for global logout.