You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
TL;DR: Should the FedCM specifications and/or documentation more emphatically warn against device exfiltration attacks?
Context:
/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.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
The text was updated successfully, but these errors were encountered: