Extending IdP Sessions at WSO2 Identity Server with Blocked Third Party Cookies
Lately, most of the popular browsers have been working on blocking the use of third party cookies. As of late 2020, Safari and Firefox had already begun blocking third-party cookies by default, and now Google Chrome seems to be following closely with a “phased-out” approach [1]. So how would this affect a user accessing an application using a session at WSO2 Identity Server? If the application still uses the old method for extending sessions, the user’s experience may become a little inconvenient.
Let me elaborate. Earlier, when a user’s session at the Identity Provider (IdP) approaches its timeout, the application would send a passive authorization request to the Identity Server to extend the session and allow the user to keep accessing the application without any interruptions (a passive request is an authorization request that is initiated without any human intervention). The Identity Server uses the commonAuthIdcookie that is sent along with the passive request to identify the session that needs to be extended. In a scenario where the Identity Server is hosted on a sub-domain of the application domain, everything would work as expected as the cookie would then be regarded a first-party cookie. But more often than not, this would not be the case. When third-party cookies are blocked by the browser, the cookie will not be sent along with the passive authorization request. Therefore, the Identity Server will not be able to identify a session, and the application will not be able to extend the session. Hence, the user will get automatically logged out when the session gets timed out. Inconvenient!
So, if your application already uses this method to extend sessions and you’re looking for a solution, or if you’re looking for a way to make your new application extend user sessions, you’ve come to the right place!
Introducing the Session Extending Endpoint…
This endpoint is a newly introduced endpoint dedicated to extending user sessions using a session identifier, or even the cookie. Passive authorization requests are no longer required. The application only has to make an AJAX call to this endpoint using the session key obtained during login to extend the session.
As of now (February, 2021), the session key can only be obtained via OpenID Connect flows, and this functionality is only available in Identity Server version 5.10.0.
This endpoint needs to be enabled before it can be used. To enable this endpoint, add the following entry to the deployment.toml file.
[session_extending_endpoint]
enabled = trueWhen this configuration has been added, the endpoint will be accessible with the following URL.
https://<IS_HOST>:<IS_PORT>/t/<TENANT_DOMAIN>/identity/extend-sessionWith this endpoint, there are two ways in which you could extend a session.
Session Extending Method 1
This method is ideal for cases where the commonAuthId cookie becomes a third-party cookie. Nonetheless, this could be used in first-party cookie scenarios as well as it is very easy to implement in the application, and it would future-proof your application as well if the host domains were to change.
To make session extending calls to this endpoint, you are going to need some session identifier other than the commonAuthId cookie to correctly identify the IdP session at the Identity Server. This identifier can be extracted from the ID token. Once the above config is in place, the session identifier will be returned as a claim in the ID token by the name isk.
To get the session extended, simply send a GET request to the above endpoint with the session identifier as a request parameter. The session identifier (isk value) should be included in the request as idpSessionKey. Hence, an example call to the session extender API would look like this,
curl --location --request GET 'https://localhost:9443/identity/extend-session?idpSessionKey=2be2180d54f49ed891e2c2cb07791350995a54b2b39689e1df4429bf4ae8095e'Session Extending Method 2
The second method is very similar to the traditional approach. The session extending endpoint accepts the commonAuthId cookie as well to identify the session. This method could be used if the cookie is regarded as a first-party cookie. In this case, you would only have make a GET request to the endpoint with the cookie included in the headers.
curl --location --request GET 'https://localhost:9443/identity/extend-session' \
--header 'Cookie: commonAuthId=c70803c0-3aa0-474a-8f4e-86bfac9a8b08'If the session has been extended successfully by using either of these methods, a 200 OK response will be returned. The user will be able to continue using the application. Great! But if the Identity Server fails to extend the session, a 400 BAD REQUEST or 500 INTERNAL SERVER ERROR response will be returned depending on the context. More information on the API responses can be found in [2]. Unique error codes and helpful messages will be returned with the responses to help you steer your application in the right direction in the event of failure.
Hope this resolves some of your ‘blocked third-party cookie’ dilemmas. 😃
Cheers!
References
[2] https://is.docs.wso2.com/en/5.10.0/develop/idp-session-extender-endpoint/#api-responses
