Gmail OAuth client as notifier

[doraeric]

Description

Currently, there are 2 methods to send notifications: filesystem and smtp. With smtp provider, if we want to connect to gmail, we need to set up an app password that can be used for purposes beyond just sending emails. It's a less secure option.

If we can setup oauth client and grant authelia sending email permission, it would be more secure.

Use Case

User setup gmail as notifier, authelia asks for sending email permission, user agrees and receives notification from email.

Details

No response

Documentation

OpenID Connect  |  Authentication  |  Google for Developers

Pre-Submission Checklist

• I agree to follow the Code of Conduct

• I have checked for related issues and checked the documentation

[glime-ai]

Please note this response was created using generative AI leveraging previously available information from the repository. This information may be helpful however it is our strong recommendation that you carefully consider the information before blindly applying it.

---

Currently, Authelia supports notifications via filesystem and SMTP methods. For SMTP, while it is possible to use services like Gmail by setting up an app password, Authelia does not currently support OAuth for SMTP authentication directly within its configuration.

To securely use Gmail with SMTP in Authelia, you would indeed set up an app password. This method, while less secure than OAuth, is supported because Authelia's SMTP notification setup does not include OAuth authentication capabilities at this time.

If you are looking for a more secure method like OAuth for sending emails, this would require significant changes to Authelia's codebase to support OAuth as an authentication method for SMTP. This feature is not currently available in Authelia, and there is no indication from the available documentation that it will be implemented soon.

For now, using an app password is the recommended approach if you choose to use Gmail with Authelia's SMTP notifications. If OAuth support is crucial for your setup, you might need to consider alternative solutions or custom modifications to Authelia, or wait until such a feature might be added in future releases.

This comment was generated by Glime.

[james-d-elliott]

Please show specifically how you think it's less secure for users of Authelia.

Also unless I'm missing something here, the end user doesn't have permission to grant consent to send email as the from email address, and it would be considerably insecure to allow them access to do so as it would allow end users to impersonate the Authelia service.

Thanks for deciding to be involved in the community. While we may or may not accept this feature on the merits we always carefully weigh the pros and cons of each idea.

[doraeric]

Thank you for your prompt response. I believe I may not have expressed myself clearly enough, so let me clarify.

As the administrator of the server, I want to set up the Authelia service and make it available for use by our team. I'd like Authelia to send emails using my personal gmail when necessary. According to the documentation, I need to enable an app password in my Google account to allow Authelia to send emails using my gmail.

What I'm proposing is for Authelia to act as an OAuth client, requesting permission to send emails via my Gmail account. As the administrator, I would then authorize Authelia to send emails on behalf of others using my mailbox.

Regarding security considerations, my concern is that if the server running Authelia were to be compromised, my app password could be obtained. This password not only allows sending emails but also grants access to any Google service, such as accessing and modifying files on Google Drive. However, if Authelia were to obtain sending permissions as an OAuth client, even if the server were compromised and the token leaked, it would only be usable for sending emails and would not grant access to my Google Drive.

I hope this clarifies my issue.

[james-d-elliott]

I think this is a somewhat trivial issue to solve without the need for a complex implementation. A separate account for emails like this would solve all of the concerns mentioned. I don't think it'd be a good design decision at this time to support the Authorization Code Flow for this particular purpose as this flow is user-interactive, and would require a completely user-interactive setup (rather than a declarative YAML setup). However we'd be willing to support an architecture appropriate flow for this.

The Client Credentials Flow / Grant Type is appropriate for this specific scenario in this architecture. Unfortunately it does not seem like Google supports this (Microsoft does). The only other flow that really supports the current architecture is the Refresh Flow. Which would mean provisioning the access and refresh tokens would have to occur out-of-band from normal operation via the CLI to satisfy these requirements.