How your Google account binds to a person
Your email address says who you claim to be; Google's stable identifier for your account is the proof. Connect records that identifier the first time you sign in and compares it every time afterwards. If a different Google account arrives with the same email address, the sign-in is refused as a mismatch — and no amount of retrying changes it.
Email is the key, the subject is the proof#
Every Google account has a stable identifier that does not change when the display name changes, when the address is re-cased, or when the account is renamed. Connect stores that identifier against the user the first time it sees it, and from then on it is what the account is judged by.
This matters because an email address is not a strong identity on its own. Addresses are recycled inside organisations, aliases point at different people over time, and a domain can be re-issued. Binding to the identifier rather than the address means a later Google account with the same address cannot inherit an existing Connect user's history, memory or workspace by simply arriving.
Two stores, one answer#
The binding lives in the platform user record. For the operator's own account there is also an older single-owner identity row, kept from an earlier version of Connect rather than migrated away, because deleting a working identity record to tidy up is a poor trade.
The rule is *first non-empty of the two, in that order*: the platform user record if it has a binding, otherwise the legacy row. Everything that needs to know what the binding is — a screen showing the linked account, a fixture creating a session for a test — reads it through one accessor so that all of them get the same answer.
| Case | Store consulted | Result |
|---|---|---|
| A customer signing in | The platform user record | The identifier stored there, or empty on a first sign-in |
| The operator, bound in the newer store | The platform user record | That identifier |
| The operator, bound only in the legacy row | The platform user record, then the legacy row | The legacy identifier, which is then copied forward |
| Nobody bound yet | Both, both empty | Empty — the arriving identifier is adopted as the binding |
What a mismatch means#
The refusal says that this Google account is not the one previously bound to this Connect user. It is not a password failure, not a network problem, and not something a second attempt will resolve. Something has genuinely changed about which Google account owns that address.
- The address was re-created at Google — deleted and made again, or re-issued to a new person in the same organisation. Same address, different account, different identifier.
- The organisation migrated to a different Google tenancy, and the accounts on the far side are new accounts as far as any relying application is concerned.
- Somebody is signing in with an account that merely shares the address, which is precisely the case the binding exists to stop.
The resolution is administrative rather than technical: somebody with the authority to say which Google account now owns that Connect user has to make that change deliberately. A sign-in flow that let the arriving account overwrite the binding would make the check decorative.
Questions#
I changed my name at Google — will that break my sign-in?
No. The binding is to the account's stable identifier, which does not change when your display name or your address's capitalisation does. What breaks it is a genuinely different account arriving with the same address.
Can I move my Connect user to a new Google account myself?
Not through the sign-in flow, deliberately. Allowing the arriving account to take over an existing binding would remove the only protection the binding provides. It needs somebody with the authority to make that change on purpose.
Why does the mismatch message not say which account it expected?
Because it would be telling an unauthenticated caller about somebody else's identity. The refusal is specific enough to distinguish it from a transient failure — retrying will not help — and no more specific than that.