Azure AD B2C User Flow migration: password hash handling and active sessions during cutover

Direct Answer

• Graph API on‑the‑fly import does not preserve the existing password hash. You must supply a clear‑text password; Azure AD B2C will hash it internally. Users who sign in during the overlap will either use the original password (validated by the old flow) or the new password (validated by the new flow).
• Tokens issued by the old flow stay valid until their natural expiration because the tenant’s signing keys and token lifetime policies are unchanged. A refresh request will continue to succeed after the old flow is disabled, so sessions expire gracefully.
• The old flow can be safely disabled only after the maximum configured token lifetime (access token + any sliding refresh‑token window) has elapsed for all active sessions. Disabling earlier forces an invalid_grant on refresh and logs users out immediately.

Why this is true

• Password handling: The Azure AD B2C Graph API requires a passwordProfile with a clear‑text password when creating a user. The API does not accept pre‑computed hashes, so the old hash cannot be carried over.
• Token validation: Token validation is performed against the tenant’s signing keys, which are not tied to a specific user flow. Switching flows does not change these keys unless you explicitly rotate them.
• Session expiry: Refresh tokens in B2C have a sliding window (default 24 h). As long as the window is not exceeded, a token refresh will succeed even if the signing flow is disabled.

Practical Steps for Your Cutover

1. Clone your B2C tenant for testing.
   • Create two identical user flows: old-flow and new-flow.
   • Ensure token lifetimes and signing keys match exactly.
2. Import a small set of users into new-flow via Graph API, supplying a known clear‑text password for each.
   • Example request (pseudo):

     POST https://graph.microsoft.com/v1.0/identityUserFlows/{new-flow-id}/users
     {
       "accountEnabled": true,
       "displayName": "Test User",
       "mailNickname": "testuser",
       "userPrincipalName": "[contact removed]",
       "passwordProfile": {
         "password": "P@ssw0rd123",
         "forceChangePasswordNextSignIn": false
       }
     }
     

3. During the overlap period:
   • Users may sign in with either the old password (old flow) or the new password (new flow).
   • Verify that tokens obtained via the old flow remain valid after disabling the old flow by waiting until the access‑token expiry and attempting a token refresh.
4. Determine the maximum token lifetime (e.g., access token 1 h, refresh token 24 h sliding). Wait at least that long after the last user sign‑in before disabling old-flow.
5. Disable old-flow only after the waiting period.
6. Monitor for invalid_grant errors on refresh; if they appear before the expected window, adjust the wait time or review token policies.

Missing Diagnostic Detail

To fine‑tune the safe disable time, confirm the exact refresh‑token lifetime configured for your tenant. If it differs from the default 24 hours, adjust the waiting period accordingly.

Takeaway

Preserve user experience by keeping token lifetimes and signing keys identical across flows, import users with clear‑text passwords, and wait for the longest token lifetime before retiring the old flow.