2025: Google Kills Basic Authentication for Gmail — OAuth or Nothing

For over two decades, connecting a third-party email client or script to Gmail was simple. Enter your username, enter your password, hit connect. It worked with Thunderbird, it worked with your Python script, it worked with that dusty printer in the back office that emailed scanned PDFs. It was also, from a security standpoint, terrible. In September 2025, Google finally pulled the plug. Basic authentication — the method of sending a plain username and password to access Gmail — was permanently and irrevocably disabled for all third-party access. The only way in now is OAuth 2.0.

The Long Goodbye

This was not a surprise. Google had been telegraphing the move for five years.

In 2020, Google introduced the “Less Secure Apps” (LSA) setting — a toggle that allowed users to grant third-party apps access to their Google account using just a username and password. The name itself was a warning: Google was telling users, in the setting’s own label, that this method was less secure. The toggle was on by default for older accounts, and millions of users and scripts relied on it without thinking twice.

In June 2022, Google disabled the LSA toggle for new accounts. Existing accounts could still use it, but the writing was on the wall. Google began sending periodic emails to users with LSA enabled, warning that the setting would be removed. Many users ignored these emails — they landed in the Promotions tab, or looked like routine notices, or were simply lost in the noise.

In 2024, Google set a hard deadline: September 30, 2025. After that date, all IMAP, POP, and SMTP connections to Gmail from third-party apps would require OAuth 2.0. No exceptions. No grace period extensions. No “just one more year.”

When September 2025 arrived, Google kept its word.

What Actually Broke

The impact was concentrated but significant.

Legacy email clients were the most visible casualties. Users running older versions of Thunderbird, Windows Live Mail, or pre-2016 Outlook found themselves locked out of their Gmail accounts. These applications either didn’t support OAuth 2.0 at all or required manual configuration to enable it. For tech-savvy users, updating or reconfiguring was a minor inconvenience. For less technical users — particularly older users who had been using the same email client for a decade — it was genuinely confusing.

Custom scripts and automation took a harder hit. Developers and sysadmins had written thousands of scripts over the years that used Gmail’s SMTP server to send automated emails — monitoring alerts, cron job reports, form submissions, backup notifications. These scripts typically imported Python’s smtplib, hardcoded a Gmail address and password, and called it done. Every one of those scripts broke on the same day.

IoT and embedded devices were perhaps the most painful category. Network-attached scanners, security cameras, NAS devices, and industrial equipment had been configured years ago to send email alerts through Gmail’s SMTP servers using basic credentials. Many of these devices had firmware that simply didn’t support OAuth 2.0 and never would. Administrators had to reconfigure them to use a different SMTP relay or replace the devices entirely.

Enterprise systems with embedded Gmail SMTP credentials — CRM platforms, legacy ERP systems, ticketing tools — also required updates. Some organizations discovered they had Gmail credentials hardcoded in systems that no one on the current staff had originally configured, leading to archaeological expeditions through decade-old code.

Why OAuth 2.0 Is Better

The security case for this change is straightforward.

Basic authentication works by sending the user’s actual username and password with every connection. Even when transmitted over TLS (encrypted in transit), the credentials are available in plaintext at both ends of the connection. If a third-party app is compromised, the attacker gets the user’s real password — which can be used to access not just Gmail but any other Google service, and potentially any other account where the user reused that password.

OAuth 2.0 fundamentally changes this model. Instead of sharing a password, the user authenticates directly with Google through a browser-based flow and grants the third-party app a limited-scope access token. The app never sees the user’s password. The token can be scoped to specific permissions (read-only email, send-only, specific folders), can expire automatically, and can be revoked by the user at any time without changing their password.

If a third-party app using OAuth is compromised, the attacker gets a token that provides limited access to one service for a limited time. They do not get the user’s password, cannot access other services, and the user can revoke the token with a single click.

Microsoft Did It First

Google was not the first major email provider to kill basic authentication. Microsoft began deprecating basic auth for Exchange Online in 2019 and completed the process in October 2022, disabling basic authentication for Exchange ActiveSync, POP, IMAP, Remote PowerShell, Exchange Web Services, Offline Address Book, Autodiscover, and MAPI over HTTP.

Microsoft’s transition was notably messy. The company set and postponed deadlines multiple times, eventually forcing the change on a date that still caught many administrators off guard. The Exchange Online transition was widely covered in IT press and served as both a roadmap and a cautionary tale for Google’s own rollout.

Outlook.com (Microsoft’s consumer email service) followed with its own basic auth deprecation timeline, aligning consumer and enterprise policies. By 2025, both of the world’s largest email providers had eliminated basic authentication entirely.

The Broader Trend

The death of basic authentication for email is part of a larger industry movement away from password-based authentication. Passkeys, hardware security keys, biometric authentication, and token-based protocols are replacing passwords across the technology landscape. Email — one of the oldest internet services still in widespread daily use — was one of the last holdouts.

The change also reflects the evolving threat landscape. Credential stuffing attacks — where attackers use username/password combinations leaked from one breach to access accounts on other services — are devastatingly effective when basic authentication is available. Removing basic auth eliminates an entire category of attack surface.

For email marketers and developers who send email programmatically, the shift means adapting workflows. Where a script once needed two lines of configuration (username and password), it now needs an OAuth client ID, client secret, refresh token, and token refresh logic. It is more complex, undeniably. It is also orders of magnitude more secure.

What This Means Going Forward

The era of sending credentials in plaintext is officially over for consumer email. Google and Microsoft, which together handle the vast majority of the world’s email, have drawn the line. Other email providers will follow — many already have.

For the email ecosystem, this is unambiguously positive. Every connection to a mailbox is now authenticated with modern, revocable, scoped credentials. The password-in-the-config-file pattern — a security antipattern that persisted for decades because it was easy — is dead.

The transition was painful for some, particularly those running legacy systems or scripts that hadn’t been touched in years. But the security improvement is permanent and structural. Basic authentication was a relic of an era when the internet was smaller, threats were simpler, and convenience routinely trumped security. That era ended in September 2025, and email is safer for it. For more on the authentication standards that are replacing the old ways, see our coverage of SPF, DKIM, and DMARC and the 2024 Gmail and Yahoo authentication requirements.

Infographic

Share this visual summary. Right-click to save.

Frequently Asked Questions

What did Google change about Gmail authentication in September 2025?

Google permanently disabled Basic Authentication (username and password) for all third-party apps accessing Gmail via IMAP, POP, and SMTP. After September 2025, any app or script that connects to Gmail must use OAuth 2.0, a token-based authentication protocol that never exposes the user's actual password to the third-party application.

Why did Google kill basic authentication for Gmail?

Basic authentication sends usernames and passwords in plaintext (or easily reversible encoding) with every connection. If intercepted, the credentials are immediately usable by an attacker. OAuth 2.0 eliminates this risk by issuing short-lived access tokens that can be revoked without changing the user's password. Google had been warning about this change since 2020 when it introduced the 'Less Secure Apps' toggle.

What apps were affected by Gmail's basic auth shutdown?

Older email clients like Thunderbird (pre-2020 versions), legacy versions of Outlook, custom scripts using Python's smtplib or imaplib with hardcoded passwords, IoT devices that send email alerts, and enterprise applications with embedded SMTP credentials were all affected. Any software that sent a plain username and password to Gmail's servers stopped working.