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

SAML

app integration to use SLO

Use the following steps to update your

SAML

app to use SLO:

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

   SAML

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

   SAML Settings

   section, click Edit.

4. Scroll down, click Show Advanced Settings, and then scroll down to the SAML Request section.
5. Click Browse files to upload a signature certificate or CA in .pem format. Your app must sign the SLO request with the certificate.
6. In the Logout section, do the following to configure SLO:
   • SLO initiation: Select the checkbox to enable SP-initiated SLO for the app.
   • Response URL: Enter the URL where you want Okta to send the logout response at the end of SLO. For example: http://myapp.exampleco.com/logout
   • SP Issuer: Enter the identifier for the app. This is usually the Assertion Consumer Service (ACS) URL or the SP Entity ID. The ACS URL is most often the SAML Post URL location for the target app. The SP Entity ID is the unique identifier that is the intended audience of the SAML assertion. The SP Issuer value is included in the metadata sent in the SP-initiated inbound logout request from the app. For example: https://myapp.exampleco.com
   • SLO participation: Select the checkbox to allow your SAML app to participate in IdP-initiated SLO. Users are signed out of the app when any other app, or Okta, initiates single logout.
   • Request URL: Enter the URL where you want Okta to send the IdP-initiated logout request. For example: http://myapp.exampleco.com/saml/logout
   • Select how your app expects Okta to send the IdP-initiated logout request:
     • HTTP POST: Send additional data in the request body
     • HTTP Redirect: Send data as query parameters in the request URL
   • Select Include user session details to include the session index (sessionIndex) as part of the IdP-initiated logout request. This ends a specific user’s session rather than all active user sessions within that browser.
7. Click Next and then Finish.

Collect the SLO details for your app

1. On the Sign On tab, click View Setup Instructions in the instructional text along the side of the Settings section. The page that appears includes configuration information for your SAML app.

2. Copy the Identity Provider Single Logout URL. This is the POST request URL that your app uses to initiate the logout request with Okta. For example: https://{yourOktaDomain}/app/{app}/{key}/slo/saml

   • yourOktaDomain: Your Okta org URL
   • app: The name (not label) of your SAML app
   • key: The ID of your SAML app

3. Copy the Identity Provider Single Logout Callback URL. This is where the SAML app makes a POST or REDIRECT request to Okta in response to the Okta outbound logout request.

4. Add these URLs to the configuration settings in your SP SAML app.

Use the API to update your

SAML

app integration

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

SAML app

integration for SLO.

This includes adding the participateSlo object for IdP-initiated SLO.

Note: The participateSlo object is independent of the existing slo object (opens new window) that you use to configure the SP-initiated logout flow.

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

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

2. Update the response body by editing the

   signOn

   object:
   • Add the spCertificate object. This is the signature certificate or CA in .pem format. Your app must sign the SLO request with the certificate.
   • Update the slo object:
     • enabled: Set to true to enable SP-initiated single logout.
     • issuer: Enter the identifier for the SP app. This can be an ACS URL or the SP Entity ID. This value is included in the metadata sent in the SP-initiated SLO request.
     • logoutUrl: Enter the app URL where Okta sends the sign out response. If your SP app doesn't have a specific SLO URL, you can use the main app URL.
   • Add the participateSlo object:
     • enabled: Set to true to enable IdP-initiated SLO.
     • logoutRequestUrl: The URL where you want Okta to send the IdP-initiated logout request.
     • sessionIndexRequired: Set to true to include the session index (sessionIndex) as part of the IdP-initiated logout request. This ends a specific user’s session rather than all active user sessions within that browser.
   • bindingType: Set how your app expects Okta to send the IdP-initiated logout request:
     • POST: Send additional data in the request body
     • REDIRECT: Send data as query parameters in the request URL
   
   

   Example request

   The request and the x.509 certificate are truncated for brevity.

   { ...
       "signOn": { ...
           "spCertificate": {
                   "x5c": [
                   "MIIDnjC...EruxrghxV\r\n"
                   ]
               },
           "slo": {
                   "enabled": true,
                   "issuer": "https://${myapp.exampleco.com}",
                   "logoutUrl": "https://${exampleSAMLAppLogoutURL}"
               },
           "participateSlo": {
                   "enabled": true,
                   "logoutRequestUrl": "http://${exampleSAMLAppLogoutRequestURL}",
                   "sessionIndexRequired": true,
                   "bindingType": "POST"
               }
       }
   }
   

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

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

   
   

   Example response

   The response and the x.509 certificate are truncated for brevity.

   {...
         "signOn": {
         "defaultRelayState": "",
         "ssoAcsUrl": "http://myapp.exampleco.com/saml/sso",
         "idpIssuer": "http://www.okta.com/{org.externalKey}",
         "audience": "urn:example:sp",
         "recipient": "http://myapp.exampleco.com/saml/sso",
         "destination": "http://myapp.exampleco.com/saml/sso",
         "subjectNameIdTemplate": "{user.userName}",
         "subjectNameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
         "responseSigned": true,
         "assertionSigned": true,
         "signatureAlgorithm": "RSA_SHA256",
         "digestAlgorithm": "SHA256",
         "honorForceAuthn": true,
         "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
         "spIssuer": "https://myapp.exampleco.com",
         "requestCompressed": false,
         "attributeStatements": [],
         "inlineHooks": [],
         "participateSlo": {
             "enabled": true,
             "logoutRequestUrl": "http://myapp.exampleco.com/saml/slo",
             "sessionIndexRequired": true,
             "bindingType": "POST"
          },
          "spCertificate": {
             "x5c": [
                  "MIIDnjCC ... EruxrghxV\r\n"
             ]
          },
          "allowMultipleAcsEndpoints": false,
          "acsEndpoints": [],
          "samlSignedRequestEnabled": false,
          "slo": {
             "enabled": true,
             "issuer": "https://myapp.exampleco.com",
             "logoutUrl": "http://myapp.exampleco.com"
           }
        } ...
   }
   

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.