Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[New Feature] Support for GMail OAuth tokens #365

Open
ivelin opened this issue Feb 24, 2021 · 5 comments
Open

[New Feature] Support for GMail OAuth tokens #365

ivelin opened this issue Feb 24, 2021 · 5 comments

Comments

@ivelin
Copy link

ivelin commented Feb 24, 2021

Currently apprise supports gmail via App Passwords. However Google does not recommend use of app passwords any more.

Instead it recommends App Authorization via OAuth 2.0 or Sign In with Google.

https://support.google.com/accounts/answer/185833?hl=en

Rclone is a reference example of an open source project that uses App Authorization to access Google APIs (gdrive) on behalf of a Google Account user.

https://rclone.org/drive/

The specific use case that prompted this feature request is this: IoT device (Ambianic edge) sending email notification to users, who manage their IoT device via an UI app (Ambianic UI). Via the Google App Authorization flow , users can enable gmail notifications with a few clicks. The UI app will push the gmail authorization code to the IoT device, which will in turn pass it to apprise to obtain a gmail access token to be used in future notification requests from that device.

Google API documentation with the details of this flow:

https://developers.google.com/gmail/api/auth/web-server

@caronc
Copy link
Owner

caronc commented Feb 28, 2021

Hi,

I started looking a bit into this, but the complicated parts are setting this up myself so i can test. I presume we'd create something like gmail://client_api/cilent_secret, gmail://?keyfile=/path/to/service.json (where service.json is generated from the Google Admin Panel) and contains all of the private keys needed to connect? But then you're talking about handing the client_api/client_secret (as part of the OAuth2) separately and acquiring the token for yourself ahead of time.

The only problem with this route is it extremely limits the use of Apprise if someone has to to do pre-processing ahead of time. It also makes the gmail:// useless from the CLI (where the pre-processing isn't really an option). But that said, it could probably support gmail://apitoken as well (1 arg = token, 2 arg = id/secret, keyfile= use json file) to handle your case. Some of this is similar to the FCM integration where there is a JSON file generated from the Admin Panel that is needed for OAuth2. The keys within this json file are hundreds and hundreds of characters that span across several lines.... it's just way to many entries to place in a URL. I haven't done too much researching into the gmail thing yet to see if i'll have to use a json file here too and/or if the keys are incredibly long.

I did begin setting myself up following the last link you shared and came faced with this option which also complicates things:
Google Oauth2 Method

I'm not sure how much the setup needs to vary to support both of these options. Which one did you choose for your product? I presume External ?

What were your thoughts in how this might be implemented?

@ivelin
Copy link
Author

ivelin commented Feb 28, 2021

Thank you for looking into this @caronc . Doesn't seem like a trivial thing to implement.
I agree that the app password route offers a great deal of simplicity for many use cases.
The OAuth path is specific to situations when the app can interact with the user via some UI.

Maybe @ncw can offer some guidance based on his successful rsync work on syncing files with Google Drive.

@ncw
Copy link

ncw commented Mar 5, 2021

Doing oauth with google drive is hard - I assume gmail is similar.

Setting up the app (client_id/client_secret) and getting it authorized is a real slog. Last time I did it with Google Photos I had to write loads of docs and make a video!

Then you have the whole oauth flow which is painful too!

If you can use the JSON service files then that makes life a bit easier.

@ivelin
Copy link
Author

ivelin commented Mar 5, 2021

@ncw thank you for taking the time to comment.

I do not have enough direct experience with either and still catching up on docs. This doc seems to offer a clear flow.

Maybe apprise should delegate to the app all steps of the flow up to and including the point of obtaining an access token. Apprise only handles the last step of this flow: calling Google APIs with the access token.

The app can be also responsible for refreshing the token periodically.

flow

So from apprise perspective , it might be a matter of referencing this Google OAuth document and allowing use of OAuth access token as an alternative to the current app password method.

@caronc
Copy link
Owner

caronc commented Dec 15, 2024

I hit a bit of a wall...

According to the Google documentation, the new way of doing things is to request a Device Token after you've set up a Desktop App. Unfortunatey this WILL require manual intevention to follow a provided hyperlink and put in a number validating the device code the first time this step is performed. This new way forward has no means of avoiding this manual intervention (from what i've found so far).

After the Token is authorized by you (using the manual intervention), the token to keep your session alive lasts 6 months; Apprise will be clever enough to renew/refresh it before it expires, so this part can be automated from that point forward. The manual part is only required once (but it won't be accepted well - it drives me nuts just thinking about it). This new Gmail adaptation will now the first plugin Apprise has that doesn't work out of the box. Again... unfortunately the limitations are on Googles end, and not Apprise. I start looking to see if we can use a JWT token instead; but from what i read so far, i don't think it's possible.

Anyway... that's the long story... the short story is: the code doesn't seem to work. It's as though Google documented the steps to get a Device Token after following through with steps in #1250 but it always returns a 401. At this time i really don't know why. I've pushed all my code, maybe one of you could have a peak and let me know what you think. A second pair of eyes would help.

For example (Apprise aside), the following should work, but it does not for me (it ALWAYS returns 401 in my case):

# Cllient ID is retrieved from: https://console.cloud.google.com/apis/credentials
ClLIENT_ID=12345-xxxxxx.apps.googleusercontent.com
curl -d "client_id=$CLIENT_ID&scope=email"   https://oauth2.googleapis.com/device/code

I always get (and so does Apprise):

{
  "error": "invalid_client",
  "error_description": "Invalid client type."
}

Since i'm blocked now, i can't proceed further on this gmail:// adaptation 😦

Any advice would be most appreciated 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants