Description
Hi, my use case is a SaaS web app that allows clients to define vanity domains on which the app can be accessed.
Authentication is done with cookies and when our app is served on vanity domain (e.g. vanity.com
) we set a (3rd party) cookie for our main domain, e.g. hub.ourapp.com/api
, and all data is loaded with API calls to hub.ourapp.com/api
. We do not want to set any cookies for vanity.com
as the domain is not controlled by us.
As far as I understand this is the same case CDN Load Balancing example and we are in fact able to make this work with partitioned cookies, we set a session cookie for hub.ourapp.com/
with partitionKey=vanity.com
when our app is served on vanity.com
.
The only issue we're having is in the login process which is done via OIDC, essentially after successful login on the identity provider the users are redirected to hub.ourapp.com/api/oAuthCallback?code=<>&state=<>
, which (after successful code token exchange) drops a session cookie. Since here we have hub.ourapp.com
as the top level context we are unable to drop a partitioned cookie.
We found a way to make this work by embedding an <iframe src="hub.ourapp.com/...">
inside vanity.com
and do the OIDC process inside the iframe
(or in a popup opened from said iframe
), eventually the iframe
gets redirected to a callback url (<iframe src="hub.ourapp.com/api/authCallback?code=<>&state=<>">
) and the cookie dropped in response to /api/authCallback
is correctly partitioned for vanity.com
.
While this works it is quite cumbersome and can pose some security risks, if the OIDC flow is done in a popup a postMessage(codeToken, '<iframeOrigin>')
must be used to share the code token with the iframe, potentially exposing it to some JS code. Alternatively if we actually do the entire OIDC flow inside the iframe
we must disable embedding prevention (X-Frame-Options
, Content-Security-Policy
) which is something you generally want to have on an identity provider to prevent clickjacking attacks.
Is there a cleaner way to set a partitioned cookie in this example? It seems like quite a common use case (OIDC authentication and vanity domains) and it seems unlikely this would be the simplest way to handle it.