App Passwords vs OAuth When You Add a New Email Client

The failure looks the same everywhere. You install a new email client, hand it your address and your password, and it hangs — then fails with an error that reads 'authentication failed', 'invalid credentials' or 'we can't sign you in right now'. Nine times out of ten the problem is not your password. It is that Google, Microsoft, Apple and Yahoo no longer accept a raw account password over IMAP or SMTP. They accept an OAuth token, or in a narrow set of cases an app-specific password, and your client asked for the wrong one.

This post is a diagnostic. It explains what OAuth and app passwords each are, which of the two your provider will accept in 2026, and what to do when the sign-in still refuses to work. The primary keyword to hold in mind — app password vs OAuth for email client login — is really a choice between two mechanisms that solve the same problem from opposite ends: OAuth delegates trust through a provider-hosted consent screen, and an app password is a stand-in credential the provider issues so a client that cannot speak OAuth still has something to send.

One disclosure so the recommendation later reads honestly. We build AI Emaily, an AI-native email client that connects over OAuth for Gmail, Google Workspace, Outlook.com, Microsoft 365 and iCloud, and over app passwords for the IMAP hosts that require them. The mechanics below are a live problem for us, not an abstract explainer — every failed sign-in is one we have to diagnose too.

The short verdict#

If your client offers a button that says 'Sign in with Google', 'Sign in with Microsoft' or 'Sign in with Apple', click it. That is OAuth. It is the correct default for all four of the largest consumer providers and it is what those providers have been steering you toward since basic authentication was retired.

If your client only offers a plain password box and your provider is Google, Microsoft, Apple or Yahoo, you need an app-specific password. Your real account password will not work — the providers stopped accepting it on IMAP and SMTP years ago. Generate a 16-character app password from the provider's own security page and paste that in.

If your provider is a smaller IMAP host — Fastmail, ProtonMail Bridge, Zoho Mail, GMX, Yandex, most cPanel-hosted business mail — a normal mailbox password usually still works. Some of those hosts require an app-password wrapper when two-factor is on; check their doc before you assume.

How do OAuth and app passwords actually differ?#

The two look similar from the outside — both let a mail client read and send your mail — but they are structurally different. OAuth is a delegation protocol: the client never sees your password. An app password is a bearer credential: the client sees a string that is functionally equivalent to a password, scoped only by which client you handed it to and which service the provider will accept it for.

The table pulls out the dimensions that actually decide which one you should use and why one might fail where the other works.

Where OAuth wins#

OAuth is the default we would recommend to almost every reader, and the reasons are practical rather than ideological. It solves problems app passwords cannot solve, and it makes several classes of mistake harder to make.

• It is revocable per-client without collateral damage. Boot one app from your Google security page and every other OAuth client keeps working. In an app-password world, if the string leaks in a stolen laptop, you rotate it and every client that had it — including your phone, your desktop and your watch — goes dark until you paste the new one in.
• The consent screen is real security. A malicious 'inbox productivity' app that requests OAuth has to name itself, its verified publisher and every mailbox scope it wants — before you click Allow. An app-password client has none of that friction: whoever pastes the string in reads and sends your mail, and the provider never learns which app it was.
• Two-factor authentication stays intact. OAuth honours whatever second factor you set up — hardware key, TOTP, provider push. App passwords, by their nature, exist to skip it. Google's own help pages put this in bold: app passwords 'are less secure than using up-to-date apps and services that use the latest security standards'.
• It survives password changes. Change your Google password and every OAuth grant keeps working until you revoke it explicitly; all your app passwords die at once and every client has to be reconfigured. If you rotate credentials often, OAuth is dramatically less operational pain.
• Workspace and tenant admins can control it. On Google Workspace or Microsoft 365, an admin can allowlist which third-party clients are permitted to request an OAuth grant and block the rest before anyone even sees the consent screen. App-password policy is all-or-nothing per tenant.
• The audit trail is richer. OAuth grants show up in the provider's connected-apps view with a timestamp, a scope list and often a last-used field. App-password entries show the label you gave them and not much else.

Where app passwords win#

OAuth is better in almost every dimension, but 'almost every' is not 'every'. There is a real category of situation where an app password is what actually gets you connected, and the honest thing to do is name it rather than pretend the mechanism has no role.

• The client has not registered an OAuth app with your provider. This is common for Linux MUAs, older desktop clients, self-built tools, and anything that connects over plain IMAP and SMTP without XOAUTH2 support. If the client cannot speak OAuth to your provider, an app password is the only way in.
• The provider does not offer OAuth to third parties for that scope. Some corporate Exchange configurations with strict SSO, some ProtonMail Bridge setups, some self-hosted IMAP servers with only PLAIN over TLS — none of these have an OAuth path a third-party client can use, and an app password (or an equivalent) is the shipping mechanism.
• They survive OAuth revocation storms. Providers occasionally revoke OAuth grants for a class of apps at once, usually after a policy breach or a scope-audit failure. App passwords are unaffected — the client keeps working until you rotate the string yourself.
• Refresh-token expiry does not apply. Google can invalidate an OAuth refresh token after six months of inactivity on the account; app passwords sit there until the account password changes or you delete them.
• They work when the provider's OAuth consent screen is broken by policy. If a Workspace admin blocks the OAuth grant for third-party clients but leaves app passwords enabled, an app password may still connect where an OAuth attempt is refused before it even reaches the user. This is a narrow case — most admins who block one block the other — but it does happen.

The cost — not in dollars, in operational overhead#

Neither mechanism has a price. What each of them costs you is different, and it is worth naming, because the running cost is what makes the choice for most people over a year of use rather than one login.

OAuth's cost is invisible until it is not. The client's developer has to register an OAuth app with each provider, sometimes go through a security review (Google's CASA verification for restricted Gmail scopes is the well-known example), and keep the app up to date as the provider tightens its scope requirements. The user cost is one browser sign-in and a consent screen — no rotation, no expiry surprises for active accounts, no lost strings. When it works it disappears.

App passwords have the opposite cost profile. They are trivial to set up — generate, paste, done — but the running cost is on you. Every string is a credential you now own; you have to store it somewhere or accept re-generating it, rotate it when you retire the client, and remember that a password change wipes all of them. Multiply by every account and every device and it becomes a small but permanent tax.

Which method does each provider actually use in 2026?#

This is the table people arrive on this page hoping to find. Verify each row against the provider's own current help page before you trust it — some of these policies are one press release away from changing.

Who each method is genuinely for#

The overall shape is unambiguous — OAuth for the big four consumer and business providers, app passwords for the long tail of self-hosted and legacy setups — but there are readers each side of the line is genuinely built for, and the honest way to talk about that is by naming them.

OAuth is genuinely for the reader who runs on Gmail, Google Workspace, Outlook.com, Microsoft 365, iCloud or Yahoo, and whose client of choice ships an OAuth flow for that provider. That is most readers of this post. It is also the reader who cares about revocability, keeps two-factor on, and does not want to think about rotating credentials when they change their password. If both sides support it, there is essentially no case for choosing an app password.

App passwords are genuinely for the reader whose client and provider combination has no shared OAuth path. That is the Linux mail user on Mutt or Aerc, the developer wiring up a small script that needs to send from a shared mailbox, the operator of a self-hosted IMAP server whose team lives in a mix of clients, and the ProtonMail user running the Bridge. It is also the fallback for the Workspace user whose admin has narrowed the OAuth allowlist and left app passwords enabled — a rarer combination than it used to be.

The reader who should stop reading and go elsewhere is the one whose problem is not a sign-in problem at all. If your client connects fine but does not sync new mail, or drops the connection every ten minutes, or duplicates every message — those are IDLE, connection-limit or folder-mapping issues, and none of them are about the auth mechanism. Fix them separately.

A third option, honestly — let the client handle the choice#

The choice between OAuth and an app password is really a choice about who does the token dance and who owns the credential — you, or the client. A modern client that supports both mechanisms across every major provider takes the decision off your desk: it uses OAuth wherever your provider and the client's registered scopes allow, and it falls back to an app-password field only for the IMAP hosts that actually require one.

That is the shape we build for. We build AI Emaily. It ships OAuth for Gmail, Google Workspace, Outlook.com, Microsoft 365 and iCloud, and an app-password entry for Yahoo, Fastmail, Zoho, GMX, custom IMAP and the long tail of self-hosted hosts. The trade-off does not vanish — for Gmail we still appear on your Google security page as a connected app and can be revoked there, exactly as the OAuth model intends — but the reader stops having to know which of the two mechanisms applies before they try to sign in.

The 7-day free trial takes card details and charges $0 if you cancel before day 7; the current AI Emaily pricing lives on the pricing page and is worth checking rather than trusting a number in an article. If you want the mechanics of what we ask for on each provider — the exact Gmail scopes, why we do or do not need any given one — the connect-mailbox docs listed below the article go through them provider by provider.

When the sign-in still fails after you have the right credentials#

You have picked the right mechanism, you have the right string or the right consent, and the client still refuses. A short diagnostic order tends to catch most of what goes wrong at this stage.

1. 1

   Check the provider's security page for a fresh block

   Google, Microsoft and Apple all show a 'critical security alert' or 'sign-in blocked' entry when they refuse an unfamiliar client. Approve the sign-in from that page — often that alone completes the flow the client is stuck on.

2. 2

   Confirm the account has 2-Step Verification on

   For Gmail specifically, the app-passwords option is invisible in your account settings until 2FA is turned on. If you cannot find the app-passwords link, this is why. Turn on 2FA, then revisit.

3. 3

   Verify the server host, port and TLS mode

   IMAP over TLS is 993, SMTP submission over TLS is 465 or 587 with STARTTLS. A wrong port produces an auth failure that looks like a wrong password. Check the provider's IMAP/SMTP settings page verbatim.

4. 4

   Regenerate the app password from scratch

   You cannot re-read an app password after the provider first shows it. If you copy-pasted with a stray space or lost the middle of the string, generate a new one and paste the whole 16 characters without spaces.

5. 5

   For work accounts, ask the admin about the OAuth allowlist

   Google Workspace and Microsoft 365 admins can block a specific client from ever getting a consent screen. The refusal looks identical to a wrong-password error. If your personal client works fine and your work account fails, this is nearly always the reason.

6. 6

   Reset OAuth by revoking and re-adding

   A stale refresh token can produce a silent failure. Revoke the client's grant on your provider's connected-apps page, then add the account to the client again from scratch. This resets the whole token chain.