We’re migrating a Node/Express app from another OIDC identity provider
to Auth0. Sessions are server-side (express-session + Postgres), and our
users table currently keys off the old provider’s OIDC sub.
Our plan is to stop using the IdP subject as our primary key: add
auth_provider / auth_subject columns, freeze our internal user id so
no foreign keys move, and resolve identity on login as
- match (auth_provider, auth_subject) — returning user
- else match on verified email — existing user migrating over
- else create a new user
That handles the large majority of our users cleanly.
The problem is users who originally signed up via Sign in with Apple and
chose “Hide My Email”. Their stored address is a private relay address
that was minted under the old provider’s Apple developer team. Apple
scopes relay addresses per team, so once we configure the Apple social
connection under our own team, the same person arrives with a different
relay address. Step 2 can’t match, and they’d get a new empty account
while their existing one is orphaned.
Two questions:
-
Is there an Auth0-native way to handle this — anything in account
linking, or an Action at polate an Apple
identity whose email has changed? Or is the relay address genuinely
the only signal available autside Auth0?
-
For anyone who has migratedom another
provider: did you pre-emptively re-link those users before cutover
(one-time token emailed to handle it some
other way? Interested in what actually worked in practice.
Hi @Samama251251
Welcome to the Auth0 Community!
I understand that you are having issues in migrating users to Auth0 from an external OIDC provider due to the Apple Relay email not matching with the existing user profile.
This is a challenging architectural hurdle when migrating away from an identity provider that managed Sign in with Apple (SIWA) under their own Apple Developer Team ID.
Because Apple strictly scopes both the user sub (subject identifier) and the private relay email addresses to the Team ID, changing teams means the same human user arrives as a completely different entity with no matching identifiers as stated by Apple’s Transferring your apps and users to another team article.
Option 1:
In order to migrate these users, follow this official solution provided by Apple:
User Transfer IDs (Requires Old IdP Cooperation)
If the old identity provider is cooperative, Apple provides an official migration API specifically for team transfers (such as when an app is transferred or when moving off a third-party platform’s Team ID).
-
How it works: The transferring team (old IdP) uses Apple’s user_migration_info endpoint to generate a unique Transfer ID for each user sub. Your new team (Team B) then exchanges these Transfer IDs with Apple to obtain the new sub and the new private relay email for those users before they log in.
-
Auth0 Integration: If you obtain these mapped pairs, you can pre-emptively import the mapped users into Auth0 or update your database with the new sub and new relay email.
This information can be found under Apple’s Technote TN3159: Migrating Sign in with Apple users for an app transfer.
Option 2:
If you cannot use Apple’s migration API, the recommended approach would be to build a Just-In-Time (JIT) Account Linking flow using an Auth0 Post-Login Action.
-
When a user logs in with Apple, your Action will detect that they have a “new” Apple profile but no corresponding account in your Postgres database.
-
The Action redirects the user to a custom “Claim Your Account” page on your Express app (using api.redirect.sendUserTo()).
-
The Express app prompts them to verify their identity (e.g., by logging in with an alternative method or verifying their old email).
-
Once verified, your backend links the new Apple sub to the old Postgres record, updates the email column to the new relay email, and redirects them back to Auth0 to complete the login.
Kind Regards,
Nik