Configure Single Logout

Identity Engine
Early Access

This guide discusses how to configure Single Logout (SLO) for your apps.

---

Learning outcome

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

What you need

• Okta Developer Edition organization (opens new window)
• Existing SAML app and OpenID Connect (OIDC) app integrations to update for SLO. See Create SAML app integrations (opens new window) or Create OIDC app integrations (opens new window) if you don’t have configured app integrations.
• The SLO feature enabled for your org. From the left navigation pane in the Admin Console, go to Settings > Features, locate the SLO feature, and enable.

---

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 on other devices.

Okta supports Service Provider-initiated (SP-initiated) SLO for third-party SAML 2.0 and OpenID Connect (OIDC) apps. When an end user clicks the sign-out button in your app, the app directs the browser to Okta while making an inbound logout 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 logout requests (IdP-initiated SLO) after the SP app makes the SP-initiated inbound logout request to Okta. Okta sends outbound logout requests to any other apps participating in SLO that didn't initiate the logout. 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 logs the user out of everything at once.

Single Logout 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 sessions for the user 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 that 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 SAML apps, and web and single-page (SPA) OIDC apps. The following steps explain how to configure your apps for SLO.

Update your

OIDC

app integration to use SLO

Use the following steps to update your

OIDC

app to use SLO:

1. In the Admin Console, go to Applications > Applications.
2. Select the

   OIDC

   app that you want to update to use SLO.
3. On the General tab, in the

   General Settings

   section, click Edit.

4. Scroll down to the LOGOUT section and do the following to configure SLO:
   • Logout redirect URIs: Enter the URI where you want to redirect the browser after SLO is complete.
   • Single Logout (SLO): Select the checkbox to enable IdP-initiated SLO for the app.
   • Logout request URL: Enter the URL where Okta sends the IdP-initiated logout request. For example: http:/myapp.exampleco.com/slo/logout
   • User session details: Select 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.
5. Click Save.

Use the API to update your

OIDC

app integration

The following example shows you how to use the API to update your

OIDC app or OAuth 2.0 client app

integration for SLO.

Add the three new properties to the oauthClient object for IdP-initiated SLO.

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 participate_slo 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",
           "participate_slo": 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",
               "participate_slo": 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 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
• TotalSamlLogoutRequests: Lists the total number of logout requests for SAML apps

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.