You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most browsers are aggressively blocking cookies when page belonging to different TLD is loaded in an iframe. This also impacts OIDC based integrations where application page is embedded in other portals inside iframe. The current implementation of nginx relies on opaque token sent as cookie.
Are there any plans to provide an alternate option. Some of possible things could be:
Fallback to local/session storage if cookie support is not detected.
Provide a parameter for opening the IDP page in a popup so that the cookies created by IDP are treated as First Party.
The text was updated successfully, but these errors were encountered:
Sorry for the late response. Can you share some more Information about your architecture? Feel free to use example domains but I would like to better understand the use case and where the iFrame comes to play.
To question #1: the opaque cookie is generated while sending the response using the set-cookie header. We do not have access to the browsers local/session storage.
#2: we are „opening“ the login page based on a browser redirect if the user is not authenticated. The popup idea can not be handled by the relaying party alone. This would require some more integration in your application.
Most browsers are aggressively blocking cookies when page belonging to different TLD is loaded in an iframe. This also impacts OIDC based integrations where application page is embedded in other portals inside iframe. The current implementation of nginx relies on opaque token sent as cookie.
Are there any plans to provide an alternate option. Some of possible things could be:
The text was updated successfully, but these errors were encountered: