Hacker News Reader

Comment by superkuh | Hacker News Reader

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, which is not imap) that's the end of gmail for me.

View on HN

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.

>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.

> Thunderbird does, but that could be Gmail specific

No, it definitely works on Office 365 too.

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.

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.

I have no idea what you are talking about. Every Google service (not just GMail), and every major service provider on the internet, uses OAuth 2 as the standard for authorizing API access.

Reply on news.ycombinator.com