Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oauth2 support for GMail

pmail.com

Post reply on HN
Print view View original

71–80 of 136 posts

Re: Oauth2 support for GMail

#71

Post by jeroenhd »

superkuh wrote: post #69

Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in. When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap,…

OAuth is hardly Google only, it's part of RFC7628. There are very good reasons why a simple password login isn't necessarily what you want for your email protocol. IMAP and 2FA are often at odds, for example, usually leading to vulnerable application passwords that bypass security requirements out of necessity.

I don't think many email clients support OAuth2 (Thunderbird does, but that could be Gmail specific?) but the concept isn't inherently bad, in my opinion.

I don't really see the problem with OAuth2 itself, the email space is just very very slow at accepting new standards. Dovecot and UTF8 email addresses still don't play well together, for example. The lack of proper on-the-fly application registration for mail servers is annoying, but supporting them should be easy enough if the mail service isn't run by complete doofuses.

Re: Oauth2 support for GMail

#73

Post by Alex3917 »

Fizzadar wrote: post #25

I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally. By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience). [1] https://kanmail.io

> The third party audit is not required for email clients that run on end users computers and store credentials locally.

It might not be required for applications that run locally, but they don't tell you whether or not it will be required until after you've already done the work to create the app.

The exact wording from the FAQ is:

"Local Data Storage: Local client applications don't need to undergo a security assessment because data is run, stored, and processed only on the user's device. Local client applications that only allow user- configured transmissions of Restricted Scope data from the device may be exempt from this requirement."

Keep in mind that any email client that allows you to reply to (or forward) an email would count as transmitting restricted scope data from the user's device.

Re: Oauth2 support for GMail

#74

Post by superkuh »

jeroenhd wrote: post #71
superkuh wrote: post #69

Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in. When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap,…

OAuth is hardly Google only, it's part of RFC7628. There are very good reasons why a simple password login isn't necessarily what you want for your email protocol. IMAP and 2FA are often at odds, for example, usually leading to vulnerable application passwords that bypass security requirements out of necessity. I don't think many email clients support OAuth2 (Thunderbird does, but that could be Gmail specific?) but t…

>OAuth is hardly Google only,

To be clear, I never said OAuth2 was google only. I said the standard OAuth2 is so much not a standard that an implementation written for Google's imap+OAuth2 will not work for any other email provider's imap+OAuth2.

Re: Oauth2 support for GMail

#75

Post by fivre »

superkuh wrote: post #69

Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in. When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap,…

OAuth2 is a suite of protocols and standards you can use to build an auth system from people who have been working on auth systems for a while. it isn't strictly designed for federated auth, and arguably is targeted at internal systems because there are so many parts are "you need a system that does this, but how is up to you"

OIDC builds on OAuth2 to fill in those gaps with prescribed details and add additional systems necessary for a workable federated auth system. it _should_ be possible to use it entirely provider-agnostic fashion, but in practice it's like any complex protocol with optional parts in that implementations have incorrect bits or idiosyncrasies (why does Azure's provider sometimes serve public keys it doesn't actually use to sign tokens in some modes? god only knows) and you'll probably only provide integrations for a subset of providers, not just let anyone with a discovery link show up and use it.

Re: Oauth2 support for GMail

#76

Post by mawise »

tut-urut-utut wrote: post #49
xbar wrote: post #48

And so it is time to relegate my Gmail account to an auto-forwarder.

If you own your mail domain, it's the time to move off from Gmail. If not, make a clear cut, purchase domain, and never ever be at the mercy of mail provider.

This is so hard. I bought a domain and even started paying for (non-google) email on it over a year ago. But I can't bring my self to start the painful process of migrating everything.

Re: Oauth2 support for GMail

#77

Post by joshuamorton »

Alex3917 wrote: post #73
Fizzadar wrote: post #25

I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally. By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience). [1] https://kanmail.io

> The third party audit is not required for email clients that run on end users computers and store credentials locally. It might not be required for applications that run locally, but they don't tell you whether or not it will be required until after you've already done the work to create the app. The exact wording from the FAQ is: "Local Data Storage: Local client applications don't need to undergo a security asses…

> Keep in mind that any email client that allows you to reply to (or forward) an email would count as transmitting restricted scope data from the user's device.

Not if it does so only via the oauth api?

Re: Oauth2 support for GMail

#78

Post by wila »

corentin88 wrote: post #28

I believe many comments here will criticize Google. But objectively, Google is at its best here: - in terms of privacy, applications that have access to your Gmail inbox now require a security audit. - the audit is not required for MVP ( Of course, you have to pay for the audit. But: - it’s only required when you ask for restricted user data (i.e. reading my emails). - Google doesn’t take 30% of your revenue to use i…

> And that says a lot when I read the developer of Pegasus Mail doesn’t want to record a 2min long YouTube screencast to get approved.

Congrats on misreading the article. That's not the problem. The problem is having to spend a lot of money for a security audit for free software.

Re: Oauth2 support for GMail

#79

Post by onphonenow »

undecisive wrote: post #51
Fizzadar wrote: post #25

I’ve gone through this process for my email client Kanmail [1]. The third party audit is not required for email clients that run on end users computers and store credentials locally. By the looks of it Pegasus falls into this category and should not have any issues getting approved (still need the YT video and such but the Google team are surprisingly responsive and helpful in my experience). [1] https://kanmail.io

The wording seems to imply that if, on a yearly whim, someone at Google decides to "empanel" a security assessment team, you have no choice, you will not necessarily be asked permission and you will be paying that invoice whether or not you needed that assessment. Do you have evidence - in writing - to the contrary from a Google official? Abridged wording and my non-lawyer interpretation below in case I'm not clear:…

Google SHOULD NOT promise anything else. This is critical for users security.

Yes, developers and business claim they make user data, privacy and security a top priority. As we have seen from plenty of developers on the facebook platform, if not checked, they far to often lie, betray users trust or are just totally incompetent.

At least on the business side, giving restricted scopes access (ie, enabling a third party server to read all emails in a domain) is a major permission. It needs to be treated like this. In many cases a problem here unlocks a LOT more because email is used the default password for everything (via password reset options and more).

I hope google holds a firm line here and doesn't bow to hacker news type social media pressures - we have too much evidence of bad and poor behavior by developers to just trust them.

Re: Oauth2 support for GMail

#80

Post by superkuh »

fivre wrote: post #75
superkuh wrote: post #69

Note that this "OAuth2" support is only for gmail. OAuth 2 is not really an open protocol like OAuth (1) was. It's just something the megacorps shoved down the IETF's throat and every implementation is different enough to need different software. OAuth2 is not good for the health of the internet and will lead to even more lock in. When Google disables imap at the end of the month for gmail (only allowing OAuth2+imap,…

OAuth2 is a suite of protocols and standards you can use to build an auth system from people who have been working on auth systems for a while. it isn't strictly designed for federated auth, and arguably is targeted at internal systems because there are so many parts are "you need a system that does this, but how is up to you" OIDC builds on OAuth2 to fill in those gaps with prescribed details and add additional syst…

I don't even mean federated auth.

I mean if you take some email client application that went out of it's way to support OAuth2+imap for google via a plugin then even if you replace all of google's info in the plugin it won't work for other OAuth2+imap implementations. Every OAuth2 implementation is a different thing, as you say. But the megacorps are pretending it's some standard protocol. It's not and the fallout will be much worse than people having issues because they picked easy passwords.

This is massively different than actual protocols like pop3 or imap where all you do is change the info but the protocol stays the same.

Post reply on HN