Easy OAuth 2.0 Setup for SMTP in Automation Workshop

Hey everyone! Today, let’s tackle OAuth 2.0 for sending emails using SMTP in Automation Workshop—without the headaches (or in any other app / custom scripts). If you’re like me, you just want stuff to work without diving into pages of complex documentation. So let’s make this simple!

Quick Start – Google & Microsoft OAuth

• Google (Gmail) using Thunderbird IDs
  • Client ID: 406964657835-aq8lmia8j95dhl1a2bvharmfk3t1hgqj.apps.googleusercontent.com
  • Client Secret: kSmqreRr0qwBWJgbf5Y-PjSU
  • Scope: https://mail.google.com/
    (Yeah, Gmail demands the full access scope even just for sending emails via SMTP—talk about trust issues, Google!)
• Microsoft (Outlook/Office 365) using Thunderbird IDs
  • Client ID: 9e5f94bc-e8a4-4e73-b8be-63364c29d753
  • Client Secret: Leave empty (not needed)
  • Scope: offline_access https://outlook.office.com/SMTP.Send

Set these credentials up in Automation Workshop, and you’re pretty much done!

Quick Setup Walkthrough

• Open your email task or SMTP settings.
• Select OAuth 2.0 for SMTP authentication.
• Click Manage credentials – then New credential
• Fill in your email address and the Client ID and Client Secret.
• Choose a provider’s Authorization Endpoint and Token Endpoint preset from the Providers screen.
• Both endpoints are filled automatically, but check/fix the scope (Gmail scope is https://mail.google.com/ while Outlook is offline_access https://outlook.office.com/SMTP.Send)
• Hit the Sign in button, and follow instructions in the browser, and voilà—you’re good to go!

And that’s it—OAuth configured in just a few clicks.

Why Bother with OAuth?

As traditional username/password methods (often called “Basic Auth”) are considered less secure, major email providers like Google and Microsoft are transitioning to OAuth 2.0.

OAuth 2.0 replaces the need to store plain-text passwords, theoretically gives users more control over permissions, and improves security. But let’s be real—setting it up can sometimes feel unnecessarily complicated.

That said, it’s worth acknowledging that Basic Auth isn’t automatically insecure if implemented with care. When used in combination with secure practices—like storing credentials safely (e.g., in encrypted secrets), using app-specific passwords, and transmitting data over secure channels (TLS 1.2 or 1.3)—it’s far from reckless. SMTP with TLS is a well-established, battle-tested protocol, and when properly configured, it significantly mitigates the risks that OAuth supposedly solves.

Sure, OAuth does offer some nice benefits, like granular permission scopes and easier revocation, especially in large-scale or shared environments. But for smaller-scale applications, scripts, or trusted server-to-server communication, traditional authentication can still be a reasonable and manageable option—despite what Google and Microsoft might want you to believe.

Why Thunderbird’s IDs are Awesome

TL;DR

• You skip complicated app registrations.
• No verification hassle.
• Minimal risk of credentials being banned.

Longer Guide & Detailed Explanation

Borrowing Thunderbird’s IDs is ethical, practical, and totally fine. Thunderbird is an open-source project licensed under the Mozilla Public License. Its source code, including OAuth 2.0 client IDs, is freely accessible to anyone. Since desktop apps can’t hide secrets anyway, Mozilla’s credentials are effectively “public domain” (in simplistic terms). By using these credentials:

• You are not giving Mozilla the ability to read your emails. OAuth 2.0 doesn’t grant the third-party developer any special access to your mailbox.
• You bypass many complexities of self-registering your own app with Google or Microsoft, which can require app verification, fees, and compliance reviews.

App Verification (a.k.a Google’s Scary Process)

Creating your own OAuth credentials might lead to expensive and tedious verification processes.

• Google’s restricted scopes, especially https://mail.google.com/, trigger an app verification process.
• This process can demand source code reviews, third-party audits, and significant fees.
• For small developers or hobbyists, this is neither feasible nor practical. Even larger companies often struggle with the overhead and risk of giving their proprietary code to unknown auditors.

Thunderbird’s ready-made credentials help you avoid this hassle.

Potential App Ban Risks

When you register your own app, your entire user base is tied to that registration. If any single user starts spamming or violates the provider’s terms, the entire app can be banned. This scenario is less likely for Thunderbird’s official credentials, as Thunderbird is used by millions of people and is far more established.

Unverified Apps and Token Expiry

If you do not go through Google’s official app verification process, your refresh tokens can expire after two weeks. This forces you (and every user of your unverified app) to sign in repeatedly. Verified apps can keep refresh tokens for extended periods, making OAuth more seamless.

“Secret” Credentials (That Aren’t Really Secret)

OAuth 2.0 was originally designed for web apps with a server-side component. In a compiled desktop app, the Client ID and Client Secret are stored locally—either embedded in the binary or saved in configuration files. And let’s be honest: it’s trivial to open a binary in a hex editor and search for strings. If the secrets are in config files, it’s even easier—just open them in a text editor.

Even if the application encrypts these values or fetches them from an activation or license server, a motivated user can still inspect the app’s memory at runtime to extract the decrypted secrets. Tools for memory inspection, reverse engineering, and runtime analysis are readily available, and once the secret is in memory, it can’t hide. In other words, keeping OAuth credentials truly secret in a desktop or client-side app is effectively impossible—something that often gets overlooked in discussions about OAuth’s security benefits.

OAuth: Not Always the Smooth Ride You’d Expect

You might think using OAuth is as simple as clicking “Sign in with Google”—but for app developers, especially ones working on desktop tools like Thunderbird or Automation Workshop, it’s a whole different story.

Take Mozilla, for example. Their team has run into major headaches trying to register Thunderbird with various email providers. Why? Because every provider has its own unique process. Some ask you to sign special contracts. Others want you to go through endless forms or policy hoops. It’s a far cry from the open, plug-and-play world that traditional email protocols like IMAP and SMTP were built on.

As one Mozilla developer put it:

“We currently support tens of thousands of different IMAP servers (without OAuth2). That would be impossible with OAuth2 and manual client registration.”
— Mozilla developer

And it doesn’t stop there. Even after jumping through all the registration hoops, there’s the problem of reliability. What happens if your app registration changes? Or if your provider updates their policies without notice? Tokens can suddenly expire or stop working, and nobody—not even the engineers at Google or Microsoft—can always tell you why. For apps that need to run 24/7 without anyone babysitting them, like Automation Workshop, that’s a pretty big risk.

By contrast, sticking with well-understood authentication methods—like app passwords or securely stored credentials—can be a lot more predictable and stable. When something goes wrong, at least you know where to look.

So yes, OAuth has its place, especially for web and mobile apps. But for reliable desktop automation tools that just need to send an email now and then? It might be more pain than it’s worth.

Pros and Cons – Borrow vs. DIY

• Borrow Thunderbird’s IDs: Easy, reliable, no verification.
• Register your own IDs: Full control, but complex and potentially costly.

Why Automation Workshop Lets You Bring Your Own OAuth

When it comes to sending emails through OAuth 2.0, Automation Workshop takes a flexible approach: you can use any provider you want—Gmail, Outlook, Yahoo, your company’s own mail server, whatever. But there’s a catch (and a reason): you have to set up the app registration yourself.

Why? Because Automation Workshop is used all over the world in every kind of environment. The developers at Febooti can’t realistically act as the middleman for every email service’s fine print. Some providers require you to agree to special terms, verify domains, or promise not to use their service for spam or large-scale automation. That’s not something a third party can sign on your behalf.

And let’s say they did bundle a shared set of credentials with the app. First off, those secrets would have to live somewhere in the app—either in a config file or hidden inside the binary. But desktop apps can’t really keep secrets. Anyone with a hex editor (or Google) could dig them out. Even worse, if everyone used the same app credentials, one bad actor could burn through the whole quota or get the app blocked for everyone.

Instead, Automation Workshop plays it safe and smart. It supports universal OAuth 2.0 for SMTP, but lets you (or your sysadmin) plug in your own app credentials. You stay in control, you stay compliant, and you don’t have to worry about your automation breaking just because someone else misbehaved.

Bottom line: this setup keeps things flexible, reliable, and fair—especially for a tool that needs to run critical tasks 24/7 without drama.

App Passwords, OAuth, and the Mixed Messages

App Passwords vs. OAuth 2.0

In some cases, email providers still support good old app passwords. And honestly, they can be a lot simpler than setting up OAuth 2.0. Just generate a password, plug it in, and you’re done—no tokens, no callbacks, no app registration dashboards.

However, major providers like Google and Microsoft are moving away from app passwords, or at least hiding the option behind multiple clicks. The general message is clear: OAuth is the future. If your provider still allows app passwords and everything works smoothly, go ahead and use them—but don’t be surprised if that option quietly vanishes down the road.

Mixed Signals from Microsoft

Microsoft has been sending some interesting messages lately. On one hand, they’re phasing out basic authentication for Microsoft 365 (Office 365). On the other, they’re bringing back legacy SMTP access via services like smtp.azurecomm.net. Wait, what?

This just shows that secure email is a bit of a moving target. Big providers are trying to balance modern security with the real-world needs of businesses that still run older scripts, IoT devices, or simple automation tools. So while OAuth is the official “way forward,” it’s not always practical for every use case.

Other Providers?

Thunderbird offers OAuth details for Yahoo, AOL, Yandex, Mail.ru, Fastmail, Comcast, and more. Check their GitHub for specifics.

Wrapping Up

OAuth may seem complicated, but Automation Workshop and Thunderbird’s IDs make it easy. Set it up, automate your emails, and never worry about OAuth again!

Happy automating!