Add interaction_required error response

[aaronpk]

There are many scenarios in which the user is logged in to the IdP but the IdP does not want to issue a token in the assertion endpoint response, such as wanting to re-authenticate the user, or needing to get the user's consent when the RP asks for API access, etc. This is an alternative way to solve the problem described in w3c-fedid/custom-requests#1.

Proposal: Define an error code interaction_required which the IdP can return from the ID assertion endpoint. When the browser sees this response, it shows a prompt telling the user they need to continue at the IdP:

Clicking "Continue" would unblock the cross-site restrictions between the RP and IdP, and would return the error code and configURL to the RP, and the RP would start a new flow with the IdP using whatever protocol it normally would.

    const identityCredential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            configURL: "any",
            clientId: window.location.origin+"/"
          },
        ],
      },
    }).catch(e => {
      if(e.code == "interaction_required") {
        // Get IdP configURL from e.configURL
        // Start a new OAuth/OIDC/whatever flow with the IdP as normal
      } else {
        // A normal unrecoverable error
      }
    });

The main benefit of this over w3c-fedid/custom-requests#1 is that FedCM gets more out of the way of the flow, while letting the RP use whatever protocol it wants to talk to the IdP. The challenge I see with w3c-fedid/custom-requests#1 is that FedCM is sitting in the middle of the protocol, so might not work in some cases depending on how the protocol works. This also sidesteps the issues talked about in the thread of how the IdP can signal to the browser that the popup flow is done.

[ThisIsMissEm]

I was thinking a bit more about this, and was thinking: why not let the assertion endpoint return a URL that is the fully formed authorization URL that would be needed to complete the flow?

That would save the developer from needing to interact with the IdP to fetch configuration, then construct an authorization URL.

Additionally we could include the "loginHint" to let the IdP know which account we're trying to authorise for.

[achimschloss]

See here - https://github.com/fedidcg/FedCM/issues/555. Can be tested behind a feature flag already

[aaronpk]

@achimschloss see the notes above about why this is different from w3c-fedid/custom-requests#1

[npm1]

Would auto granting SAA after FedCM is successful (#501) solve this use case? I think that is basically what you mean by 'unblock the cross-site restrictions between the RP and IdP' anyways. So the flow would look like this:

• FedCM dialog is shown.
• User confirms using an account.
• Id assertion fetch returns a dummy token (not used).
• IdP invokes SAA and now the RP and IdP can communicate however they want.

[yi-gu]

+1 to what npm said. More details about SAA auto grant can be found here. It's currently in Origin Trial in M126 so you could test if it meets the requirement.

It's worth noting that the SAA auto-grant only works when there's an IdP iframe on the RP page because the SAA API must be used from an iframe. The iframe also needs the FedCM permissions policy which is specified by the embedder.

[aaronpk]

Actually yeah, we could do it that way, especially if the IdP can return JSON data back to the RP (#578).

• FedCM dialog is shown
• User confirms using an account
• ID assertion fetch returns JSON data with interaction_required string (probably defined in an OAuth profile of FedCM??)
• IdP invokes SAA (hopefully without any further dialogs being shown to the user?)
• RP starts a new OAuth flow to the IdP without any restrictions

(How does the IdP invoke the SAA when the browser is at the RP this whole time?)

[aaronpk]

Oh sorry I didn't see the iframe note. I don't love that this requires an iframe, since nothing else about this flow does. Is there an option of triggering the SAA request in an HTTP header instead?

[npm1]

Well, SAA in particular is to grant cookies to the iframe. How are you envisioning the communication between RP and IDP to take place without IDP having an iframe? In particular, where does the IDP have access to their first party cookies in order to establish this communication?

[aaronpk]

This is based on my understanding that redirects between sites with query parameters will eventually get blocked too. So all I need is for the RP to be able to do a redirect with query parameters that are preserved intact when it gets to the IDP.

[yi-gu]

There are explorations w.r.t. requesting/granting storage access from top level frame (e.g. rSAFor, storage access headers). But one problem as discussed in the PrivacyCG is how to ensure RP opt-in in those cases before auto-granting storage access based on a FedCM permission grant.

[ThisIsMissEm]

Yeah, I'd strongly discourage usage of iframes here due to security concerns: it encourages users to enter credentials potentially without knowing to where.

I was envisioning a standard SSO flow from this point

[aaronpk]

Yeah, the iframe would only serve the purpose of triggering the SAA request, and then you'd have to do a regular SSO redirect, which is why I don't like requiring the iframe here.

[npm1]

Oh ok. So really all needed is that query parameters from redirect to IdP and back to RP are not removed by the browser?

[philsmart]

If we are worried about future bounce tracking mitigations (I am), perhaps the IdP registration API (#240) can provide an alternative signal that the IdP is not a tracking site and the parameters should not be stripped (rather than dealing with the complexities of iframes).

[panva]

@philsmart The fact that there's an IdP<>RP<>Account connection should be enough without the need to bring up another dialog for a statically configured IdP, for which the IdP registration API is not intended anyway.

[philsmart]

@panva that makes sense if you wanted to use FedCM (I assume that is where the connection is established). I am just trying to work out if any of these mechanisms could offer a lightweight solution to enable existing, unchanged, redirect-based authentication flows (SAML, OAuth/OIDC) if navigational tracking mitigations broke them.

That said, my understanding is that these mitigations are being developed not to disrupt existing identity flows — and are separate to FedCM anyway.

[samuelgoto]

The benefit of #590 (comment) in comparison to the original proposal in this issue is that #590 (comment) doesn't show the browser error UI, and instead can be entirely implemented between the RP and the IdP.