Resolve OAuth Token Errors During Office 365 Migration
There's a specific kind of headache that comes from a migration job dying overnight with nothing but an invalid_grant error and a cryptic AADSTS code in the log. No password changed. No setting was touched. The job just stopped trusting itself. This is one of the more confusing categories of migration failure precisely because it has nothing to do with the data being moved — it's about the access token that was supposed to be quietly renewing itself in the background, and didn't. OAuth tokens are the backbone of how modern Microsoft 365 connections stay authenticated without repeatedly prompting for a password, but they come with their own lifecycle rules, and a migration that runs longer than expected can easily outlast the token that started it. EdbMails Office 365 Migration is built to manage this token lifecycle automatically, refreshing access tokens behind the scenes so a long-running migration doesn't quietly stall because a token expired three hours into an overnight batch. This page breaks down why OAuth token errors happen, what the common error codes actually mean, and how to deal with them when they show up.
A Quick Refresher: Access Tokens vs. Refresh Tokens
It helps to separate the two pieces that make OAuth work, because most token errors point squarely at one or the other:
- An access token is short-lived — typically valid for around an hour — and is what's actually presented to Microsoft 365 services to prove a request is authorized.
- A refresh token lives much longer and is used quietly behind the scenes to get a new access token once the old one expires, without requiring the user to sign in again.
A migration tool that's been authenticated once should, in theory, keep refreshing its access token using the refresh token indefinitely. The trouble starts when the refresh token itself becomes invalid — at that point, there's nothing left to refresh from, and the whole authentication chain collapses until someone re-authenticates from scratch.
Why OAuth Tokens Fail Mid-Migration
Refresh Token Inactivity Expiry (AADSTS700082 / AADSTS70008)
This is probably the single most common token error reported across Microsoft 365 integrations, not just migration tools. Microsoft's identity platform expires a refresh token if it sits unused for an extended period — commonly around 90 days, though the exact window depends on tenant policy. For most active, daily migration jobs this rarely bites, but it shows up often in paused projects: a migration started, set aside for a few months, and then resumed, only to find the previously-working connection now needs a fresh round of consent.
"Remember MFA" Settings Interfering with Token Refresh
A less obvious cause of the same AADSTS700082 error: when a tenant has a "remember MFA for X days" policy enabled, it can interact poorly with the underlying refresh token lifecycle, effectively invalidating the token even though the integration appeared to be working normally up to that point. Disabling that setting and allowing roughly half an hour for the change to propagate is the usual fix.
Revoked Tokens After a Password Reset or Security Event (AADSTS50173)
If the account a migration is authenticated as has its password changed, gets flagged for a security event, or has its sessions revoked by an admin, Microsoft invalidates the existing refresh tokens as a security measure. The migration then fails with an invalid_grant error, and the only real fix is re-authenticating the connection from scratch.
Conditional Access or MFA Re-Challenge (AADSTS50076 / AADSTS50158)
Some tenants have Conditional Access policies that require interactive sign-in under certain conditions — a new location, a new device fingerprint, a policy change. When that happens mid-migration, the existing token silently stops being sufficient, and the connection needs a fresh interactive consent before it'll work again.
Fixed-Lifetime Tokens for Certain App Types (AADSTS700084)
Tokens issued to certain application types — particularly single-page applications — have a hard, non-extendable lifetime rather than a sliding inactivity window. Once that fixed window closes, there's no keeping it alive through activity; a new interactive sign-in is required. This is less common for traditional migration tooling but worth knowing if a custom script or connector is involved.
Missing or Withdrawn Admin Consent
OAuth app registrations typically need a tenant admin to consent to the permissions being requested. If that consent is later revoked — deliberately, or as a side effect of a broader security review — token requests start failing even though the app registration itself hasn't changed.
How These Errors Typically Show Up in Logs
- "error": "invalid_grant", "error_description": "AADSTS700082: The refresh token has expired due to inactivity."
- A migration batch that was progressing normally suddenly stops, with no new data moved despite the job showing as "in progress"
- Repeated re-authentication prompts appearing for an account that previously connected without issue
- A token-related failure that affects every mailbox in a batch simultaneously, rather than just one or two — a strong signal it's a connection-level token issue rather than a mailbox-specific problem
How Different Migration Tools Handle Token Lifecycle
| Approach | Token Handling | Common Pain Point |
| Manual scripts using a one-time OAuth flow | Access and refresh tokens captured once and reused as-is | No built-in renewal logic; once the refresh token expires or is revoked, the script simply fails with no automatic recovery |
| Tools relying on a single long-lived session per migration project | Refresh token used throughout the project but not actively monitored | Works fine for short projects; long-running or paused-and-resumed migrations risk hitting inactivity expiry or tenant policy changes mid-project |
| Tools with manual re-authentication prompts on failure | Detects token failure and prompts the administrator to reconnect | Functional, but requires someone to notice and respond to the prompt, which can stall overnight or unattended batches |
| Tools with automatic, proactive token renewal | Refreshes access tokens before they expire and handles standard renewal failures without manual intervention | Reduces unattended failures significantly, though tenant-side events like a password reset or revoked consent still require a fresh authentication regardless of the tool |
The differentiator across these isn't whether OAuth is used — virtually everything modern uses OAuth at this point — it's whether the tool actively manages the token lifecycle or just assumes the original token will keep working indefinitely.
How EdbMails Handles OAuth Token Management
EdbMails Office 365 Migration Tool is designed to manage the OAuth token lifecycle automatically rather than leaving it to chance over a long-running migration:
- Automatic access token renewal, refreshing tokens in the background before they expire, so a migration running for several hours or overnight doesn't stall partway through over a routine token refresh.
- Clear error reporting when a token issue does occur, distinguishing a renewable token problem from one that genuinely requires fresh administrator consent — so you're not left guessing whether the fix is a quick retry or a full re-authentication.
- Resilience to interruption, since EdbMails' incremental/delta migration model means that if a batch does need to pause for re-authentication, previously migrated data isn't duplicated once the connection is restored.
- Modern OAuth-based connections by design, avoiding the kind of one-time, unmonitored token capture that tends to be the root cause of unattended token failures in simpler scripts and tools.
This doesn't mean tenant-side events are avoidable — if an administrator resets a password, revokes consent, or a Conditional Access policy forces an interactive challenge, re-authentication is still required regardless of which migration tool is involved. What it does mean is that the routine, predictable side of token expiry isn't something administrators need to babysit manually.
Step-by-Step: Resolving an OAuth Token Error
- Capture the exact AADSTS code from the error message — it almost always tells you precisely which category of token failure you're dealing with.
- Check whether the issue is inactivity-related (AADSTS700082/70008). If the connection has been idle for an extended period, the fix is usually as simple as re-consenting through the OAuth flow again.
- Check tenant-level MFA and Conditional Access settings. A "remember MFA for X days" policy or a recent Conditional Access change can silently invalidate tokens that otherwise look fine.
- Confirm nothing changed on the authenticating account — a password reset, account compromise response, or admin-initiated session revocation will always require fresh authentication, no exceptions.
- Verify admin consent is still active for the app registration in question, particularly if a tenant-wide security review or app governance policy has run recently.
- Re-authenticate and test against a single mailbox before resuming a full batch, to confirm the new token is actually working end-to-end.
- Resume rather than restart the migration batch where possible, so mailboxes already completed aren't re-processed unnecessarily.
Best Practices to Avoid Token Errors During Migration
- For long or paused-and-resumed migration projects, avoid letting a connection sit completely idle for months at a time without at least a connectivity check
- Review tenant MFA "remember for X days" settings before a major migration, since they've been linked to unexpected token invalidation
- Communicate any planned password resets or security reviews to the migration team in advance, since these will force re-authentication regardless of timing
- Keep admin consent and app registration permissions documented, so a missing-consent issue can be diagnosed quickly rather than re-investigated from scratch
- Where possible, run migrations in well-defined batches rather than one continuous multi-week job, so a token-related pause affects a smaller, easier-to-resume slice of the project
Frequently Asked Questions
What does AADSTS700082 mean, and is it serious?
Why did my migration token expire even though I was actively using it?
Can a token error cause data loss or corruption during migration?
Does EdbMails handle OAuth token renewal automatically?
Additional resources:
- EdbMails Office 365 Migration Software
- Resolve Office 365 Migration Endpoint Authentication Errors
- Resolve Office 365 Mailbox Mapping Errors
- Exchange Online Service Limits for Migration
- Coexistence During Office 365 Migration
- Automatic registration of EdbMails in Azure AD
- Manual Registration of EdbMails in Azure AD
