-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OIDC authentication on vanity domains with partitioned cookies #80
Comments
Thanks for the question, @jkosir! Note that, at least for the near-term, your OIDC/redirect-based flow may become exemption from third-party cookie blocking due to some heuristics that we are deploying in Chrome. I would recommend verifying this by following these testing instructions. You may also qualify to request additional time to migrate away from third-party cookies by following this process. For the long-term, we are hoping to build out a solution that may or may not be based on CHIPS; so thank you for the details on your use-case. We had previously considered the possibility of a partitioning scheme that accounts for popup/redirects, but it would be really helpful if you could either advocate for such a solution on that thread, or open a new bug using https://goo.gle/report-3pc-broken. |
Thanks for the update @krgovind
Am I understanding correctly, that auth cases that involve a redirect will remain to be out-of-the-box supported, even if the user is part of the 1% that have third-party cookies deprecated? Can we rely on this exemption until Chrome exposes a dedicated reliable solution for such cases? |
Yes, you can rely on this solution for auth cases for the 1% experiment group which will have third-party cookies blocked. However, I'd recommend that you test out the heuristics using these instructions to make sure that they do unbreak your user flow. In terms of long-term solutions, note that we recently published some guidance for identity use-cases here. I was curious if you have explored using the FedCM API? |
@krgovind Thanks for the feedback. Is there anywhere official statement that such cases will remain to be supported, even if the user is part of the 1% with deprecated 3rd party cookies? We would like to be transparent with our customers and want to include this in our documentation. In regards to the FedCM API - we have checked it with the dev team and here is the feedback.
We are a SaaS company where B2B2C is the most common use case. As a result, we cannot affect a lot on parent applications in which our product is embedded, nor on their identity provider. |
I don't follow exactly what issues are. Can you expand either here or in a new issue in the FedCM repo? In particular, |
Hello @npm1. I am working with @UgoFantozzi and we have encountered a separate use-case, which I will try to explain: We sell a product to our customers that includes a back-end, authentication management, and a web UI that can be embedded into their sites. Here is what happens when a user configures our app to use Single Sign-On (SSO): Our product (ourProduct) is deployed by our customer at their desired location, 1 per customer (https://product.domain.com). Our customer, who uses our product, embeds it into their websites (customerSite, https://customer.site.com). The end-user uses the whole application, and each customer has a personal SSO identity provider (https://oidc.provider.com), configured by them and used within ourProduct for user authentication. With this setup, here is the login flow:
Regarding FedCM: During the implementation of our Proof of Concept (POC), I attempted to use ourProduct as the "identity provider" as per the tutorial. This required implementing all the necessary endpoints according to the documentation. The first obstacle I encountered is that the /.well-known/web-identity endpoint needs to be provided on the eTLD+1 of the IDP, which is "https://domain.com" in the case of our app being deployed at "https://product.domain.com". This is a part we cannot control, thus we cannot use this solution. |
If I understand correctly, https://product.domain.com is not really a user-facing site, is that correct? It seems to me like this could potentially be solved by using FedCM from within an iframe:
A couple other comments:
|
Re: the CHIPS issue, my understanding of the observed behavior is that if a 302 redirect sets a partitioned cookie, the partition key is computed from the site that served the 302, rather than the site that is listed in the
This sounds like an "authenticated embed" use case to me. This is the kind of thing that the Storage Access API is meant for, when the iframe needs fully-unpartitioned cookies. @mefril would the Storage Access API (SAA) be an option for you here? SAA has very different privacy properties than CHIPS (since SAA allows joining user identity across sites, and CHIPS doesn't provide that capability), so SAA involves a user permission prompt. But if you're currently relying on cross-site data sharing between |
it is correct, maybe it is expected behaviour, I'm just trying to find any other way to manage 3rd-party cookies in a such case
Thanks for advice, did some investigation, looks like "requestStorageAccess" is only works with an iframe, which is not our case. I see there is a "requestStorageAccessFor" method that looks like just what I need, however I didn't manage it to work. Every time I am trying to get "requestStorageAccessFor" inside user's interaction, I am having "DOMException: requestStorageAccessFor not allowed" with no detailed explanation. Checked the documentation and looks like the only reason it may not work is "The top-level and embedded sites are not in the same Related website set" (In this step documentation is a bit misleading, as I understood it should show "prompt" in a general case and skip a prompt if websites are in the same "Related website set"). |
Chrome is considering a new proposal which might help with this use case: https://github.com/arichiv/partitioned-popins |
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 tohub.ourapp.com/api
. We do not want to set any cookies forvanity.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/
withpartitionKey=vanity.com
when our app is served onvanity.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 havehub.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/...">
insidevanity.com
and do the OIDC process inside theiframe
(or in a popup opened from saidiframe
), eventually theiframe
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 forvanity.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 theiframe
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.
The text was updated successfully, but these errors were encountered: