Add support for Gmail's XOAUTH2
gsborisgithub opened this issue Β· 159 comments
I really do not want to allow "less secure apps" in my gmail account.
Would K9Mail be compatible with this gmail security some time in a future?
"Less secure apps", as far as I'm aware, really just means apps that don't use Google's proprietary APIs, rather than using standards like K-9 does.
You can also use an "app-specific password" created from your Google account, which is a part of their two-factor authentication system, which you should be using anyways.
On "less secure apps": https://www.google.com/settings/security/lesssecureapps
On "app-specific passwords": https://support.google.com/accounts/answer/185833
Perhaps this is the reason I periodically receive an e'mail from the Gmail Team stating, "Someone has your password!". So much dreck is peddled by Google.
Implementing XOAuth2 for Google will require us to:
- Obtain a client ID and 'Secret' for K-9 (which will have to be in the APK so may as well be in the repo).
- Implement a screen for users to allow K-9 access to their email (or just a link to an external browser window)
- Implement a follow-on screen to accept the verification code and generate an access code and refresh code.
- Store the refresh code and action codes as their pseudo-passwords
- Use the action code to login (this is quite similar to CRAM_MD5)
- Use the refresh code to periodically refresh the access code (1 hour for Google)
Some of this is common across anyone who uses XOAuth2. But much of it is Google's implementation. It may or may not be the same for different providers. While I'd want the developer to do it in a provider neutral fashion as possible, until you have two it's impossible to know what the changes will be - they could have no concept of token refresh for example.
Whether putting the "client secret" in a public repo is acceptable to Google is a good question.
I would hope so, otherwise it's impossible to use the api for email clients, which sort of defeats the purpose.
As a first step we probably want to limit ourselves to Google accounts set up on the device. Then we can use AccountManager.getAuthToken(β¦) to retrieve the tokens.
If you limit yourselves to Google accounts set up on the device, would that allow for access to both the free consumer Google account signed into the Android device as well as additional Google for Work accounts? I have a K-9 devotee in the family that recently switched their primary email to a Google for Work account and they are being plagued with the "Sign-in attempt prevented" emails and I've been tasked with finding a solution.
The work-around is to use the app-specific passwords @ocdtrekkie mentioned.
As for whether the unimplemented future solution will work for additional GfW accounts, I have no idea - not being sure how they get integrated into a phone. If they get integrated as Google account on the device possibly, depending on the implementation. It's all hypothetical at this point as I've not done much more than the initial look at the protocol.
There's a new xoauth2 branch from work I've done so far.
Here's what works.
- You can now select to authenticate incoming using an OAuth 2.0 token.
- If you do that it will use the AccountManager to try and fetch a token for the email address you provide.
- The IMAPStore now checks for capability for authentication via XOAuth 2 and SASL-IR.
- For authentication it will get a token, and then using the token it will make a XOAUTH2 AUTHENTICATE request. It will handle the continuation response and parse the status response.
Here's what doesn't work/needs work:
- Authentication with Gmail never actually works. So currently you can't get further than account setup :( I have no idea why right now. Google's documentation is a maze and none of it quite covers the interaction between the AccountManager Android API and the GMail XOAUTH authentication. The token type may be wrong (token types are not documented on Google's site, at all - I found a reference to the "mail' token type and it looked right...) or you may need to pass in an Application API Key or you may not be able to auth like this...
- If you are going to use a token you shouldn't need to put in a password. Currently you do. Choosing token auth may well need moving to the email address page which will then need a re-design.
- We can get a list of Google Accounts. So we should do that and allow a user to select the one they want to authenticate for rather than having to type the address and match it (e.g. gmail vs googlemail). This can be part of the re-design of the email address page.
- SMTP doesn't support XOAUTH2 at all yet - I've not looked at it.
- The AccountManager currently gets passed in to the ImapConnection class - like the Connectivity Manager. We probably want a more general AuthTokenProvider.
Think of this branch as like #884 for XOAuth 2. It's not the solution, but it's at least a starting point for someone (maybe me) to get it to work.
Okay, updated branch with some help from cketti regarding finding correct auth type.
Of the list of not working stuff:
- Authentication with Gmail works
- Selecting it is now done in the 'advanced options'.
- When selected, the password fields are hidden and the username field turns into a drop down of the accounts registered.
- Automatic configuration of Gmail accounts now uses XOAUTH2
- SMTP now supports XOAUTH2
- There's an OAuth2TokenProvider interface implemented by the AndroidAccountOAuth2TokenStore which manages tokens
What still needs to be done:
- I need to test token expiry timeouts. I don't want requests to fail periodically, the token get invalidated then the next request works fine. We need to ensure this gets handled gracefully. This might mean tracking invalidation times and invalidating it and getting a new one when it's close.
- I need to test removing the privelege.
- I need to workout how to provide the Application Key
- It'll all need documenting in the manual
So it's working in a very rough state. I wouldn't recommend it unless you're familiar with debugging though just yet.
Testing blocked by
- Support different pre and post-auth capabilities. #1297
I've not run into the capabilities bug recently (I applied cketti's fix). So I've been getting on with testing.
- I've written code that seems to behave correctly for token refresh
- I've started testing non-Gmail accounts ( @AndyCouch ). Not run into any issues so far.
Thought I'd share some screenshots :)
In the first you can see OAuth 2.0 has been checked and the account list is now a drop-down with the list of available Google Accounts. The password field is gone and client-certificate option is greyed out.
In the second you can see the authentication screenshot that appears. Note currently K-9 is an unregistered app. I need to fix this next because I can't work out how to de-auth an unregistered app and if I can't do that I'll be signing up to lots of Gmail accounts :)
@cketti Can you please obtain an API key for this from Google. https://console.developers.google.com/ - if we don't already have a project, create one, search for Gmail API, fill in the consent screen and then obtain the key (you may need to get a SHA1 of the certificate
Hopefully doing one for probably actually want one for com.fsck.k9 is enough and we don't need a separate one for com.fsck.k9.debug.
(I'm asking you because it wants to be done under the same account that holds the Play store stuff I think)
Done.
Thanks. Can you either email me the key (and secret if there is one) or commit it to the repo? They get added to the request sent to Google in the app.
@cketti Waiting for the above to finish this off. I think it's pretty much done otherwise.
Any news regarding this issue or an ETA when it'll be implemented in the F-Droid version of the app?
I think we need to be realistic and understand that if Google implements standards of its own, it is not fault of K9. K9 is the best open-source email app out there and follows all standard email protocols and standards in most transparent manner (how many other apps offer such flexibility).
So if you're serious about not using the Gmail app, then you should not be using Gmail email server either. I have my own email server and bumped into this thread, as my employer uses Google Apps and I wanted to have all my phone email served by K9.
As @ocdtrekkie pointed out
"You can also use an "app-specific password" created from your Google account, which is a part of their two-factor authentication system, which you should be using anyways."
There is everything explained here: https://support.google.com/accounts/answer/185833
Only change is that you use generated password instead of your Google Account usual password, when setting up in K9.
When will this be released?
The branch of code that implements this works (mostly). But the UX is pretty bad and it can't support non-Google XOAUTH implementations. So that needs to be worked on. Making a half-baked solution that only supports Google isn't much good if it makes the others ones harder to do.
Right now we're pretty busy stabilising the current release. At the point that stops or at least becomes manageable I will try and get back to it.
Oh, ok -- I thought because you added the "next stable" tag it'll actually be in the next stable release.
While I agree it's always great to have a very general solution, often this is very costly to achieve. Of all oauth support requests gmail is the one the most users will want to have (easily 90% and more), so if you get this running then making it more general also can be done later. As one of the comments here said: These oauth things are proprietery for all providers -- so most likely you'll have to implement it again each time you want to support another provider :/
I certainly hope it'll be in the next major stable (not a bug fix release) now that PGP/MIME is mostly there.
Initially I did hope that doing it for Google alone would be sufficient. But the big providers are all moving to a post password era following numerous incidents. So it makes no sense not to do it properly once.
There is actually more in common in the back end than you might expect - it's just the initial setup that differs really because only Google uses the Android framework - MS and Yahoo both want you to visit a web page.
What's the status of the OAuth support? I would have thought it would be in 5.205, but it's not.
Per my last comment basically.
The 5.2 code (e.g. 5.201, 5.205) contains the PGP/MIME stuff and associated bug fixes.
A future branch (possibly 5.4 though there are other priorities like handling Doze) will hopefully contain a rework of the on-boarding (account creation) process, including OAuth.
Has something changed on the google side recently? My phone was using a google OTP I had generated 2-3 years ago I think (and which survived several phone-to-phone migrations using Titanium Backup. However, I just tried to set up K9 on a new phone and generated a new OTP from my account. However K9 is responding with wrong password error. Anyone else seeing this?
Please add support of XOauth. It's very important feature. Even less secure access is enabled in the Google account, i'm unable to read mails once I change country or use new public wifi, because Google is requesting login via browser to confirm ebery new unsecure login
@devbazilio It's generally considered impolite on GitHub to make a comment just to say you also want to see a feature. There is already an issue here to request the feature, your comment adds nothing to the discussion. The best way to show your support for a feature is to look at the top right of the original issue for the like + :) icon, and add a thumbs up (:+1:) to the issue.
update: I made a mistake -- keystore doesn't need to be matched any more if not depend on Android account system. So anyone looking forward to use gmail on K-9 can just clone K-9, checkout to my branch, build it from source and install it on phone. OAuth 2.0 of both Gmail and outlook are working now.
Some progress: Now oauth 2.0(no dependency on Android account system) gets working on my GSoC branch(Based on philip's amazing work). But because I used my own debug.keystore to register on Google API Console so only myself can use it for the time being. Please wait for it being merged :)
Screenshot:
@philipwhiuk more than happy to test anything that you may have. I am essentially still using the Gmail application because of my work email requiring Oauth2, and the admins not knowing how to enable application specific password for their users... This would be a huge time saver for my daily workflow. Thanks!
New user here, but this might be more important now. I tried logging in on a new GSuite account/domain using an app password and I get the error seen in this issue. Google also emailed an alert to my account saying they blocked the login.
Google has this text on their help page for App Passwords (under 'Still can't sign in'):
If you're using an app not made by Google and can't sign in, that app's sign-in process might not be secure. If there's a corresponding Google app, we recommend using it instead. For example, if you can't sign in to an email app, use the Gmail app.
I'm not sure what the point of App Passwords is anymore if Google is blocking them, but they are.
My existing Google accounts don't have this issue, and a test account I created on my older GSuite domain worked fine, so whatever new policy this is isn't being fully rolled out yet.
In the meantime is there a workaround to using K9-Mail on my phone with my organization's account? Google does have an option to allow access to less secure apps, but
- My new organization needs to enable it.
- From what I saw with my (unaffected) GSuite account, you also have to disable 2-factor authentication on your account!
New user here, but this might be more important now. I tried logging in on a new GSuite account/domain using an app password and I get the error seen in this issue. Google also emailed an alert to my account saying they blocked the login.
This works for myself and others (2FA + app password) so it must be related to your set-up. Are you sure you're following the documentation for connecting?
Yes, I am. I tested it on a new account on my old domain where it works fine (2FA + app password); it's only on the new domain that those steps fail.
Guys, any updates?
3 years have passed and no still any solution. I stopped using of K9 on phone because I don't want to give a phone number for google. And enabling of less secure apps don't works because Google bans my mailbox at each new IP and asks to login via browser and verify identity by solving captchas/entering other annoying stuff.
It's a very crucial issue.
Same here, reason why I stopped using K9.
This is one of the reasons I stopped using Gmail. And Android. And K9. :|
It's a very crucial issue.
If it's that crucial for you, I'd recommend contributing.
Well there are organizations that let you enable Less secure applications, but not 2FA, my organization's settings are like that despite repeated request to turn on 2FA + application specific passwords. Thunderbird now seems to favor defaulting to OAuth2 for my personal gmail.com address, so this could likely be the future at some point.
Could there maybe be unstable F-Droid releases with gmail support ?
This works for myself and others (2FA + app password) so it must be related to your set-up. Are you sure you're following the documentation for connecting?
I've just changed work-place and I'm unable to use the app password (I have the same setup as my old work-place where the app password still works).
For example, the error for SMTP authentication is:
AUTH PLAIN failed (Username and Password not accepted. Learn more at https://support.google.com/mail/?p=BadCredentials b129sm9992323wmd.24 - gsmtp)
Just confirming what others have observed that this is likely becoming more and more common.
Hi guys. Any news on XOAUTH support? Google keeps buzzing me with suggestions to disable access for less secure apps and K9 is the only one that keeps me from doing so. Thanks and keep up the good work.
Use pep instead of k9. It's a fork of k9 and has this feature finally implemented: https://pep.software/android/ β k9 seems to be dead.
@dreamflasher Thanks for the suggestion. I have the same issue
@mdcclxv Another option is to create an application specific password for K9
@dreamflasher
it works if my personal account was added to device but I'd like to don't that as all bloatware on phone will see and can access my account. I'm now using Bluemail. It's a closed source app, but it doesn't require ore-added google accounts to phone.
@paul70078 app passwords work if you had set up a phone number to google account, I don't want to do that as all stupid sites now want to know my phone number nowaday
@dreamflasher I don't know if I'd call it dead, there has been commits in the last month. But maybe the feature could be merged back from pep
@dreamflasher Why was there a fork? I can't find documentation on this anywhere.
This is not a discussion forum. Please use the mailing list.
This looks to have been fixed in the e foundations Mail fork here: https://gitlab.e.foundation/e/apps/Mail
This looks to have been fixed in the e foundations Mail fork here: https://gitlab.e.foundation/e/apps/Mail
Link on Google Play?
It's not on Google play (you'd have to build the app from source yourself to use it at the moment I think), but thought it might help someone fix this quicker to look at their solution.
I'm not installing some third party app from an unverified source, sorry.
Do not see in current v5.600 that OAuth2 :(
This looks to have been fixed in the e foundations Mail fork here: https://gitlab.e.foundation/e/apps/Mail
Are K9 guys attempting to backport those changes made by /e/?
Probably all /e/ has done just was simply slapping their branding on top of the gmail-branch
I think one option could be to create an oauth client id and secret for every install in that particular Gmail users account. Then k9 mail can access that particular user's Gmail using the newly generated client id and secret from that particular user's account.
The process for generating a client id and getting the secret is outlined here - https://medium.com/@pablo127/google-api-authentication-with-oauth-2-on-the-example-of-gmail-a103c897fd98
K9 mail can easily scrape a simple web page with or without user interaction and retrieve the client secret. Or the user can be asked to paste the client secret.
Most users will be within the allowed limit of 100 oauth accesses for unverified apps.
Effectively make every user his own developer also!
Do you think this is a good idea?
Your thoughts please? Thanks!
@Serkan-devel, when you mentioned a gmail-branch, is it https://github.com/k9mail/k-9/tree/xoauth2 ?
As a note, secure passwords are being deprecated in June 2020 for G Suite accounts.
If this isn't implemented by then then I won't be able to use K9 any more. (Along with, presumably, a fair number of others)
To be honest, FairEmail (https://email.faircode.eu/) has OAuth support already via wizard and has far more flexibility in settings. Also encrypted emails are supported. Also developer is very responsive and considers development proposals quite quickly.
I too will have to move on. This topic has been open for 4 years. Maybe K9 has finally had its day. :(
At least we are not alone - I can confirm that FairEmail (https://email.faircode.eu/) is very strong application and good replacement and worth to try. Especially I like responsive developer and most of my proposals are already accepted and already deployed. Certainly these proposals will be weighted but will be added to todo list as soon as they will be accepted. Relatively fast release cycle and beta releases are working already as stable (ready to be deployed to Google Play and available also in F-Droid). I am very satisfied and also the donation for developer was relatively reasonable if to count what I just described. Donation helps to unlock pro features (https://email.faircode.eu/donate/), e.g. biometric (e.g. fingerprint) authentication, etc.
I could easily add even Hotmail account via wizard, using "Other provider" choice.
Gmail support in fairemail available only on google play build
While I can empathize with people using a different mail system, what I'm looking for is the functionality specified in this issue, for this application.
This is now required. From Google to all Gsuite users dated December 16, 2019:
_Starting February 15, 2021, G Suite accounts will only allow access to apps using OAuth. Password-based access will no longer be supported.
Dear Administrator,
Weβre constantly working to improve the security of your organizationβs Google accounts. As part of this effort, and in consideration of the current threat landscape, weβll be turning off access to less secure apps (LSA) β non-Google apps that can access your Google account with only a username and password, without requiring any additional verification steps. Access through only a username and password makes your account more vulnerable to hijacking attempts. Moving forward, only apps that support a more modern and secure access method called OAuth will be able to access your G Suite account.
Access to LSAs will be turned off in two stages:
June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off.
February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts._
@Serkan-devel, when you mentioned a gmail-branch, is it https://github.com/k9mail/k-9/tree/xoauth2 ?
@je-vv does any other mail-provider have xoauth?
Anyways I prefer a stable client, which won't change much and I won't jump ship to any of these outdated forks that won't contribute their improvements to upstream
side-question: when/if k-9 gets xoauth-support, does that necessarily mean the account will be taken from android settings?
Tried fairemail yesterday shortly, and this only allows for gmail-accounts which are setup-up within the system.
I have two google accounts: one personal for gmail etc, and another one exclusively for android use. I have been using k-9 to prevent that my personal account is being associated with the one I run the device with (--> privacy concerns). So fairmail is out.
Is it technically possible to implement xoauth in a way that is not depending on accounts which are stored in android itself?
It is a lot easier to implement it when you rely on android to handle most of it.
It is a lot easier to implement it when you rely on android to handle most of it.
Relying on system-wide account management makes implementation easier, but it also prevent me using built-in mail client due to privacy reason as @0x4a said (I have 4 personal Gmail account :/ ). I would also looking for an implementation without Android's account management.
By the way, there are apps like Island/Shelter that utilize Android works profile to isolate other apps in another environment. You need to install another copy of k-9 in the sandbox.
Although those isolated accounts still show in accounts, those accounts have no access to data outside sandbox.
@Serkan-devel, I would have preferred to get k9 with the support on production, and available under f-droid, but who knows when it'll get there... For the /e/ K9 fork, you can read about the /e/ default app wiki, and the fork repo. It says to fork from K9, but not if from master or a particular branch...
I'm not using /e/, since I'm still using LineageOS for MicroG, so I can't tell how to download its apk, and how to keep it up to date, other than by installing and using /e/, which I wasn't planning to do.
Tried fairemail yesterday shortly, and this only allows for gmail-accounts which are setup-up within the system.
Have to admit that it is true.
I have two google accounts: one personal for gmail etc, and another one exclusively for android use. I have been using k-9 to prevent that my personal account is being associated with the one I run the device with (--> privacy concerns). So fairmail is out.
I can confirm that FairEmail is perfectly suitable for that purpose to separate different Google Mail mailboxes. I have many different accounts from Google: both GMail and G Suite with organization accounts. You need to disable syncing as soon as possible, presumably turn off internet connectivity before finally adding account - then you have time to make all syncing inactive.
Haven't used it, but FAQ 111 says that it still uses Android account manager for OAuth even if you use the wizard.
(111) Why is OAuth not supported?
OAuth is supported for Gmail via the quick setup wizard. The Android account manager will be used to fetch and refresh OAuth tokens for the selected account.
@edmundlaugasson as long as the account is stored in android, I do not trust google enough to not connect the accounts given. If they have both of the accounts (e.g. the mail address), that is absolutely enough to connect data of both, even if syncing is off.
Call me paranoid, but I don't want to have my contacts, my maps-data and my mobile searches connected with that other account, which basically has all other data there is about me...
If one of the accounts only "exists" within k-9, it is still possible, but much less likely to do that. So on with the topic: implementation of xoauth in k-9 :)
@0x4a and other similar people...
Use /e/ or Librem 5 or whatever else similar - nobody says that you should stick with Google?!?!? But as OAuth has its own requirements binded with Google - you should probably avoid Google Mail at all. Use ProtonMail with .ch or Librem One - be free from Google! There are also many other search engines available than Google...
I personally use posteo.de for mail andduckduckgo for search. But my old gmail fetches mails of about ~5 different other accounts and automatically labels and filters them accordingly. It's hard to get rid of that. So I want to keep it, as Gmail is quite comfortable.
Anyway, I'll wait if/when xoauth comes to k9, and see how I'll go on from there...
Sounds like OAuth support is coming also to F-Droid version of FairEmail. Here is appropriate commit.
Since no one linked to it, here is the official announcement about the change to GSuite policy about password-based authentication: https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
Since no one linked to it, here is the official announcement about the change to GSuite policy about password-based authentication: https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
As @edmundlaugasson and @physkets has already posted this, I won't repeat it.
What i wll add is that I am happy to donate towards having this implemented.
so, since today, k9 mail not possible to be used for gmail accounts ... as no oauth2
seems to be i need to look for another application - very sad about :(
@camelcamro - there are alternatives - https://alternativeto.net/software/k-9/?platform=android - haven't tested them all but I'm using FairEmail for OAuth 2.0
If anybody has a time to test any other Android email client against OAuth 2.0 - please let also us to know here!
Is that OAuth requirement only for GSuite users? I'm no GSuite user, but I do use GMail. Also, wasn't June 2020 the month of disallowing new users that haven't before use LSAs, and February 2021 the month to definitely turn it off, according to gsuite-bblog? I'm still wondering if for those regular non gsuite users, this will affect at all, at least in those announced dates. Wouldn't K9 try a 1st quick approach, perhaps similar to what /e/ mail fork did, and then provide a different more appealing one?
yes, you are right ...
the normal domain @gmail.com still working
but the gsuite for my company with domain @ro****.com not working anymore.
so, i had to change now to FairEmail ... well, it is different, but i have to live with that for now :(
very sad, that it was totally forgotten to be able to handle the OAuth2 to support gmail :(
but that shows that k9 mail is not taking care ... and i would support the team more when possible ... well, i bought kaitenmail as the devels are behind ... but well, maybe it is time to migrate to a product which can deal with the future ...
gsuite works as well. Unless your admin disallows it.
@camelcamro - there are alternatives - https://alternativeto.net/software/k-9/?platform=android - haven't tested them all but I'm using FairEmail for OAuth 2.0
If anybody has a time to test any other Android email client against OAuth 2.0 - please let also us to know here!
@edmundlaugasson please ... NO
NO, we should not discuss alternatives in an issue tracker, please use a search engine to find alternatives to K-9 and its derivates Kaiten, K-@ and Bird
NO, you should not use most of them listed and you should have a look at their agreements, since most "fancy" clients are no real clients like k-9 but cloud services
anyone else: complaints doesn't help, there is a pending PR #3804 from @wiktor-k aside the already discussed work done by @philipwhiuk in late 2016 with no PR https://github.com/k9mail/k-9/compare/xoauth2
based on backend commit 7774ebc since 5.300 from PR #1295
But indeed, THIS issue contains all the relevant discussion about, e.g. #655 (comment)
if it doesn't take the attention and drive you hope to get, it's a mostly a sign of too many "unthankful participants" and too few contributors.
yelling goes to forum please, else you nag those developers that are interested in technical "issue" discussions killing any fun in contributing for an OpenSource project, thank you
It would be nice to see Dev's offer reassurance.
Unfortunately many may not have known better than to use certain providers, but information is available. There are even mailto: protocol forwarding services whose MX Records point to whatever other service you like.
But if there is legit' UNCERTAINTY it's not "FUD" and should be addressed in terms of SOLUTIONS. I disagree with telling someone to go scour some web search, especially not even suggesting Searx, nor offering a source of info'.
But this seems to be an ISSUE for THIS PROJECT, and thusly in it's issue tracking.
Β―_(γ)_/Β―
It appears that later this year Microsoft will be going down the same route with Office 365 as Google is doing with GSuite , and requiring OAUTH 2 capability for all clients.
I tried FreeMail from F-Droid and it won't load Gmail
Kinda useless for this case
Adding support for Oauth in K9 is not REQUIRED to keep using it after february 2021. There is an alternative way to keep using K9 after "non secure apps" is definitively disabled next year. I have tested it today:
App Passwords
https://support.google.com/accounts/answer/185833?hl=en
It works also for Apps domains accounts, with one trick: 2steps needs to be enabled by the domain admin, and this will immediately disable less secure apps for the whole domain; there is no smooth migration possible; you must, in this order:
- login as admin
- enable 2steps for admin (immediately disables less secure app for everyone)
- set 2steps for admin
- enable 2steps for domain
- login as user(s), enable and setup 2 steps
- generate AppPasswords
- reconfigure all your apps
If reconfiguring all your app takes hours, then, your services may be down for ... a few hours.
I have migrated one domain today, and it took me 3h for one domain, 2 users, and 3 apps. Next week I have an other domain with 4 users, 30+ apps, and I don't think I can do it within 2 days.
Note that for K9, the password must be updated in incoming AND outgoing menus; the same password works at both places (was not trivial, had to be checked).
@doublehp The main issue is for GSuite accounts, and users are very likely not their own admins. Organisations (like my own) very often decide to not allow app passwords (mostly because it defaults to off). So this is absolutely necessary.
I can't see anything from Google saying that app passwords will still be useable after the deadline, only that OAUTH must be used.
The deadline for switch over has been withdrawn though due to COVID, and no new date announced yet.
Starting from today, it seems that I can't send emails anymore from K9mail on my gmail account... Not sure if they are disabling accounts progressively, but I can't find any way to send emails from K9mail now (when I try to send an email via K9Mail, the email is put instead in the draft folder, and I get a notification saying my email can't be sent, and when I reconfigure the smtp server, it keeps telling me to connect to my browser). Before I just needed to go on my browser and recognize the device, now it's not working anymore.
Note that I don't want to enable 2 factors authentication (don't want to be locked out of gmail if I don't have my phone, and SMS text are anyway simple to bypass if someone really wants access to my mail), so app password is not a solution for me.
Note that I don't want to enable 2 factors authentication (don't want to be locked out of gmail if I don't have my phone, and SMS text are anyway simple to bypass if someone really wants access to my mail), so app password is not a solution for me.
Buy a Yubikey (or other U2F device) and use it instead. The only accounts I have SMS 2FA enabled on are those that only support 2FA via such a route. Everything else is TOTP where I keep secrets on an encrypted USB key (can't even read it with the phone) and NFC-enabled Yubikeys. If you get multiples, you can have backup keys to use for access in case you lose your main one (I have a number in geographically diverse places).
With 2FA, I have app passwords for now. I suspect eventually we'll need OAuth tokens for K9 which still won't involved anything like that in the email workflow.
yahoo also bothering "...so we need you to make some changes before 20 October 2020."
Any news here? Can't seem to change yahoo to Oauth!?
My university email wont support anything but oauth2 come november 2nd. Is there an open source android mail client that does support it?
I searched on F-Droid and found FairEmail which has this FAQ question. Skimming the list from a search didn't turn up too many other promising candidates, but I admit I didn't do much digging.
The app seems useful, but it seems that you need to use Google Play's version for XOAUTH usage? Something about Android checking app signatures or the like.
Edit: This FAQ entry seems relevant. Seems that to use OAUTH for Google accounts, one will need to use a Google Play-distributed build of the apps.
It also seems that the account needs to be known to Android generally, so just adding an alternative account to an app means tying your device to it in some way. This is likely how any app would end up working.
I guess all I can recommend is to migrate from GMail to elsewhere (I've been migrating to Fastmail this year) since it seems like these problems are more related to Google locking things down than anything the FOSS community can reliably address.
@mathstuf I fully recommend people switch to Fastmail (I switched in 2016), but FWIW, this isn't really an unobtainable goal for open source apps to support, and this issue was opened six years ago. There's a point where you just say a project is abandoned from a major support standpoint and move on.
@ocdtrekkie There is an open pull request for it. #4832 , so I will not think it is so unobtainable. Just needs to be checked and merged. There is also #3804.