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
Conversation
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. |
Thanks for having a look.
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.
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. |
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). |
Until there is a new release the only way to install the latest work is to build the project yourself.
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 |
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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
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. |
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 And K-9 Mail does not require you to add Google accounts as system accounts (that can be used by all installed Google apps). |
There is no "OAuth 2.0" under "Authentication". v6.000. EDIT > I read in other thread that this is in planning stage for 6.200. Looking forward to it. |
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