Global Logout Cannot Terminate Application System User Sessions

Problem Description

Application systems integrate with the IDaaS authentication service using standard protocols such as OAuth2 and OIDC. After the administrator adds the application system's logout address in the IDaaS enterprise center application configuration, application developers often encounter the following scenarios where calling global logout cannot terminate the application system's user session.

• IDP-initiated Sign out: The user first logs in to the IDaaS user center and then accesses authorized application systems App1 and App2. When the user clicks unified logout in the IDaaS user center, only the SSO session information is logged out, but the application systems' user sessions are not synchronously terminated.
• SP-initiated Sign out: The user first accesses the target application system App1 after IDaaS authentication, and then continues to access App2/3/N. When the user clicks logout in a certain application system (which has integrated global logout), besides successfully logging out the SSO session and the current application system's user session, the other business systems' user sessions are not synchronously terminated.

Cause

1. The logout address configured for the application system uses the HTTP protocol instead of HTTPS.

Because the IDaaS service uses the HTTPS protocol, when the IDaaS unified logout page calls the application system's HTTP logout address, the browser considers the request insecure and blocks it, causing the application system's user session logout to fail.

2. In cross-site requests, when IDaaS calls the application system's logout address, the application system cannot retrieve the cookie of the current user in that system.

In cross-site requests, when BambooCloud IDaaS calls the application system's logout address, the browser restricts cookie carrying. The application system cannot identify the user currently logged in to the business system, causing the business system user session logout to fail.

Solution

1. The application system must be accessed using the HTTPS protocol.

2. In cross-site scenarios, set the server cookie attribute SameSite to "None; Secure", declaring that cookies can be sent regardless of whether the request is cross-site.

Example of setting a Cookie using Java HttpResponse.addHeader():

response.addHeader("Set-Cookie", "CookieName=CookieValue;SameSite=None;Secure");

Notes:

• The HTTP interface does not support SameSite=None. If you want to add the SameSite=None attribute, the cookie must also have the Secure attribute, indicating that the cookie will only be sent under the HTTPS protocol.
• The new version of Safari enables "Prevent Cross-Site Tracking" by default, prohibiting third-party cookies in cross-site scenarios. In other words, even if the application server sets SameSite=None; Secure, Safari still does not allow cookie-carrying requests. For details, refer to Safari Blocks Third-Party Cookies and Cannot Retrieve User Login Status.

3. Use Nginx or other gateway tools for proxying to turn cross-site requests into same-site requests.

Related References

SameSite Attribute

SameSite is one of the attributes of the HTTP response header Set-Cookie. It allows declaring whether the cookie is limited to first-party or same-site context.

SameSite can have the following three values:

1. Strict: Only same-site requests are allowed to carry cookies. The browser will only send cookies for same-site requests, meaning the current page URL is exactly the same as the requested target URL.
2. Lax: Allows some third-party requests to carry cookies.
3. None: Cookies are sent regardless of cross-site or not.

The default was previously None, but after Chrome 80 the default is Lax.

The Lax case is shown in the following table:

Request Type	Example	Normal Case	Lax
Link	<a href="..."></a>	Send Cookie	Send Cookie
Prerender	<link rel="prerender" href="..."/>	Send Cookie	Send Cookie
GET Form	<form method="GET" action="...">	Send Cookie	Send Cookie
POST Form	<form method="POST" action="...">	Send Cookie	Not Sent
iframe	<iframe src="..."></iframe>	Send Cookie	Not Sent
AJAX	$.get("...")	Send Cookie	Not Sent
Image	<img src="...">	Send Cookie	Not Sent

When SameSite is Lax, cross-site requests for POST, iframe, AJAX, and image do not send cookies.

Reference Links

• Using the Same-Site Cookie Attribute to Prevent CSRF Attacks
• SameSite cookies explained
• Tough Cookies, Scott Helm
• Cross-Site Request Forgery is dead!, Scott Helme