-
Notifications
You must be signed in to change notification settings - Fork 67
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
A not-yet logged in IDP has no route to success with this flow #442
Comments
Yes, this will be needed, especially if an RP wants to use FedCM for a button flow (as opposed to triggering it onload, where silent failure is probably acceptable) #436 adds a signin_url field, which is part of what is needed here. |
Agreed. A key piece will be having the proposed dialog that shows that link show up when a user isn't yet logged in. In addition to that, there are two options:
I think the best way forward is the latter. |
Yes option 2 sounds good to me. But I think we need to figure out how to trigger this behavior. Maybe add a flag somewhere saying that if there are no accounts found, that we should show a signin prompt instead of returning failure silently? And/or have the presence of transient user activation trigger this behavior? |
I think this is also another instance where the RP would want a flag to influence this behavior especially with the introduction of multi-idp support - see #438 (comment) - there could be a IDP specific flag where the RP could indicate to be wanting to enable a IDP sign-in from its site. |
This would be quite relevant to Seamless Access. We expect that users will move between many sites, wanting to access for example scientific content. They will be shown the option, but it needs to be clear that they are signed in or still need to |
+1 that the
Yeah, maybe an extra attribute like
await navigator.credentials.get({
identity: {
providers: [{
// ...
signedOut: "signin" // defaults to "dismiss"
}]
}
}); @bvandersloot-mozilla does this sound more or less right to you? any intuition on where this should hang? There is also a related discussion on allowing users to "add/change accounts" when users are already signed-in, which we would expect not all IdPs would necessarily want to support (e.g. not all IdPs have the concept of "multiple accounts"), so maybe we need another flag like await navigator.credentials.get({
identity: {
providers: [{
// ...
signedOut: "signin", // defaults to "dismiss"
allowNewSession: true // defaults to false
}]
}
}); Another challenge here is (IdPs) supporting the combinatorial explosion of flags here, so another option here is to hard code a few known supported flows rather than individual flags with an enumeration of await navigator.credentials.get({
identity: {
providers: [{
// ...
mode: "button" || "widget"
}]
}
}); So maybe we can start with the coarse Another related discussion is that of Another consideration is whether this should be a configuration per-IdP or at the await navigator.credentials.get({
identity: {
mode: "button" || "widget"
providers: [{
// ...
}]
}
}); |
hm, I think RPs may want different behavior at different times. For example, they may want to show an account chooser onload but only if the user is logged in; but they may have a "sign in" button which should not fail silently. |
Yeah, I was thinking that IdPs would have the ability to have more than one So, RPs can still choose between two different |
I think that enumerating a set of supported flows may be painting ourselves into a corner. How does either proposal interact with a multiple-IDP use case? |
In this CL, we expose - behind a flag - a "mode" parameter in the FedCM API and plumb it to the browser process through the mojom interface. This starts allowing the FedCM API to degrade more gracefully when the user is *not* logged-in to the IdP. Specific feature request here from Mozilla: w3c-fedid/FedCM#442 (comment) The "mode" (={button, widget}) parameter controls the internal algorithms of FedCM to handle logged-out users. In mode=button, the browser opens a pop-up window when users are logged-out, whereas in mode=widget (the default) the prompt is just automatically dismissed. Part (pre-requisite) for this larger feature: w3c-fedid/FedCM#477 (comment) Privacy and Security Early Reviews: https://docs.google.com/document/d/1WtiG-JwlcuCJPI0EZdo61vxg6sjTAuxFFm5I2Jk4x6s/edit The browser implementation, that will actually change based on this flag, is being implemented in a separate CL (see gerrit CL dependency). Bug: 1429083 Change-Id: If9f6b453cc5e16c479b89a16191d010892bd0377 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4779439 Commit-Queue: Sam Goto <[email protected]> Reviewed-by: Yi Gu <[email protected]> Reviewed-by: Emily Stark <[email protected]> Cr-Commit-Position: refs/heads/main@{#1204181}
In this CL, behind a flag, we make the algorithm degrade gracefully for logged-out users when in "button" mode by opening a pop-up window that allows the user to sign-in to the IdP (as opposed to dismissing the request, when in "widget" mode)). This allows the FedCM API to support button flows where the user expects a fallback, as opposed to a dismissal. w3c-fedid/FedCM#442 (comment) Change-Id: Id1492f8f3e10fbd9e400b809caf64e90ac2806ca Bug: 1490588 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4790926 Commit-Queue: Sam Goto <[email protected]> Reviewed-by: Yi Gu <[email protected]> Cr-Commit-Position: refs/heads/main@{#1206673}
I've tried this with the multi-idp mode. As it is a global property, it seems to pop up the |
If that comment is about the Chrome flag, we haven't worked on that in a while so it is likely not working correctly at this point. In multi-idp mode, I'd expect the user to pick the IDP they want to sign in to, not for one popup per IDP to open. |
That's it (chrome flag), thanks. The behavior I observed was a popup per signed-out IdP. But I realize the multi-idp support is a WiP, so just adding a data point from testing. |
Interesting, thats really not what you'd want for a final version. As noted in the CG call I think the RP/Authentication Intermediary should be able top open a pop-up in this case to let the user choose how to proceed (not a browser mediated UI, or at least both options must be available) See also the implementation bug in Chrome to track this: https://bugs.chromium.org/p/chromium/issues/detail?id=1487268 |
@samuelgoto seems this should be a proposal under https://github.com/fedidcg/FedCM/tree/main/proposals ? |
2023-11-28 call: prototype exists in Chrome Canary, please test |
Just a small update on this: we built a prototype in chrome canaries with the following formulation: await navigator.credentials.get({
identity: {
mode: "button" || "widget"
providers: [{
// ...
}]
}
}); You can try this by flipping this flag in chrome canaries: What it does is that, on Any chance we have anyone around interested in giving this a try and letting us know if this behaves the way that they'd expect this to behave? |
FWIW - this is also already supported as an option in the demonstrator implementations (mode = button) on the RP side. |
Yes. This looks like the implementation I tested with multi-idp support above. I uploaded a demo video of how it acts in that case, for reference. |
I should add, that it behaves in the way described for a single IdP. |
I have no good suggestions of how to fix that for multi-idps, even if you moved the mode option into the provider's array (i.e., per-provider) I am not sure how the RP would know to set it differently per IdP (or even why it would do that), and would probably just set it the same for each provider anyway (so I think it makes sense to set globally as it is). I guess, as already suggested in this thread, you might need the user to select which IdP to use first before trying to retrieve accounts from it, and therefore before deciding if the sign-in popup is needed. |
Yeah, we'd probably have to have an "IDP selection" dialog if the user is not signed in to any of the IDPs, and if the user is signed in to at least one IDP the dialog should still let the user sign in to one of the others |
Don't forget that SeamlessAccess has a lot of experience with that IdP choosing process. Lessons to be learned there (and possibly code to use). |
@yi-gu re: feature detection, we could consider something like getClientCapabilities() which we recently added to WebAuthn L3. This could be useful for both FedCM and the Digital Credentials API. |
Thanks @timcappalli for the suggestion! That idea was brought up late 2023 when it was un-merged. Will take a closer look and we can discuss about it in the CG. |
Plan to share some update from the Chrome team on this topic in the next CG call. In addition, we could discuss about Tim's suggestion on feature detection. |
Question for @bvandersloot-mozilla - is the button mode as currently being tested in origin trials sufficient to resolve this issue? |
For context, here are some details on Chrome's FedCM button flow origin trial. From group discussion, we think IDP login for multi-IDP is a separate (harder) problem, as it requires the browser to take on the "nascar flag" UI. |
Yeah, the button flow is sufficient for our concern. We agree that multiple cold IDPs is a much harder problem, and may not be desirable for the browser to solve. |
We added some mocks for Android. They are not final and we will keep folks updated as we are getting closer to running Origin Trials in Chrome. |
There's not a lot of information in the Explainer post about the proposed Use Other Account API/extension here. Is it using an existing account chooser? If so, why is it called out as a new proposal? If it is different from (or a modification to) an existing account chooser, then there needs to be more info in order to perform security and privacy reviews. How is it different and how does it ensure that available accounts and current logged-in status is not leaked? |
Hi garykac@, |
OK, thank you for the clarification. I hoped that was the case, but ChromeStatus describes this as a proposed API, which makes it seem like a larger change than it actually is. |
Sorry for the confusion. It is indeed a new API like
but as you mentioned it was not a big API change with new privacy/security implications. |
Enabling an option in which the IDP can provide a way to be logged in (via a controlled call to window.open) and then immediately be dropped back into the account chooser would be nice! I discussed something related to this in fedidcg/proposals#3 but it could be adapted here. I'll add a comment with a general shape of the proposal.
The text was updated successfully, but these errors were encountered: