Bilbo47 wrote: ↑2023-12-02, 03:07
[One prefs-set for all Ggl OAuth accounts] Okay but how does that make sense? Yes the email address is different between those accounts. But how does GMail know that I authorize Epyrus to log in for all my Ggl accounts using just those same OAuth keys, if it never went through the usual silly authorization dance that Ggl wants so much? Wouldn't Ggl normally want separate auth keys for each email address/account?
Well, I can't really justify Google's decisions, but let me explain briefly what OAuth2 does.
Those keys are not meant to authorize a specific account, they are meant to authorize a specific
client to use OAuth2 with an e-mail service hosted by a given server. It's an e-mail client developer to e-mail service provider thing that has nothing to do with the user at all, period. If you look at how even Mozilla has implemented this, they have one set of keys for every provider. One of the bugs related to OAuth2 on Epyrus that I was actually able to address, in fact, was that we weren't using our Google keys for a non-Google domain that used Google servers for their corporate e-mail or something.
Now, obviously everyone using the e-mail client doesn't share the same tokens, and would need a different password, which is what I think you are referring to.
Google authorizes Outlook and Thunderbird to send OAuth2 requests for tokens using Google's API, because they are trusted. On top of that, the user
also has to enter a password and confirm that they want the token to be issued. So both Google and the user have to agree to trust Epyrus, independently, for OAuth2 to work.
The problem for me is, Google doesn't trust my client. So I have to find workarounds, like having each user issue themselves a temporary development key or something. This is NOT how OAuth2 is supposed to work, at all. It is supposed to authenticate a client, not a user. I'm trying to work around that because my client isn't trusted. That is to say, this isn't about authenticating the user, this is about you even having the right to get that screen asking if you trust Epyrus and are willing to grant it permissions. You will get that screen on each GMail account separately, and when you confirm you are issuing a token.
What Google is doing with OAuth2, is denying Epyrus and any other client that isn't trusted by them, from even having the right to be granted permissions upon request. They are preemptively saying no, and saying you aren't allowed to give Epyrus permissions to access your account because it isn't a client that meets their standards. It's about protecting their servers, their interests. Not yours... normal passwords with TLS already covered that, this is something totally different.
So the reason why Google assumes you authorize Epyrus to use that OAuth2 key for all the Google accounts? It's because what you're technically claiming to Google when you generate an OAuth2 key and try to use it, is that you're an Epyrus developer and are investigating getting OAuth2 working with it in the future. You're using a developer-focused API to generate a type of key that you as a user are never even supposed to see. You're supposed to be oblivious to this layer of the transaction, and just see username and password prompts like always. It's technically supposed to be my responsibility, which is why Epyrus work is so depressing. Because I know I don't meet those standards Google has laid out, and have no choice but to involve the users directly in this mess of using hacky workarounds that were never intended for users in the first place. Or else eventually find Epyrus limited to random obscure self-hosted e-mail services, which isn't what I want.
So, if this were being done legitimately, here's what the process would look like:
1. I incorporate Epyrus, LLC and pick a registered agent.
2. I create a business-related account with Google.
3. I pay Google (or possibly someone on a short-list of Google-approved auditors) to do a rather stringent third-party audit of the Epyrus codebase (that can cost thousands or millions of dollars).
4. If the audit shows that Epyrus is secure, Google gives Epyrus, LLC an OAuth2 key to be used with Epyrus.
5. I put the OAuth2 key into Epyrus.
6. Users are then given the right to send their username and password through Epyrus (now trusted by Google) to access their Google account, after seeing a screen confirming that's what they want to do and detailing what permissions they are giving it. The user can still have the chance to deny Epyrus permissions, but without the OAuth2 key, the user can't even say no because Google is saying no for them, because they are rejecting the application and its developer from their service as a whole.
Obviously, step 3 is kind of the sticking point... that third-party audit. So we are doing this in a way where each user of the application has to setup a Google developer account and create a "testing" key, as if they were the application's developer. This is the workaround every open-source implementation of OAuth2 that doesn't have big money backing it has to rely on.
They've grandfathered in a lot of the older Google accounts run by people who would complain about this, giving them features like app passwords and use less secure clients that aren't offered to everyone, so it mostly affects younger people who cannot opt-out of OAuth2... and then they tighten their grip, and suddenly all those options go away and people just notice their stuff is broken on less popular clients, so they give up and use the popular ones.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
The instructions by Claws-mail are barely helpful. Maybe I'll write it up better tomorrow, but any HowTo will be out of date as soon as Ggl changes their UI again.