v136 · identity
Conflict Resolver
When multiple IdPs return accounts in a single navigator.credentials.get() call, the browser groups them by IdP in the chooser. This simulator shows what happens when the same email appears in both — whether it's treated as the same identity or two separate accounts — and how the chooser is structured.
FedCM is browser-mediated — simulating chooser logic in-page.
Chrome 136 supports multiple IdPs in a single
navigator.credentials.get() call. Each IdP's accounts are shown in separate sections. If the same email appears in both IdPs, the user sees two entries — they are different credentials (different IdP tokens), not duplicates. The user picks which IdP to authenticate through.
Configure IdP accounts
IdP A
https://idp-a.example.com
IdP B
https://idp-b.example.com
Overlap analysis
Chooser preview
Click "Simulate chooser" to preview.
Why overlapping emails are NOT duplicates
// Even if the same email@example.com appears in both IdPs,
// they are distinct credentials:
// - IdP A issues its own access token signed with idp-a.example.com
// - IdP B issues its own access token signed with idp-b.example.com
//
// The relying party may accept both (login with Google OR Apple),
// but the tokens are not interchangeable.
//
// Chrome 136 multi-IdP: both credentials are shown, grouped by IdP.
// The user chooses WHICH IdP to sign in through.
const { token } = await navigator.credentials.get({
identity: {
providers: [
{ configURL: 'https://idp-a.example.com/fedcm.json', clientId: 'app123' },
{ configURL: 'https://idp-b.example.com/fedcm.json', clientId: 'app456' },
]
}
});
// token is from whichever IdP the user selected