The Impact of Blocked Third-Party Cookies on WSO2 Identity Server
- Tharindu Bandara
- Software Engineer - WSO2
Image credits: xresch on Pixabay
From the moment you type a link in the address bar, web browsers are hard at work trying to protect your identity. The likes of Google safe browsing and phishing protection by Mozilla comes to mind. Modern web browsers are equipped with tracking-prevention capabilities to protect your site data and to prevent malicious tracking. Initially, the plan was not to block third party cookies, but to control its usage using SameSite cookies. With these , users could specify ‘Strict’, ‘Lax’, or ‘None’ values to instruct browsers on how to allow or block third party cookies.
Those values are used as follows:
- Strict - Block third party cookies completely.
- Lax - Allows third party cookies to be sent with top-level navigations, which are sent with GET requests initiated by a third party website.
- None - Third party cookies will be sent in all contexts.
WSO2 updated all its products to support SameSite cookies in January 2020.
The WebKit engine used by Safari, has taken more aggressive steps for enhanced safe browsing protection by introducing the Intelligent Tracking Prevention (ITP) feature and continually improving it. With the release of Safari 13.1, safari site settings now block all third party cookies by default, irrespective of the value set on the SameSite cookie.
Chrome has taken up a similar initiative to block third party cookies in incognito mode to to prevent CSRF attacks from phishing sites and other web based threats starting with Chrome 83. Chrome has further plans to completely phase out third-party cookies by 2022.
Firefox and other major browsers are also heading in the same direction of enhanced safe browsing. While no other browser except Safari has set default security settings to block third party cookies as the default setting, all major browsers have this capability as an option for users to enable if they wish to do so.
The following table (Figure 1) describes how major web browsers currently handle third-party cookies.
| Browser | Third-party cookie handling |
|---|---|
| Brave | All access restricted |
| Chrome | No restrictions (all access restricted on incognito mode) |
| Edge | Access restricted for known trackers |
| Safari | All access restricted, except with Storage Access API |
| Firefox | Access restricted for known trackers |
Impact on Identity Provider Functionality
Some standard identity protocols rely on cookies to ensure that some of its flows function properly. As a result of third party cookies being blocked for privacy protection, some flows within the identity protocols stop working as expected.
Client applications running in the same domain as WSO2 Identity Server are not affected by this.
The following table (Figure 2) lists the impact on WSO2 Identity Server (or on any other identity provider) due to initiatives to block third party cookies by default (with an option to opt-out), starting from Safari 13.1 and Google Chrome 83 incognito mode.
| Functionality | Impact | Workaround / Solution |
|---|---|---|
| Session management (applicable only for OpenID Connect) | Will not be able to detect the IDP session changes, hence will not be able to log out from the client application. | Use backchannel logout instead of using OpenID Connect session management for logout. |
| IDP session extending with passive requests using iframes (applicable only for OpenID Connect) | Will not be able to extend the session. | Refer to section Extending the Identity Provider Session Using an iframe |
| SSO login with Identity Server, where the login page is embedded in an iframe (applicable for both OpenID Connect and SAML 2 Web SSO) | Login functionality will work, but there is no SSO experience between multiple applications. Also if there are any custom cookie usages with adaptive authentication scripts where same-site value of those cookies are NONE, those cookies can be blocked. If you do not embed the Identity Server login page into the client application this has NO impact. | Refer to SSO login with WSO2 Identity Server, Where the Login Page is Embedded in an iframe |
| Cross-site XHR requests made from client application to the Identity Server with token binding validation enabled | Binding validations fail since cookies are blocked. | Turn off access token binding validations when calling APIs, from Identity Server's management console or avoid using cross-site XHR requests with session or cookie bounded access tokens if possible by using an alternative approach. |
Workarounds/Solutions
The resulting efforts to block third party cookies has impacted all identity providers that use standard identity protocols. Currently, identity providers, together with the OAuth community and browser vendors, are looking into effective solutions to overcome these issues.
Session Management and Single Logout
Some applications may use OpenID Connect (OIDC) session management as a mechanism for single logout as defined in the OIDC Session Management specification. However, this approach will not function properly if browsers block third party cookies.
As a solution, clients with backend servers can implement the single logout mechanism defined in the OpenID Connect Backchannel Logout specification.
Extending the Identity Provider Session Using an iframe
Once a user logs into an application from the client application side, a script which runs on the client application side (inside an iframe) periodically pings an Identity Server endpoint to keep its session live. With the current implementation, this call to WSO2 Identity Server relies on cookies, so if third party cookies are blocked, its functionality will be adversely affected.
At the time of writing, WSO2’s Identity Server team is working on a permanent solution to remove the dependency on cookies.
UPDATE: 04/01/2021
WSO2’s Identity Server team has introduced an alternative approach that removes the dependency on cookies while extending IdP's session. This feature is merged and will be available with the 5.12.0 release onwards. Further details are available with the public issue: https://github.com/
SSO Login with WSO2 Identity Server, Where the Login Page is Embedded in an iframe
When WSO2 Identity Server login page is embedded into an iframe, all cookies that the Identity Server relies on to provide Single Sign On (SSO) between multiple applications are treated as third party cookies by the browser.
The recommended solution is to remove WSO2 Identity Server’s embedded login page from the iframe and use the standard redirection flow. The use of iframes is highly discouraged and it should only be used when there is a strong requirement to do so.
Common Solutions
Identity protocols are being affected because cookies set by the identity flows are considered as third party cookies from the perspective of client applications. Having the WSO2 Identity Server login page as a subdomain of the same domain that the application belongs to will solve this issue. This will make WSO2 Identity Server cookies first party cookies for the client application and will no longer be blocked by the browser. For example, if your application is running on app.example.com, then have WSO2 Identity Server’s domain as ipd.example.com.
Educate users on the impact on Identity protocols due to blocked third party cookies
- On Safari 13.1 onwards, users can enable third party cookie sharing. However, this impacts user experience, and they may feel they are at risk by doing so.
- On Google Chrome 83 Incognito mode, users can enable third party cookie sharing. Again, this does affect the user experience as they could feel they are at risk by enabling this option.
- On Firefox and on Google Chrome’s normal modes, users will not experience this issue at the time of writing.
Long-Term Solutions
Several proposals have come up from vendors to better integrate identity flows with their browsers. These proposals hope to solve the issue of identity flows breaking due to its dependency on general web capabilities such as top-level navigation, link decoration, window popups, and cookies.
While these are still in initial stages, they can be considered as long-term solutions when they mature and are possibly added to browsers. The WSO2 team is closely monitoring the development of these initiatives, and as soon as there is a concrete solution, we will update our products to support them.
Some of the ongoing efforts to solve this problem are as follows.
- The isLoggedIn API with which websites can inform the web browser of the user's login state. This will allow identity providers to mark that the user is authenticated with the IdP for a certain website.
- The WebID initiative intends to give browser core-level support for identity federation. One of the problems it addresses is providing the capability to differentiate between federation cases where identity data is exchanged, as well as other scenarios.
The OAuth WG has also initiated discussions on the impact on identity protocols by the use of tracking-prevention technologies that have been introduced by browsers, and new browser initiatives to provide core level support for identity federation.
Summary
Lately, browsers have been introducing new security measures to enhance user privacy regarding user tracking via browser cookies. While browsers initially introduced Same-Site cookies to control the usage of third party cookies, now they are moving towards blocking third party cookies altogether.
However, as a result of these third party cookie restrictions, standard identity protocols are also impacted as the cookies set by those protocols are considered as third party cookies with respect to the client application in certain use cases. This article discussed the specific use cases in WSO2 Identity Server, which could get affected due to third party cookie restrictions and provided solutions, workarounds and updates about the work-in-progress efforts.
In the end, we discussed the ongoing efforts from browser vendors and also from the community itself, towards a better integration of identity flows with browsers. As most of these are still premature, WSO2 is closely monitoring the efforts to update its product and provide support once a stable, concrete solution is provided.