The credential cache you cleared is on another device
We removed every application from that vendor off a phone, restarted it, reinstalled one, and it still offered the account we had spent an hour deleting.
An organisation moves to a new identity tenant. Users keep the same email address; only the account behind it changes. On most machines the desktop mail client picks up the new account without complaint. On two of them it does not. You type the new address, and it asks for the password of the old one.
So you start clearing things, in roughly this order, over roughly a morning.
- Remove and re-add the account. No change.
- Reset the application container. No change.
- Delete the identity entries from the credential store. No change.
- Sign out at the identity provider so no browser session survives. No change.
- On the phone, delete every application from that vendor, restart it, reinstall one. It offers the old account on first launch.
That last result should be impossible. A freshly installed application, on a device with nothing left to read, cannot know an account you have never given it.
What is actually happening
The credential store is not one store. There is a local one and a cloud-synced one, and the tooling opens on the local one by default. The tokens were in both, and the synced half was being restored from the user's other devices as fast as we removed it.
That accounts for every result above. It survives an application reinstall because it does not belong to the application. It survives wiping a device because it does not live on the device. And it stays invisible for as long as you are searching the store the interface happened to open on.
The giveaway, once we looked in the right place, was that the token entries were named after the old tenant's identifier. Several had been rewritten that morning, while we were busy clearing everything else.
The fix
Search both stores, not just the default one, and quit every application from that vendor first so nothing rewrites the entries while you work. Delete the access tokens and the shared authentication broker entries. Leave saved passwords, backup blobs and certificates alone.
Because the synced half replicates, removing those entries on one machine removes them from that user's other devices too. The same property that made it unkillable makes the fix travel.
Prove it is the client before you take the client apart
We spent hours on two machines before establishing that the machines could not be at fault. A few seconds of server-side checking would have said so at the start. Most identity providers expose an unauthenticated endpoint that reports which tenant an address belongs to and whether the account exists. Ours confirmed the address resolved correctly and offered no redirect anywhere.
Confirm it from the other direction too. If a private browser window signs the user in correctly, the account is healthy and only the local token state is wrong. That single test splits the problem in half and costs nothing, and it is worth doing before the first deletion rather than after the twentieth.
The general shape
Any credential or configuration store that synchronises between a user's devices turns "clear the cache" from a local operation into a distributed one. Clearing device A while device B still holds the item does not clear anything. It schedules a restore.
When something you have deleted keeps coming back, stop deleting it harder and ask what else holds a copy.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.