What Is OAuth 2.0 (for Email)? A Plain-English Guide

OAuth 2.0 is the authorization framework that has replaced username-and-password authentication for almost every major email provider. If you are connecting a migration tool, a desktop client, or a backup service to a Gmail or Microsoft 365 mailbox in 2026, you are using OAuth whether you realise it or not. This entry covers what OAuth is, the two grant types that matter for email, and the role the protocol plays when you move mailboxes between providers.

The short definition#

OAuth 2.0 is defined in RFC 6749. It is a framework that lets a user authorize a third-party application to access a resource — in our case, a mailbox — without giving the application the user's password. Instead, the user signs in at the resource provider (Google, Microsoft), sees a consent screen listing the permissions the app is requesting, and clicks Allow. The provider hands the app two tokens, and the app uses those tokens on every subsequent request.

That single property — the app never sees the password — is the reason OAuth exists.

Authorization code grant (the one users see)#

The authorization code grant is the flow you have already been through a hundred times: click "Sign in with Google", get redirected to Google, log in, click Allow, get bounced back to the app. Behind the scenes:

1. The app sends you to Google with a request that includes its client ID and the scopes it wants.
2. You sign in and approve.
3. Google redirects you back to the app with a short-lived authorization code.
4. The app exchanges that code (plus a client secret) for an access token and a refresh token.
5. The app uses the access token on every IMAP, SMTP, or Graph call. When it expires, the refresh token gets a new one.

This is the grant a migration tool uses when you connect your mailbox to it.

Client credentials grant (the one admins set up)#

The client credentials grant skips the user entirely. The app authenticates directly with its own client ID and a certificate or secret, and the provider grants it access to mailboxes the tenant admin has pre-authorized. This is how server-to-server migration tools move thousands of mailboxes in a Microsoft 365 tenant without each user clicking through a consent screen.

For client credentials to work, an admin has to grant tenant-wide consent to the app once. After that, the app can access any mailbox in scope.

Why "modern auth" replaced basic auth#

Google removed support for password-based IMAP and SMTP for most account types in 2022. Microsoft retired basic auth for Exchange Online in late 2022 (for connectors a little later). The shift was driven by four problems with basic auth:

• Passwords travel on every single request.
• A compromised password gives full mailbox access until rotation.
• There is no scope — the credential is all-or-nothing.
• Multi-factor authentication does not work with IMAP basic auth, so it gets bypassed entirely.

OAuth fixes all four. Tokens are scoped, short-lived, revocable from a single admin screen, and the actual sign-in happens through a browser flow where MFA is enforced.

OAuth in migration tools#

When you connect a source or destination mailbox to a migration tool, the tool is the OAuth client. You are granting it permission to read (and usually write) the mailbox. The consent screen will list scopes like https://mail.google.com/ for Gmail or IMAP.AccessAsUser.All for Microsoft 365.

A few practical points:

• The refresh token is the long-lived secret. If a token gets stuck or stops working mid-migration, see fix OAuth token expired.
• You can revoke an OAuth grant at any time from the provider's security page. The migration stops immediately.
• For providers that do not support OAuth (older hosts, ProtonMail Bridge, some cPanel setups), you fall back to an app password or a direct IMAP login.

How OAuth fits the bigger picture#

OAuth is one part of the migration auth story. You will still see usernames and passwords for legacy boxes, app passwords for Yahoo and Apple, and certificate-based service-principal auth for large Office 365 migrations and Google Workspace migrations. The pattern across all of them is the same: get a credential the receiving provider will accept, then move messages over IMAP or Graph.