In this article
July 23, 2026
July 23, 2026

AuthKit now syncs identity provider email changes automatically

When a user's email changes in their IdP, AuthKit now propagates it automatically from SSO and Directory Sync — so app identity never drifts out of sync.

Explore with AI
Open in ChatGPT
Open in Claude
Open in Perplexity

Email addresses are supposed to be stable. In practice they aren't. Someone gets married and changes their name, a company migrates to a new domain, an acquisition triggers a rebrand — and the address your app has been treating as a user's identity is suddenly wrong at the source. The identity provider updates. Your app doesn't hear about it. That gap is identity drift, and it fails quietly.

Identity drift is a silent failure mode

When a user's email changes in their identity provider, their app identity falls out of sync with what SSO and Directory Sync report. The name change, the domain migration, the rebrand — none of them announce themselves to your application. The user keeps signing in. Their profile keeps loading. Nothing throws an error.

Then the edges start to fray. Notifications route to an address the user no longer reads. Support can't match the person in front of them to the record in the system. An admin looks at the directory, sees the new email, looks at your app, sees the old one, and files a bug. Every one of these is downstream of the same root cause: two systems that should agree about who someone is, and no mechanism keeping them aligned.

IMAGE: two abstract database or record nodes connected by a flowing arrow, one node updating to match the other, in a clean deep-blue and off-white palette with a subtle grid, conveying two systems coming back into alignment

AuthKit now propagates the change for you

AuthKit automatically syncs email address changes from the identity provider to the AuthKit user. When the address changes upstream, AuthKit updates its own record to match — no webhook to wire up, no reconciliation job to run, no support ticket to trigger a manual edit.

There are two paths the change can take, and they line up with the two ways AuthKit already learns about your users:

  • From the SSO profile, the change propagates on the user's next login.
  • From Directory Sync, the change propagates on the next directory update.

When both SSO and Directory Sync are connected, Directory Sync takes precedence. The directory is the authoritative source of record for who exists in an organization, so when it and the SSO profile disagree, AuthKit trusts the directory. That gives you a predictable answer instead of a race between two channels.

No clobbering, no surprise merges

Automatic propagation raises an obvious question: what happens when the new email already belongs to someone else? Two users on the same domain, a recycled address, a typo in the IdP — any of these could point one person's new email at another person's existing account.

AuthKit skips it. Any change where the target email already belongs to another user is skipped, so there is no clobbering or surprise account merges. The unsafe case is the one it refuses to perform. You get the convenience of automatic sync for the common case and a hard stop on the case that would corrupt your user table.

What you need to do

Nothing. If your users authenticate through SSO or come in through Directory Sync, email changes from the provider now flow to their AuthKit user without any work on your side. The drift closes on the next login or the next directory update, whichever your setup uses.

For the full behavior — including how the two sources interact and the exact conditions under which a change is applied or skipped — see the AuthKit email changes documentation.