The OpenID Connect (OIDC) back-channel logout process is designed to enhance security by allowing logout requests to be handled server-to-server, independent of the user's browser. This method ensures that logout requests are reliably received and processed by all applications, even if the user's browser is closed or experiencing issues. The back-channel logout provides a robust mechanism to terminate user sessions across multiple applications, ensuring comprehensive session management.

How It Works

Initiating Logout

When a user decides to log out from an application, the application initiates the logout process by notifying the identity provider. This notification is typically done by sending a request to the identity provider's logout endpoint.

Unlike the front-channel logout, the back-channel logout does not rely on the user's browser to propagate the logout request. Instead, the identity provider sends a logout request directly to each registered application server using a back-channel communication method, such as HTTP POST.

Parameters Explained:

id_token_hint: Similar to the front-channel logout, this parameter contains a token representing the user's current session. It helps the identity provider to verify the session that needs to be terminated.

logout_token: This is a token generated by the identity provider that contains information about the logout request. It includes the user identifier, the client identifier, and a timestamp.

Logout Process:

• Request Initiation: The application the user is logging out from sends a logout request to the identity provider's back-channel logout endpoint. This request includes the id_token_hint to identify the session.
• Validation: Upon receiving the request, the identity provider validates the id_token_hint to ensure it is associated with an active session.
• Generating Logout Tokens: The identity provider generates a logout_token for each application that needs to log the user out. This token contains the necessary information for each application to identify and terminate the user's session.
• Sending Logout Requests: The identity provider sends an HTTP POST request with the logout_token to the registered back-channel logout URL of each application. This request is sent directly to the application's server, bypassing the user's browser.
• Processing Logout Requests: Each application server receives the logout request and validates the logout_token. If the token is valid, the application terminates the user's session.
• Confirmation: Since the back-channel logout operates server-to-server, there is no direct confirmation sent to the user's browser. Instead, the identity provider assumes the applications have processed the requests successfully.

Security and Compliance

The back-channel logout process enhances security by ensuring that logout requests are handled server-to-server, which is less susceptible to browser issues or user interference. The use of logout_token ensures that the logout requests are authenticated and authorized, preventing unauthorized session terminations.

The back-channel logout URLs must be pre-registered with the identity provider to ensure that logout requests are sent to trusted endpoints, maintaining the integrity and security of the logout process.

Benefits for Clients

Enhanced Security: Provides a secure mechanism to log out users from all applications, even if the user's browser is unavailable or compromised.

Reliability: Ensures that logout requests are reliably delivered and processed by all applications, independent of the user's browser state.

Compliance and Trust: Adheres to established OpenID Connect protocols, ensuring compatibility and trust across various platforms and services.

Implementation at Strivacity

The following process outlines how to call for a logout via Strivacity's Delete session for an account API endpoint .

API Call

This requires making a DELETE request using the following syntax:

https://localhost/admin/api/v1/identityStores/{identityStoreName}/accounts/{accountId}/sessions/{sessionId}

In order to initiate this call the “write” permission on the “account” object is required. This can be set at the API security policy.

Responses

This call can result in the following responses.

Success - 204

We receive this every time the request succeeds. In this case, we get nothing else but the 204 status code in the response body.

Failure - 401 Unauthorized

“I don't recognize you so I cannot fulfill your request”.
We receive this error when the provided credentials are incorrect. During logout, the user credentials should already be correct since the user has successfully logged in. Therefore, if we encounter a 401 error during logout, we need to thoroughly review the mechanics of our logic. In most cases, this error occurs due to misaligned API credentials.

Failure - 403 Forbidden

“I know who you are but you are not authorized for this request ”

This status code is returned when the request is authenticated but does not have permission to execute it. If we get this response we should check if we have the correct API permission settings.

Failure - 404 Not Found

“I recognize you and I understand your request but I can't find its target so I can't execute it”.
This status code is returned when the server cannot find the requested resource. Assuming the logic is correct and the request contains accurate values, we may receive this status if we attempt to delete a session that has already expired. Otherwise, we should verify the request values, as they likely contain errors.

The response body of a successful request 204 is empty.
For the failure responses, the body contains this information:

{  
  "detail": "string",  
  "entityName": "string",  
  "errorKey": "string",  
  "fieldErrors": [  
    {  
      "field": "string",  
      "message": "string",  
      "objectName": "string"  
    }  
  ],  
  "message": "string",  
  "params": [  
    {  
      "additionalProp": {}  
    }  
  ],  
  "path": "string",  
  "status": 0,  
  "title": "string"  
}