Resolve OAuth Token Errors During Office 365 Migration
OAuth token errors during Office 365 migration usually occur when Microsoft 365 invalidates or cannot renew the refresh token used for authentication. Common causes include expired refresh tokens, revoked consent, MFA or Conditional Access changes, and account security updates such as a password reset.
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 is 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 manages OAuth authentication during migration by refreshing access tokens as required and reporting authentication issues that require administrator action. 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.
Understanding OAuth Authentication During Office 365 Migration
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.
Common OAuth Token Errors During Migration
The AADSTS code in the error message identifies the type of token failure. The codes below are the ones most often seen during Office 365 migration:
| Error Code | What It Means | Cause Group |
|---|---|---|
| AADSTS700082 | The refresh token has expired due to inactivity. | Token expiry |
| AADSTS70008 | The authorization code or refresh token has expired due to inactivity. | Token expiry |
| AADSTS700084 | The refresh token was issued to a single-page application and has a fixed lifetime that cannot be extended. | Token expiry |
| AADSTS50173 | The grant was revoked, for example after a password change or reset, and a new token is required. | Password or security change |
| AADSTS50076 | Multifactor authentication is required because of a configuration change or a sign-in from a new location. | MFA or Conditional Access |
| AADSTS50158 | An external security challenge, such as a Conditional Access requirement, was not satisfied. | MFA or Conditional Access |
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; this is a strong signal it's a connection-level token issue rather than a mailbox-specific problem
Why OAuth Tokens Stop Working
OAuth token failures during migration fall into five groups: token expiry, password or security changes, MFA changes, Conditional Access policies, and admin consent removal.
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.
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.
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.
"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.
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, or 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.
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, either 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 to Troubleshoot OAuth Token Errors
Use the following administrator checklist to identify the cause of the error and restore the connection. If authentication is one of several issues in the project, run the wider Office 365 migration health checks to confirm mailbox access, permissions, and mail flow.
Administrator Checklist
- Check the exact AADSTS code in the error message. It identifies which category of token failure you are 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 to complete the OAuth consent flow again.
- Confirm nothing changed on the authenticating account. A password reset, account compromise response, or admin-initiated session revocation requires fresh authentication.
- Verify admin consent is still active for the app registration, particularly if a tenant-wide security review or app governance policy has run recently.
- Review MFA settings. A "remember MFA for X days" policy can invalidate tokens that otherwise look valid.
- Check Conditional Access. A recent policy change, or a sign-in from a new location or device, can require a fresh interactive sign-in.
- Re-authenticate the connection through the OAuth sign-in and consent flow.
- Test the migration with a sample mailbox before resuming the full batch, to confirm the new token works end to end.
OAuth Troubleshooting Decision Tree
Start with the AADSTS code in the error message and follow the matching branch:
- Token expired (AADSTS700082, AADSTS70008, AADSTS700084): re-authenticate the connection.
- Token revoked (AADSTS50173): confirm the password reset or security event with the account owner or security team, then re-authenticate.
- MFA or Conditional Access challenge (AADSTS50076, AADSTS50158): review the MFA and Conditional Access policies that apply to the account, complete an interactive sign-in, then re-authenticate.
- Consent removed: ask a tenant administrator to grant admin consent for the app registration again.
Whichever branch applies, test with a sample mailbox before you resume the batch.
Before Restarting Migration
- Confirm authentication: the connection signs in without an error.
- Verify permissions: admin consent and the required application permissions are still granted.
- Test mailbox connection: a sample mailbox connects and migrates items.
- Resume incremental migration: resume the batch rather than restarting it, so mailboxes already completed are not processed again.
Preventing OAuth Issues During Long Migration Projects
- 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
Build these checks into the migration plan from the start. The Office 365 migration guide covers the full planning and preparation workflow.
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, reducing the need for repeated manual authentication during normal migration operations | 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 difference between these approaches is not whether OAuth is used, since most modern tools use it, but whether the tool actively manages the token lifecycle or just assumes the original token will keep working indefinitely.
How EdbMails Handles OAuth Authentication
EdbMails Office 365 Migration Tool refreshes access tokens as required during migration and reports authentication issues that need administrator action:
- Access token renewal, refreshing tokens before they expire, so a migration running for several hours or overnight is less likely to stall 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 know 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 routine token renewal is handled during normal migration operations, reducing the need for repeated manual authentication.
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
