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

Add support for OAuth 2.0 (Gmail) #6082

Merged
merged 1 commit into from May 28, 2022
Merged

Add support for OAuth 2.0 (Gmail) #6082

merged 1 commit into from May 28, 2022

Conversation

cketti
Copy link
Member

@cketti cketti commented May 23, 2022

The implementation cuts a few corners. The plan is to clean this up when we rework the account setup code to support Thunderbird's Autoconfiguration (#865).

Fixes #655

@Monkey-Matt
Copy link
Contributor

Monkey-Matt commented May 24, 2022

I've been testing this out and looks to be working well.

One (minor) unfortunate case I found was if you enter a non gmail email address (eg spelling mistake) and click next it shows the password field, then if you change the email to a gmail account it still requires the password to be filled before you can continue. If you enter something in the password it does navigate through the oauth flow correctly so it's not much of an issue.

If this progresses is it possibly to "verify the app with google" so we don't get the aggressive warning? Not sure what that involves but I'm just imagining the concerned forum posts that might result on seeing the warning.

@cketti
Copy link
Member Author

cketti commented May 24, 2022

Thanks for having a look.

One (minor) unfortunate case I found was if you enter a non gmail email address (eg spelling mistake) and click next it shows the password field, then if you change the email to a gmail account it still requires the password to be filled before you can continue. If you enter something in the password it does navigate through the oauth flow correctly so it's not much of an issue.

I didn't want to check the providers file all the time. I'm hoping not many people will run into this, and if they do, they'll find a way out. You described one workaround, the other one is to go back and start over.

When rewriting the account setup, I want to change the flow to better handle this case.

If this progresses is it possibly to "verify the app with google" so we don't get the aggressive warning? Not sure what that involves but I'm just imagining the concerned forum posts that might result on seeing the warning.

That's the idea. I'm currently waiting to hear back from someone who already went through the process. Ideally the free-form text asking for a justification for the "restricted scope" will include all the points Google cares about to avoid a long back and forth.

@cketti cketti merged commit 5065afe into main May 28, 2022
@cketti cketti deleted the oauth_setup_flow branch May 28, 2022 13:44
@mmhere
Copy link

mmhere commented May 29, 2022

What's the best way to take advantage of the hard work accomplished here in enabling OAuth? It looks like the [much appreciated] effort is merged into main, but I've only ever installed .apk files from https://github.com/k9mail/k-9/releases.

Google's "30 May" deadline looms (as I'm sure everyone is aware, but I thought I'd bang the drum one more time anyway -- please don't take that the wrong way as it is only meant as a reminder).

@Monkey-Matt
Copy link
Contributor

What's the best way to take advantage of the hard work accomplished here in enabling OAuth? It looks like the [much appreciated] effort is merged into main, but I've only ever installed .apk files from https://github.com/k9mail/k-9/releases.

Until there is a new release the only way to install the latest work is to build the project yourself.

Google's "30 May" deadline looms (as I'm sure everyone is aware, but I thought I'd bang the drum one more time anyway -- please don't take that the wrong way as it is only meant as a reminder).

Existing/previous versions of K-9 will continue to work with gmail after that deadline, you simply have to use an "app password" from gmail. https://forum.k9mail.app/t/oauth2-authentication/2671/38?u=monkeymatt

@cketti
Copy link
Member Author

cketti commented May 30, 2022

See https://forum.k9mail.app/t/the-plan-for-k-9-mail-6-200/4590/4

@mmhere
Copy link

mmhere commented May 30, 2022

comments in response to "just use 2FA for app password" over there:https://forum.k9mail.app/t/the-plan-for-k-9-mail-6-200/4590/5 so as not to turn this here into a discussion thread.

)

val applicationId = getApplication<Application>().packageName
val redirectUri = Uri.parse("$applicationId:/oauth2redirect")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be $applicationId://oauth2redirect with two slashes?
It seems the Microsoft Azure console does not allow adding a redirection URI with just one slash.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed the example of the AppAuth-Android library. They're only using one slash.

When testing with com.fsck.k9.debug://oauth2redirect, I'm getting a "invalid_request" error from Google. But it looks like the library itself doesn't care. So if we make the redirect URI part of OAuthConfiguration we should be able to make it work with Google (use one slash) and Microsoft (use two slashes). I'd welcome a pull request for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am trying to make this work with Office365/Outlook.
Are you maybe already working on this?
If not, I will open a new issue/MR for it.
But the blocker point will likely be to setup a k9mail application on Microsoft Azure, to have a dedicated client-id and allow the k9mail redirection URL.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's already an issue for it: #1753

I'm currently not working on this. So please feel free to provide a PR. Just add a placeholder for the client ID. I'll register one for K-9 Mail before merging the code.

@lewri
Copy link

lewri commented May 31, 2022

Is this implementation planning to support custom domains that use Google Workspace? I currently use two (three, technically) so would be interested to know if this PR supports that.

Edit: Though I feel logging in with Oauth2 may end up causing the problem I was avoiding all along on an android phone -- subverting google/android device policy.

@dragnev-dev
Copy link

dragnev-dev commented May 31, 2022

Is this implementation planning to support custom domains that use Google Workspace?

I tested it with my school email which is on the school domain and it works.

EDIT: as cketti said it's not 100% seamless – after entering the email, I got prompted and explicitly chose OAuth and entered Gmail's server addresses.

@cketti
Copy link
Member Author

cketti commented May 31, 2022

K-9 Mail currently doesn't support automatic setup for email addresses whose domains are not in its providers.xml file. However, if you manually set up the account and select "OAuth 2.0" under "Authentication", it should work as long as the server names are imap.gmail.com and smtp.gmail.com.

And K-9 Mail does not require you to add Google accounts as system accounts (that can be used by all installed Google apps).

@x2611
Copy link

x2611 commented Jun 2, 2022

However, if you manually set up the account and select "OAuth 2.0" under "Authentication", it should work as long as the server names are imap.gmail.com and smtp.gmail.com.

There is no "OAuth 2.0" under "Authentication".
Only:
Normal password
Encrypted password
Client certificate

v6.000.

EDIT > I read in other thread that this is in planning stage for 6.200. Looking forward to it.

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

Successfully merging this pull request may close these issues.

Add support for Gmail's XOAUTH2
7 participants