{"version":"2.1.271","anchor":"401-handler-auth-refresh-now-distinguishes-uses-login-off-f","canonical_anchor":"401-handler-auth-refresh-now-distinguishes-uses-login-off-f","heading":"OAuth token refresh now tracks a separate 'opted-in' bucket for non-first-party logins","tier":"internal","area":"Auth","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/401-handler-auth-refresh-now-distinguishes-uses-login-off-f","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### OAuth token refresh now tracks a separate 'opted-in' bucket for non-first-party logins\n\n401 handling and OAuth token refresh now track sessions that use login off the first-party service in their own dedup bucket\n\n**Unclear.** The finding does not explain what a 'login off first-party' session is or when it applies.\n\n**What**\n\nThe 401 (unauthorized) retry handler and the OAuth credential-refresh logic now carry an explicit `usesLoginOffFirstParty` flag through the refresh flow.\n\n- The 401 retry handler and its refresh-dedup helper gained a `usesLoginOffFirstParty` option, using a new helper that checks whether login isn't happening through the first-party service, to build a distinct dedup key.\n\n- Pending refresh checks for these sessions are now tracked in a separate `pendingOptedInRefreshChecks` map instead of the regular `pendingRefreshChecks` map.\n\n- The core OAuth-401 recovery function now takes an explicit `usesLoginOffFirstParty` parameter (default `false`) and passes it into the credential-refresh call, which determines which of the two pending-check buckets the refresh is tracked in.\n\n**Why**\n\nSeparating refresh tracking for non-first-party logins avoids mixing their dedup state with regular first-party refresh checks, which keeps concurrent token-refresh attempts from being incorrectly deduplicated against each other.\n\n- Area: Auth\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}