Why Your University Account and Personal Account Resolve to the Same Login
When a university and personal login return the same identity, the cause is usually email-based account matching, warm IdP sessions, or Microsoft tenant discovery. Here is how to trace and fix it.
The symptom
You choose your university account from the Microsoft or Google account picker, sign out, then choose your personal account. The app opens the same profile, same settings, same workspace. It looks like the two logins gave the same result.
Most of the time, the two accounts are still separate in the identity provider. The collision happens later. The app resolves two different identity records into one internal user.
Why this happens
1. The app uses email as the user key
Many authentication integrations store users by `email` or `preferred_username`. A university account and a personal account can share the same address—especially if you created a personal Microsoft account with your school email years ago, or if Google Workspace and consumer Gmail both accept the same mailbox.
If the app reads `email` from the token and does an upsert, both sign-ins map to the same row. The UI then looks identical.
The fix is to key users by issuer and subject: `iss + sub` for OIDC, or `idp_entity_id + nameid` for SAML. The [OIDC Core specification](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) defines `sub` as the stable identifier for the end user within the issuer.
2. The identity provider already has a warm session
If you sign in with Microsoft and your university session is still active in the browser, the authorization server may silently return that session to the application. This is common when the app uses `prompt=none`, omits `prompt=select_account`, or relies on a cached SSO cookie.
Microsoft’s [identity platform documentation](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow) explains that `prompt=select_account` forces the account picker to appear. Without it, the user can be silently signed in with the existing session.
3. Microsoft personal accounts and work or school accounts can share an address
Microsoft Entra ID treats a personal Microsoft account and a work or school account as different directory objects, even when the sign-in name is the same. If the app uses the common endpoint and discovers the tenant from the email domain, it can send the personal account into the university tenant—or vice versa.
This is why the same email can appear to choose two different accounts but still return one app identity.
4. Account linking logic is too permissive
Some apps try to link accounts automatically by treating the same email as the same user. That is only safe if the email is verified by the provider and the provider is trusted. Otherwise, a personal Google account and a university Google Workspace account with the same address will be merged by the app even though they are separate identities in Google.
How to debug it
1. Compare the identity claims from both sign-ins. For each login, capture `iss`, `sub`, `email`, and `tid` if Microsoft returns it.
2. If the two logins have different `iss` or `sub` but the app returns the same user, the bug is in the app’s user resolution or account linking.
3. If the two logins have the same `iss` and `sub`, the user is actually signing into the same upstream account. Check for a warm IdP session or shared browser profile.
4. Test with a clean browser profile or an incognito window. If the collision disappears, session reuse is likely.
5. Add `prompt=select_account` to the OIDC authorization request during testing, or use `ForceAuthn` in SAML.
A quick token comparison checks whether the two logins produce different `iss` and `sub` values. If the personal login shows a different `iss` and `sub` but the app still loads the same profile, the app is matching on `email`.
How Sapior helps
Sapior’s developer-tools approach is to make identity resolution visible instead of guessing. When an identity resolution bug appears, you should be able to trace the full path: the upstream `iss` and `sub`, the app’s account-linking decision, and the session that was issued.
For teams building SSO or account login flows, the rule is simple: never identify a returning user by email alone. Treat identity as two fields—issuer and subject—and keep email as a display property.