Joomla 6.2 Adds OAuth for SMTP, Just Before Microsoft Turns Off Basic Auth

Joomla 6.2 came out on October 13, 2026. Most of the coverage has focused on TinyMCE changes, which are nice, but they aren't the reason we'd move client sites to it this fall. The reason is one line under the Email heading of the release notes - generic XOAuth2 support for SMTP authentication.

That's a bigger deal than it sounds, because Microsoft is about to turn off password-based SMTP sign in for Microsoft 365 by default. If you look after Joomla sites that send contact forms, order confirmations or password resets through a Microsoft 365 mailbox with a stored password, this release is happening at a good time.

OAuth for SMTP & Good Timing

Until now, connecting Joomla to Microsoft 365 or Google Workspace SMTP usually meant typing a mailbox password (or an app password) into Global Configuration and leaving it sitting in configuration.php. According to the official 6.2 announcement, Joomla can now authorize through the mail provider instead. The provider hands back a long lived refresh token, and Joomla uses it to request short lived access tokens whenever it needs to send. The announcement specifically names Microsoft 365 and Google Workspace as the main targets.

Now the Microsoft side. Microsoft's plan to retire Basic authentication for SMTP AUTH (Client Submission) in Exchange Online has been postponed more than once. The current version of message MC786329 says SMTP AUTH Basic auth will be disabled by default for existing tenants at the end of December 2026, new tenants created after that won't have it available by default, and Microsoft will announce a final removal date in the second half of 2027.

Disabled by default isn't gone. Tenant admins can switch it back on for now. But a site that stops sending password resets on January 2 is still a horrible week, and "turn the old thing back on" isn't a plan you want to explain to your clients. Sends that fail on Basic auth come back with a 550 5.7.30 error, which is worth knowing before someone forwards you a confused support ticket.

What we're doing for our own Joomla clients:

• Listing every site that sends through smtp.office365.com with a password. Microsoft's SMTP AUTH report in the Exchange admin center can show which senders use Basic auth and which use OAuth, so check that if you have tenant access.
• Moving those sites to 6.2 first, then switching mail to XOAuth2. You'll need an app registered with the provider to get client credentials, so budget a bit of back-and-forth with whoever runs the client's Microsoft or Google admin account.
• Sending a real test from every form that emails, not only the Global Configuration test button. Contact forms, registration and anything from third-party extensions that use their own mail settings.

That last point catches people. If an extension bypasses Joomla's mailer and keeps its own SMTP credentials, Joomla's new OAuth support won't help it. Check those separately.

Security Flags for Extension Updates

If you ship Joomla extensions, this is the change to read up on. Developers can now flag a release as a security update, with a severity from None to Critical. Flagged updates get highlighted in System, Update, Extensions and on the dashboard quick icon. The 6.2.0 changelog lists it as two pull requests: one adding the flag, and one so the dashboard shows the update with the highest severity.

For years, a Joomla admin looking at a list of pending extension updates had no way to tell a typo fix from a patched SQL injection. Now they can, but only if extension authors actually set the flag. We'll be using it on our own releases, and we'd encourage anyone else maintaining extensions to do the same. It also gives you a clean, visible way to tell users "this one's a security fix" which is useful for anyone thinking about vulnerability disclosure obligations for software sold into the EU.

What Changed Under the Hood?

The developer-facing changes are spread across 116 merged pull requests - of those, the important ones are:

• The JavaScript and CSS asset pipeline was reorganized, with new builders, registries, and watch/build commands. If you have custom build scripts that hook into core's tooling, test them before anything else.
• Deprecation targets were moved to 7.0, in line with the project's deprecation policy. That gives you more runway on deprecated APIs, but it also tells you where the next hard break is.
• The CMS Crypt package is now deprecated. If an extension of yours leans on it, start planning a replacement.
• Core replaced the deprecated Factory::getUser() with getIdentity() across the site and admin apps. If you're still calling the old method, this is a good release to clean that up.
• The MVCFactory service provider was refactored to be easier to extend, there's a new Enum FormField, and MailTemplate now uses dependency injection with its static functions deprecated.
• Core now sends a Reporting-Endpoints header, and MariaDB is treated as a first-class database system rather than an afterthought next to MySQL.

The swap from the deprecated user call is really simple:

// Old (deprecated)
$user = Factory::getUser();
// New
$user = Factory::getApplication()->getIdentity();

The 6.1 to 6.2 migration notes in the developer manual have the full list if needed.

The Editor Change That May Surprise You

Most of the TinyMCE updates are straightforward wins: images now go through the Joomla Media Manager, there's a single link picker for articles, contacts and menu items, and there's a proper Read More button. Content editors will like all of it.

One change deserves a test before you upgrade a client site, though. TinyMCE now uses Joomla's own text filter configuration by default instead of its own valid-elements list. On most sites that's an improvement, since there's one set of rules instead of two. But if a client has pages full of embedded iframes, custom attributes or hand-written HTML, and their text filter settings were never touched because TinyMCE was doing the filtering, what survives a save may change. Open a few of the messiest articles on staging, save them, and compare the output.

A few smaller items clients will notice: login modules can now hide the "Forgot your password?" and "Forgot your username?" links without a template override, subcategory images can show in category lists and blogs, and article images get separate CSS class fields for the image and its figure.

Before You Upgrade

Joomla 6 needs PHP 8.3 or newer, so if a site is still on Joomla 5 and PHP 8.2, start with our notes on PHP 8.2 reaching end of life. Sites on 5.x need to reach 5.4 before jumping to 6.x. The Joomla team describes the 5.4 to 6.2 move as an upgrade rather than a migration, and most extensions work with the Behaviour - Backward Compatibility 6 plugin enabled.