Lock subframes to same identity as parent frames

[will-bartlett]

In some cases, it's desirable to require that sub frames use the same account as parent frames. For example, at Microsoft, Teams, Azure Dev Ops, and Sharepoint all have ecosystems with plugins, including both first party and third party plugins. For these ecosystems, our ideal behavior would be that after the user selects an account in the top-frame, the sub frames can only get the same account, and prompts that would allow the user to select an account are minimal (i.e. privacy, but not selection).

As the spec currently reads, it sounds like iframes can use FedCM with an appropriate permission policy, and there is discussion about the appropriate privacy treatment in the UI in #725 . However, those discussions do not prevent a user from e.g. selecting account1 in the top frame and account2 in a sub frame. Such selections will not typically result in reasonable behavior, as it may not even be obvious to the user which UI elements are part of the top frame and which UI elements are part of the sub frame.

This setup results in some undesirable implementation characteristics. The top frame must pass a login_hint down to the sub frame, identifying the user to the sub frame before the user has consent to the RP, so that the RP can pass the login_hint in IdentityProviderRequestOptions. It would be nice if the top frame could set some attribute or permission policy on the iframe that says the iframe is only allowed to sign the same user in, that causes the provider and login_hint from the top-frame selected account to be automatically passed on the iframe's navigator.credentials.get request, in a way that is privacy preserving (that does not allow the iframe to see the login_hint until the user consents to the RP). It would also be nice to save implementors of such super-apps from having to pass the login_hints around.

[wseltzer]

Discussed 23 September minutes

[hlflanagan]

Discussed 28 October 2025

[ThisIsMissEm]

During TPAC, I suggested that rather than the initial navigator.credentials.get in the top frame saying "this token can be shared subframes based on policy", and then having to deal with tokens going to multiple unrelated origins, we could instead provide an API that allows for mediation and token exchange.

In OAuth there's RFC 8693 OAuth 2.0 Token Exchange where a client can use Security Token Service (STS) mechanism to make a request saying "I already have this token, I would like to exchange this for a token that this target resource can use", building on that concept, I'd propose an alternative to what Emily outlined at TPAC which is as follows:

• An API for doing mediated credential retrieval, e.g., navigator.credentials.getMediated(...) which when used triggers an event in the top frame, allowing a decision on whether or not it wants to mediate credentials for the origin of the subframe.
• The top frame would receive an event credentialMediationRequested, for which it can either allow the request, or it can block it. The event contains information on the subframe making the request (e.g., origin, url)
• When the top frame approves the mediation request, the browser takes over and communicates to the IDP "I have this token/identity assertion for this origin (top frame), it would like to delegate this credential to target origin (sub frame), please give me a new token for that target origin"
• Once the IDP returns the new mediated token (which can be chained to the original identity assertion, such that revocation of the top frame's identity assertion revokes the sub frame's identity assertion token too), the browser automatically passes that token back to the awaited promise of the sub frame which called navigator.credentials.getMediated(...)

Importantly:

• top frame and sub frame get distinct identity assertion tokens, however the sub frame's assertion is chained to the top frame's assertion
• the top frame can dynamically choose which origins it allows, and has enough information to make an informed choice, rather than a wide policy like "allow all sub frames" or "allow all same-origin sub frames"
• the browser largely handles the mediation, and can enable logging out of the top frame to revoke the sub frame's identity assertion token.
• I think this would provide a better security model too, since an iframe dynamically injected into the top frame wouldn't automatically get credentials, which I think would be the case with a policy like "any auth"

There's also a related OAuth internet draft for OAuth Identity and Authorization Chaining Across Domains which may be relevant here.

[ThisIsMissEm]

There's also this internet draft that was just posted to the OAuth WG mailing list, which is very close to what I'm describing above: https://liuchunchi.com/li-oauth-delegated-authorization/draft-li-oauth-delegated-authorization.html

[will-bartlett]

I think what's asked here is a bit different that multi-level delegation (OAuth is already a delegated access protocol, so draft-li-oauth-delegated-authorization-latest appears to be a two-level delegated access protocol). The idea here for FedCM is that a subframe could access content directly, content that the parent frame might not have access to. Consider e.g. Microsoft Teams embedding an Azure Dev Ops (ADO) plugin. The ADO plugin should have access to ADO data like pull requests or whatever that Teams does not have access to. The client (Teams) isn't delegating its own access to a delegated party (ADO). Rather, two clients (Teams and ADO) both have their own access, which they use and don't share with each other.

[will-bartlett]

Maybe a cross-company example is better. Fabrikam is a Microsoft Entra and Teams customer that operates custom machines that produce garments. They create a garment assembly line control plugin for Teams that is hosted on its own domain and can send commands to the garment assembly machines if the user is a member of the appropriate security group. Teams does not and should not have permission to send command to garment assembly machines. However, both Teams and the garment assembly machine control resource operate on Entra identities. Indeed, all Teams plugins operate on Entra identities, and so the ask is to allow Teams to do something that accelerates the FedCM user selection process for plugins (iframes) to auto-select the same identity as the user selected for Teams.

[ThisIsMissEm]

@will-bartlett this sounds like different to how it was described at TPAC when I wrote the above comment in response. I think the credential request is still probably "mediated" by the top frame, in that the top frame is specifying the policy for whether or not to allow the credentials request.

In the case that both Fabrikam and Teams are using the same IDP and same account, then I'm not sure why you wouldn't want the authorization server to return a new token for the subframe which is anchored back to the token that was generated for the top frame. Then if the top frame's token gets compromised, the AS can revoke all the tokens for that page.

Would there ever be a case where the top frame and subframe deliberately use a different IDP or account?

[ThisIsMissEm]

@will-bartlett specifically, I'm not saying that the top frame gets the subframe's access token, no, not at all. Just that the subframe's token is bound to the top frames token, such that revocation of a compromised token for the top frame also revokes the subframe's token.

[will-bartlett]

In the case that both Fabrikam and Teams are using the same IDP and same account, then I'm not sure why you wouldn't want the authorization server to return a new token for the subframe which is anchored back to the token that was generated for the top frame. Then if the top frame's token gets compromised, the AS can revoke all the tokens for that page.

What is the benefit of this? We have two origins - teams.example and fabrikam.example. FedCM will deliver two tokens (T1 and T2) directly to their destinations - T1 to teams.example and T2 to fabrikam.example. Why would we want to revoke T2 after a compromise of teams.example?

From my perspective, this is one of the major benefits of FedCM. Today, an OAuth redirect returns T2 to teams.example, and then teams.example passes T2 from teams.example to fabrikam.example. That means that a compromise of teams.example compromises fabrikam.example (and so, a revocation of teams.example should revoke fabrikam.example). Tomorrow, with FedCM, FedCM returns T2 directly to fabrikam.example. That means that a compromise of teams.example doesn't compromise fabrikam.example - which is great for security. Assume third party cookies are disabled for this example.

That's all to say - FedCM is an improvement over status quo because the security of a flow where domain2 is embedded in domain1 depends only on domain2 (and the IdP), where previously it depended on both domain2 and domain1 (and the IdP). As for revocation - I would revoke a token if any of the security dependencies were compromised - but the fewer revocations the better - and FedCM => fewer security dependencies => fewer revocations.

[ThisIsMissEm]

@will-bartlett because anything that manages to execute something in the context of the top frame can access the sub frames via the DOM (afaik). So a security breach in the top frame from something would implicitly be a security breach in the subframe, so both tokens would potentially leak.

It's fabrikam.example in the context of teams.example — hence binding the token to that context.

[will-bartlett]

@will-bartlett because anything that manages to execute something in the context of the top frame can access the sub frames via the DOM (afaik).

No, not cross-origin.

The only thing a top frame can really do with a cross origin iframe is change its size and positioning and z-index. This is usually enough for "clickjacking" - the top frame manipulates the size and positioning of the sub-frame so that critical choices (like "add to cart" and "purchase") are invisible and under the user's mouse. But that's it. The top frame cannot add or remove elements from the iframe or grab at variables, localStorage, or sessionStorage from the iframe (which is where the token will be).