tpitale
Support for OAuth
Hi @tpitale ,
With Google making the announcement of removing the LSA option for accessing the email accounts and Microsoft having similar plans for it, can we start adding OAuth support to mail_room to ensure continued access to these email accounts without major changes.
I'm not a Ruby expert but would love to collaborate and help on this.
Useful links:
[1] - https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html [2] - https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html
It's possible, but oauth is such a huge pain to support that we might only be able to do like an oauth service account or something. There's no UI to redirect to, etc etc.
I understand, my thoughts were for end-user accounts where we let the application developer handle the OAuth app configuration and redirects b/w the ID Provider (Google / Microsoft) and mail_room then starts the communication from the authorization_code received from the first exchange.
Basically it means the user app handles the first step of communication, mail_room has access to the OAuth app's credentials, mail_room then receives the auth code, uses it to get the access tokens, and later on can use the refresh token to get a new access token
We could also extend support for service accounts, but with service accounts I think to be able to read User data (their mailbox), GSuite admin(s) will have to enable domain-wide access to the service account. Whereas with the first one each user gets to choose whether to allow the app to connect or not, which most probably is always going to be just one account for each org.
With the first approach, an app developer needs to create only one app in the Google console using which they can authenticate all sets of users.
Let me know your thoughts on this.
MailRoom is generally meant to run as a standalone, pre-configured process. So the scenario you described is not a use-case I'm familiar with users using MailRoom. I don't know that MailRoom runs well, or at all, in the way you described. I don't recall that it can receive configuration changes after it has started (but I've not reviewed the code in some time). MailRoom is not meant to run and listen on users' inboxes. It is meant to be an "easy" way to have a service on a small set of mailboxes that the operator of an application owns themselves.
The canonical example of this is a service like gitlab, which allows a user to reply, via email, to a thread. I believe github does the same.
In the case you describe, I would advise not using MailRoom, and instead using imap or one of google's libraries or something directly within the application.
Given this constraint, service accounts are the path I'd be willing to support.
https://github.com/googleapis/google-api-ruby-client/blob/master/docs/oauth-server.md
Hey @tpitale , been a long time since I last followed up on this, yes service account is the right option for the mail_room gem. Do we have any timeline on adding this support?
Yes, even I wish to contribute, but haven't got a chance to work on this so far. So just checking up if this is something already in your to-do list.
Issues are my to-do list. But I'm just not doing a ton of OSS work, right now. If I have some time, I'm sure I'll take a look. I just don't.
https://gitlab.com/gitlab-org/gitlab-mail_room/-/merge_requests/15 has support for GMail and Microsoft OAuth2. We will upstream it as soon as we can.
Service accounts cannot be used without granting overly permissive permissions. Gmail requires a service account to have full access to everyone's account in the Google Apps domain. Microsoft has a similar requirement.
It turns out refresh tokens will definitely expire, so service accounts should be used, at least with Microsoft. Also, Microsoft does have the ability to restrict access to a single mailbox. https://gitlab.com/gitlab-org/gitlab-mail_room/-/merge_requests/18 generally works, though it requires more testing and documentation. #115 is the first step to supporting the Microsoft Graph API with OAuth2.
https://github.com/tpitale/mail_room/pull/125 added support for OAuth2 and Microsoft Graph API. https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access can be used to restrict access to a specific mailbox.
As I mentioned above, Google requires a service account to have full authority to read/write in all users' mailbox (https://developers.google.com/identity/protocols/oauth2/service-account#delegatingauthority). I don't see a way to lock down the service account to specific mailboxes.