OAuth 2.0 session management with SSO/SLO scenario

Identify OAuth 2.0 has full support for the session management specification.

Discovery endpoint

You can check the discovery endpoint of your Identify instance to see if the check_session_iframe and the end_session_endpoint feature have been supported:

"end_session_endpoint": "https://#identifydomain/runtime/openidconnect/logout.idp",
"check_session_iframe": "https://#identifydomain/runtime/openidconnect/sessionlogout.idp",

check_session_iframe

The openidconnect/sessionlogout.idp endpoint simply returns a page that is embedded on a target RP's page.

To enable session management, the option "Enable session status change notification" on the client's configuration must be turned on.

For the Identify Admin, you can find it in the OAuth 2.0 protocol connection:

setting

For the Safewhere Admin, you can find it in the OpenID Connect/OAuth 2.0 application's connection settings:

setting

For the REST API, you can add a property named "performSessionStatusNotification" into its "configuration" connection JSON element.

If this option is enabled, Identify will generate a cookie named OPBS which stores the current session value. Besides, authorization and token response will include one more claim called session_state.

end_session_endpoint

An RP can initiate a logout (which is called RP-ininitated logout) by sending a logout request to this endpoint.

Protocol

Setting up OAuth 2.0 protocol connection for session management

You need to update the settings below:

  • Redirect uris: Set your client redirect_uris (including your ReauthenticationCallBack endpoint)
  • Allow implicit flow: This setting must be enabled.
  • Enable session status change: This setting must be enabled.

For the Identify Admin, you can find the options in the OAuth 2.0 protocol connection:

setting

For the Safewhere Admin, you can find the option in the OpenID Connect application's connection settings:

setting

and its security settings:

setting

Client application

You need to implement the RP iframe for your application.

You can also refer to our OIDC client sample application for how the iframe is implemented.

  1. At the Safewhere Admin, create a new client: ASP.NET core 2 web application.

setting

and copy its configuration

  1. Download the sample.

  2. Paste the copied configuration to the appsettings.json file.

  3. Update the value of the EnableSessionManagement setting from "false" to "true".

    "EnableSessionManagement":  "true",

  4. Build the sample solution and start its login flow. When you choose to log out of another service provider which has the same session with this service provider sample, you are also logged out of this sample.

Advanced federation and SLO issue

In Identify, an OIDC connection can be set up to use one or more IDPs and two or more SPs can use the same login session, some tricky situations can happen as described in the example below.

Let's say we have 4 OIDC relying parties (SP1, SP2, SP3, and SP4) and 2 upstream IDPs (ADFS and IdPDemo):

  • SP1 and SP2 are configured to log in using the IDPs ADFS and IdpDemo.
  • SP3 and SP4 are configured to log in using the IDP IdpDemo. These two SPs aren't allowed to use ADFS to log in.
  • Session management is enabled for all SPs.

On a browser session, a user logs in to SP1 by using the ADFS IDP. After that, the user logs in to the SP2 on another browser tab. Because SP2 can use ADFS, SSO kicks in and both SPs have the same SSO context.

Open two more tabs on the same browser session and log in to SP3 and SP4 by using IdpDemo. SP3 and SP4 share another same SSO context.

Now, If you log out the SP1, the SP2 will be required to do a re-login. Here is what happens:

  1. Because SP1 and SP2 share the same SSO context, SLO happens for SP2.
  2. Because the session management is enabled, the SP2 will send a session state check request to Identify. This means that SP2 will make a re-authentication request with its id_token_hint.
  3. Identify receives the authentication request and detects that the IdpDemo can be used to authenticate SP2 and that there is an existing session. Therefore, the SP2 is logged in automatically and join SP3 and SP4's SSO context.
  4. However, as requested by the specification, Identify as an OAuth 2.0 Authorization server needs to validate the current Identity against the received id_token_hint. The result is invalid because they came from two different IDPs.
  5. Identify sends a response to the SP2 with a "login_required" error.

In this scenario, the SP2 is responsible to send a new login request to Identify to receive the new Identity as well as the latest OPBS cookie state.