Azure AD B2C中newUser与auth_time声明生命周期及刷新异常问询

Great question—this is exactly the kind of underdocumented auth behavior that can cause headaches when building reliable check logic. Let’s break down what’s happening with both claims:

newUser Claim #

• The newUser: true value is set once during the user’s first successful authentication flow (i.e., right after they sign up). Unlike some claims tied to a single token’s lifecycle, many identity providers retain this claim across refresh token exchanges.
• As long as the user’s session remains active (via valid refresh tokens), every new access token issued will still include newUser: true. The only time this claim will disappear or change is if the user logs out completely and then logs back in (though some providers might still keep it, depending on their implementation) or if the refresh token is revoked/expired.
• Key note: This claim marks the user’s first authentication event, not the token’s issuance. So it’s not meant to indicate "this is a fresh token"—it’s meant to signal "this user just completed their first sign-up/login".

auth_time Claim #

• The auth_time claim represents the timestamp of the user’s last interactive authentication (e.g., entering a password, completing MFA). When you use a refresh token to get a new access token, this is a non-interactive session renewal—no user input is required.
• Most identity providers will omit auth_time from tokens issued via refresh flows because there’s no new interactive authentication event. The old token’s auth_time disappears because that token has expired, and the new token doesn’t include it since no new auth action happened.
• If you need to track when a user last actively authenticated, you’ll need to store this timestamp in your own backend when the user first logs in (when auth_time is present in the token). Don’t rely on refresh tokens to update this value—they won’t.

Practical Recommendations for Your Check Logic #

• For newUser: Don’t rely solely on the token claim to trigger first-time user flows (like onboarding). Instead, add a flag to your user database (e.g., has_completed_onboarding: boolean) and toggle it once the user finishes the flow. This avoids re-triggering onboarding if the user refreshes their token multiple times.
• For auth_time: Use the value from the initial login token to update your backend session record. When you need to check if a user has authenticated recently, reference your stored timestamp instead of looking for the claim in refresh-issued tokens.

内容的提问来源于stack exchange，提问作者Simon W