Add support for Gmail's XOAUTH2 #655

Open
gsborisgithub opened this Issue May 22, 2015 · 32 comments

Comments

@gsborisgithub

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?

@ocdtrekkie

This comment has been minimized.

Show comment
Hide comment
@ocdtrekkie

ocdtrekkie May 22, 2015

"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

"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

@cketti cketti changed the title from Gmail blocks K9Mail App sign-in attempt to Add support for Gmail's XOAUTH2 May 23, 2015

@cketti cketti added the enhancement label May 23, 2015

@cketti

This comment has been minimized.

Show comment
Hide comment
@locutis-of-borg-1999

This comment has been minimized.

Show comment
Hide comment
@locutis-of-borg-1999

locutis-of-borg-1999 Feb 23, 2016

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.

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Mar 30, 2016

Member

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.

Member

philipwhiuk commented Mar 30, 2016

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.

@Valodim

This comment has been minimized.

Show comment
Hide comment
@Valodim

Valodim Mar 30, 2016

Contributor

I would hope so, otherwise it's impossible to use the api for email clients, which sort of defeats the purpose.

Contributor

Valodim commented Mar 30, 2016

I would hope so, otherwise it's impossible to use the api for email clients, which sort of defeats the purpose.

@cketti

This comment has been minimized.

Show comment
Hide comment
@cketti

cketti Mar 30, 2016

Member

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.

Member

cketti commented Mar 30, 2016

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.

@AndyCouch

This comment has been minimized.

Show comment
Hide comment
@AndyCouch

AndyCouch Apr 14, 2016

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.

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 14, 2016

Member

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.

Member

philipwhiuk commented Apr 14, 2016

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 16, 2016

Member

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.

Member

philipwhiuk commented Apr 16, 2016

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 16, 2016

Member

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.

Member

philipwhiuk commented Apr 16, 2016

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 17, 2016

Member

Testing blocked by

  • Support different pre and post-auth capabilities. #1297
Member

philipwhiuk commented Apr 17, 2016

Testing blocked by

  • Support different pre and post-auth capabilities. #1297
@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 19, 2016

Member

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 :)

screenshot_20160419-022735
screenshot_20160419-024046

Member

philipwhiuk commented Apr 19, 2016

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 :)

screenshot_20160419-022735
screenshot_20160419-024046

@philipwhiuk philipwhiuk self-assigned this Apr 19, 2016

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 19, 2016

Member

@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)

Member

philipwhiuk commented Apr 19, 2016

@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)

@cketti

This comment has been minimized.

Show comment
Hide comment
@cketti

cketti Apr 20, 2016

Member

Done.

Member

cketti commented Apr 20, 2016

Done.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Apr 20, 2016

Member

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.

Member

philipwhiuk commented Apr 20, 2016

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.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk May 2, 2016

Member

@cketti Waiting for the above to finish this off. I think it's pretty much done otherwise.

Member

philipwhiuk commented May 2, 2016

@cketti Waiting for the above to finish this off. I think it's pretty much done otherwise.

@thilo-dual

This comment has been minimized.

Show comment
Hide comment
@thilo-dual

thilo-dual Jun 29, 2016

Any news regarding this issue or an ETA when it'll be implemented in the F-Droid version of the app?

Any news regarding this issue or an ETA when it'll be implemented in the F-Droid version of the app?

@chris-y-meyers

This comment has been minimized.

Show comment
Hide comment
@chris-y-meyers

chris-y-meyers Jul 10, 2016

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.

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.

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jan 5, 2017

When will this be released?

When will this be released?

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Jan 6, 2017

Member

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.

Member

philipwhiuk commented Jan 6, 2017

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.

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jan 6, 2017

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 :/

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 :/

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Jan 6, 2017

Member

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.

Member

philipwhiuk commented Jan 6, 2017

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.

@chiaramail

This comment has been minimized.

Show comment
Hide comment
@chiaramail

chiaramail Mar 8, 2017

What's the status of the OAuth support? I would have thought it would be in 5.205, but it's not.

What's the status of the OAuth support? I would have thought it would be in 5.205, but it's not.

@philipwhiuk

This comment has been minimized.

Show comment
Hide comment
@philipwhiuk

philipwhiuk Mar 8, 2017

Member

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.

Member

philipwhiuk commented Mar 8, 2017

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.

@greenawayj

This comment has been minimized.

Show comment
Hide comment
@greenawayj

greenawayj Jul 14, 2017

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?

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?

@devbazilio

This comment has been minimized.

Show comment
Hide comment
@devbazilio

devbazilio Aug 14, 2017

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

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

@ocdtrekkie

This comment has been minimized.

Show comment
Hide comment
@ocdtrekkie

ocdtrekkie Aug 14, 2017

@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 (👍) to the issue.

@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 (👍) to the issue.

@daquexian

This comment has been minimized.

Show comment
Hide comment
@daquexian

daquexian Aug 18, 2017

Member

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:

k9oauth2-1
k9oauth2-2
k9oauth2-3

Member

daquexian commented Aug 18, 2017

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:

k9oauth2-1
k9oauth2-2
k9oauth2-3

@philipwhiuk philipwhiuk assigned daquexian and unassigned philipwhiuk Aug 30, 2017

@k9mail k9mail deleted a comment from CHEF-KOCH Dec 29, 2017

@k9mail k9mail deleted a comment from invy Dec 29, 2017

@philipwhiuk philipwhiuk added this to In Progress in Design Overhaul Jan 10, 2018

@philipwhiuk philipwhiuk added this to To Do in Modernize IMAP Jan 25, 2018

@philipwhiuk philipwhiuk moved this from To Do to In progress in Modernize IMAP Jan 25, 2018

@ffainelli

This comment has been minimized.

Show comment
Hide comment
@ffainelli

ffainelli Feb 27, 2018

@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!

@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!

@jatherrien

This comment has been minimized.

Show comment
Hide comment
@jatherrien

jatherrien Jun 23, 2018

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

  1. My new organization needs to enable it.
  2. 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.

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

  1. My new organization needs to enable it.
  2. From what I saw with my (unaffected) GSuite account, you also have to disable 2-factor authentication on your account!
@colans

This comment has been minimized.

Show comment
Hide comment
@colans

colans Jun 25, 2018

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?

colans commented Jun 25, 2018

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?

@jatherrien

This comment has been minimized.

Show comment
Hide comment
@jatherrien

jatherrien Jun 25, 2018

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.

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.

This was referenced Jul 12, 2018

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