I have been using Gmail to send emails with Django for a few years now, but I am confused about how I am supposed to authenticate with Gmail because I have twice received emails (not directly, details below) from Google saying that our authentication method was being deprecated.
First email from Google in 2019: " Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported. "
So I moved to using GitHub - dolfim/django-gmailapi-backend: Email backend for Django which sends email via the Gmail API to authenticate with OAuth, but I have recently received an email that they are deprecating out of band tokens, which that library uses: Google Developers Blog: Making Google OAuth interactions safer by using more secure OAuth flows . I don’t see any clear way to authenticate an app to send emails in their recommended migrations. They almost all seem centered around approving permissions for users rather than the app itself. I have opened an issue on the library OAuth out-of-band token deprecation · Issue #11 · dolfim/django-gmailapi-backend · GitHub, but there wasn’t a consensus on how to handle this.
One option was to use an app password, but that sounds like what I was doing initially. The other option I thought of was to create a page that only I can access to authenticate the application with OAuth, but that seems like a roundabout way of handling this.
I have reached out to Google’s Workspace team about this and should be talking to them soon, but in the few email exchanges I’ve had, they didn’t seem to understand what I was requesting. I’ll update if they give me any relevant information.
I am considering moving to SendGrid or some other service that handles email, but that feels unnecessary since we send so few emails.
Is there some easier way to authenticate with Gmail that I’m missing?
Note: My interpretation is that Gmail is eliminating that mode of authentication for their web interfaces. I have not seen anything stating that SMTP authentication is changing.
(I don’t use the gmail API, I send email through them using SMTP - works great, hasn’t given me any problems.)
That’s what I was doing initially using a password (not the account password, but a generated password through the control panel; I forget what it was officially called). Then I got that first email. Are you doing something different that meant you didn’t get that email?
What method are you using to authenticate using SMTP?
This is what my settings.py looked like before switching to OAuth:
EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp-relay.gmail.com"
EMAIL_HOST_PASSWORD = "password"
EMAIL_HOST_USER = "email@example.com"
No, I got the email - but after digging through what I could find of their documentation, I came to the (quite possibly erroneous) conclusion that what they’re doing doesn’t affect SMTP authentication.
Yes, your settings fundamentally look like what I’m doing.
(Except that I don’t send emails directly from Django. I run a local Postfix server that is the target of my applications, and it forwards the emails out to gmail.com.)
Great, thanks for the info. I was planning to try the app password again in any case, but this makes me feel like it’s probably the way to go. I’ll update if I hear anything of value of from the Google Workspace team when I finally talk to them.
I spoke to a support person with Google Workspace, and he told me that app passwords still work because too many folks were using them for Google to shut down that method of authentication. They still consider it unsafe and they would like to deprecate it, but they don’t have a timeline yet.
He sent me some information about how to possibly authenticate using impersonation in order to continue using the aforementioned library, but I’m not convinced it is an easy fix. Unfortunately, it doesn’t seem as though Google has an easy way to solve this problem.
I’m going to try moving back to the app password, and if it does get deprecated in the future, I’ll probably move to a paid service.