# Migrating to Auth0 from another OIDC provider. linking existing users when Apple relay emails don't match **URL:** \ **Category:** Get Help\ **Tags:** apple, migration, account-link\ **Created:** [August 3, 2026, 1:27pm UTC](https://community.auth0.com/t/migrating-to-auth0-from-another-oidc-provider-linking-existing-users-when-apple-relay-emails-dont-match/202225 "2026-08-03T13:27:04Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Samama251251](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/samama251251/32/80228_2.png) [@Samama251251](https://community.auth0.com/u/Samama251251)\ **Post date:** [August 3, 2026, 1:27pm UTC](https://community.auth0.com/t/migrating-to-auth0-from-another-oidc-provider-linking-existing-users-when-apple-relay-emails-dont-match/202225/1 "2026-08-03T13:27:04Z")
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 1. match (auth\_provider, auth\_subject) — returning user 2. else match on verified email — existing user migrating over 3. 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: 1. 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? 2. 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. ---
**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\ **Post date:** [August 3, 2026, 6:52pm UTC](https://community.auth0.com/t/migrating-to-auth0-from-another-oidc-provider-linking-existing-users-when-apple-relay-emails-dont-match/202225/3 "2026-08-03T18:52:12Z")
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](https://developer.apple.com/documentation/signinwithapple/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**](https://developer.apple.com/documentation/technotes/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 ---
**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\ **Post date:** [August 5, 2026, 6:52pm UTC](https://community.auth0.com/t/migrating-to-auth0-from-another-oidc-provider-linking-existing-users-when-apple-relay-emails-dont-match/202225/4 "2026-08-05T18:52:29Z")
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.