Clarify the necessity to protect against device exfil attacks

[gioele-antoci]

TL;DR: Should the FedCM specifications and/or documentation more emphatically warn against device exfiltration attacks?

Context:

• FedCM does not take a stance on how Relying Parties (RPs) and Identity Providers (IDPs) secure the authentication exchange after the /assertion endpoint.
• The /assertion endpoint returns a token to the front-end channel. The RP's front end is expected to submit the token to the RP's back end to ultimately open a session on the RP.
• Passing the token through the front-end channel exposes it to device exfiltration attacks (e.g., a malicious script running on a compromised RP might monkey-patch fetch and steal the token).

RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using HttpOnly cookies.

Alternative Proposal:
Instead of returning the token from /assertion, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.

Related to: #536 and #599

[samuelgoto]

RPs should be effectively guided towards implementing a nonce/PKCE flow while associating the authentication exchange with that specific device, for example, by using HttpOnly cookies.

Yeah, that makes sense. A couple of questions:

a) Can we do this as part of the #599 ? @aaronpk WDYT?
b) As @bvandersloot-mozilla suggested, is there anything that the browser can do to help? Would some opt-in validation help? E.g. maybe the browser could understand @aaronpk profile and throw errors when certain parameters aren't used?

Instead of returning the token from /assertion, should user agents invoke an RP's callback defined in the configuration file? This approach would alleviate some of the implementation complexity for FedCM RPs and IDPs.

I'd be happy to explore options where the browser can help make the system more secure. I'd still want to do that within the boundaries of what would show up in #599.

[philsmart]

I'd +1 a way for FedCM to send the token directly to the RP's back-end without making it available to the RP's front-end via JS. Maybe either could be supported, allowing both 'public' (browser-based) and 'confidential' (server-based) RP clients.

It even seems common these days for public applications/clients e.g. a Single Page Application, to use a backend, server-side, component to manage tokens, the Backend For Frontend Pattern (BFF).

Overall I think server-side authentication is very common (swapping security tokens for sessions on the backend, managed by HttpOnly session cookies on the frontend), and those would not need whatever comes back from the IdP accessible via JS in the front-end.

[cbiesinger]

@philsmart could you talk a bit how you envision this working concretely, especially for SPAs? I assume you want the browser to make a credentialed HTTPS request to some URL with the token, but how does this interact with the JS API? How does the page know that a token is now available?

[philsmart]

@cbiesinger; I was thinking (and maybe @gioele-antoci was thinking similarly) that both the existing mode could be supported, where the token is resolved directly from the n.c.get call, and a new mode where FedCM sends the token directly to an endpoint on the RP, and the n.c.get call returns whatever the RP wants after it consumes the token, or nothing at all (the RP might need to create or rotate a HttpOnly session identifier cookie of some kind i.e. set a cookie in response to the FedCM call).

An SPA can then use it as you suggest, in the same way it works now. But a more traditional server-side rendered (and importantly, server-side authenticated) site would just use the session cookie, and the server would make further HTTP calls using the token(s) (if required). Noting that, as Aaron points out in #599, server-side authentication and token management is still possible even for SPAs using the Backend For Frontend (BFF) architecture.