Google provides the App passwords feature:

> An App password is a 16-digit passcode that gives a non-Google app or device permission to access your Google Account. Learn more about how to sign in using App Passwords.

Maybe I misunderstand the announcement, but it looks to me that this feature will still be a valid alternative when Oauth can't be used.

Yeah, and for those that don't, app passwords are not hard to use. Slightly cumbersome, maybe, but I bet it'd take less time than GP took to write their comment.

If Google granted arbitrary and fair access to those OAuth scopes then sure, but they don’t. I have personal experience with this, trust me.

In some cases yeah but not for mail. The GMail API is great but to use it you have to spend like $75k on a security review that Google has to approve.

You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).

You should be able to use the Bearer Token standard from RFC7628 rather than XOAUTH which is something Microsoft cobbled together, but either will probably work on most systems, just one of them is better documented.

e: fyi the ringfence bit in this post is incorrect. Leaving for posterity but don't believe this comment, see replies :)

--

Could just set up an app password limited to accessing gmail, been able to do that for like 10 years now and it's not going away with this change

different password: check

ringfenced access: check

App passwords are not limited in scope, AFAIK.

It said it was when I created one before posting to make sure I was thinking of Gmail and not Fastmail.

Not sure why there'd be a dropdown to select the service if not, maybe I misunderstood

E: I misunderstood, you're correct. The dropdown is for your reference (e.g. "Mail [on] iPhone") and if you select "Other" it's the same as selecting the other dropdown's "Other", it lets you type a custom name. Guess that was never as secure as I'd thought!

I've long since moved to Fastmail which does do the limiting by service, thank you for correcting!

If an email provider does not offer standard pop3 or imap it is not an email provider. It's just some web shit.

they offer both. they simply require more secure authentication. something which doesn't require the app to know the username or password. it's that simple.

IMAP with OAuth is standard. What am I missing?

It is not, in fact, a standard. It's a proprietary complicating thing that megacorps do and everyone else assumes is standard.

https://datatracker.ietf.org/doc/html/rfc6749 "The OAuth 2.0 Authorization Framework"

>This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.

So now you have HTTP protocol being used for IMAP, or worse and more common, not-OAuth over IMAP and you call that standard? These are Microsoft, Google, etc announcements of proprietary things. Not standards. And every single megacorp requires a different custom solution to interact with.

> It is not, in fact, a standard. It's a proprietary complicating thing

Nope, it's a standard. Standards you don't like aren't proprietary, they're just standards which superkuh doesn't like.

It it were standard the same OAuth 2.0 module could be used with every provider of services. The reality is you need a custom implementation for every single megacorp and their local twist. It's not even a defacto standard by collective use.

Why is it an issue that getting a token for use with IMAP requires an out-of-band HTTP request? How do you think SSO works for anything other than web services?