I have a functioning email sending method using Indy components that connects to Gmail SMTP servers. While the current method works well, it requires users to enable “Allow less secure apps” in their Google account settings.
I aim to enhance this solution by using OAuth 2.0 authentication instead of basic username/password authentication. This change will help eliminate the need for users to lower their security settings, complying with Google’s suggested security standards.
Converting your Indy setup to OAuth 2.0 isn’t straightforward - you’ll need to add quite a bit more code. First, register your app with Google’s Developer Console to get client credentials. Then you’ll handle the OAuth flow: redirect users to Google’s auth page, grab the authorization code, and swap it for access tokens.
For SMTP, you’ll ditch the username/password and use SASL XOAUTH2 with your access token instead. Here’s the catch - Indy doesn’t support XOAUTH2 out of the box. You’ll have to write custom auth handling or extend TIdSMTP yourself.
Don’t forget token refresh logic since access tokens expire regularly. You can keep using Indy, but expect your code to get way more complex than what you have now.
oauth2 with indy is a pain. you’ll have to build the whole google oauth flow from scratch - auth codes, token exchanges, refresh tokens, everything. indy doesn’t even support xoauth2 natively, so that’s another thing to code up. honestly? just switch to an email component that already handles oauth. way less headache than working around indy’s limits.
OAuth 2.0 with Indy is a pain. You’re stuck handling token refresh, scope management, and Google’s API responses yourself. Been there.
Worst part? Your code breaks every time Google changes their auth flow. And maintaining all that token logic? Total nightmare.
Hit this same wall last year with 200+ users screaming about Google killing “less secure apps.” Instead of fighting OAuth, I just automated the whole thing.
Built a workflow that handles Gmail OAuth for me. No token headaches. No security warnings. It manages auth, refreshes tokens, and sends emails without fail.
Keeps your Pascal code clean - just make API calls to trigger emails instead of wrestling with SMTP.
Saved us weeks of OAuth hell and works way better than anything I could’ve built.
I set up OAuth 2.0 with Indy for Gmail SMTP about six months ago and hit several gotchas that weren’t obvious upfront. The biggest pain is TIdSMTP doesn’t handle XOAUTH2 natively, so you’ve got to override the auth mechanism. What worked for me: create a custom TIdSMTPRelay descendant and override the Authenticate method to send the proper SASL XOAUTH2 string format. The token format has to be perfect or Gmail silently rejects it. Here’s something nobody else mentioned - you need solid error handling for token expiration during SMTP sessions. Gmail can kill tokens mid-connection, and your code needs to catch this and retry with fresh credentials. Learned this the hard way when bulk emails started randomly failing. The initial OAuth setup is tedious but doable. The real challenge is keeping robust token lifecycle management while not breaking your existing Indy setup.