Vlákno názorů k článku
Thunderbird plánuje během tří let kompletně předělat rozhraní od koska - Hmm a kdy začnou pracovat na tom, aby...

Ale to vůbec neodpovídá tomu popisu v článku a tomu na co jsem pochopil že má oauth být. Dle článku a jak jsem to pochopil i z jiných dříve studovaných materiálů:

- klient si vymyslí ID a secret a řekne scope (k jakým prostředkům chce přístup) a endpoint URI (kam se mu POSTne výsledek autentizace)
- já (majitel Google účtu) řeknu „ano tohle schvaluji“
- Google postne na endpoint URI token; na endpoint URI typicky poslouchá klient, uloží si token a ten pak používá pro přístup k prostředkům

Proč ty požadované údaje („co je v tokenu“ - mail, fotka? proč? myslel jsem že token je čistě něco jako „unikátní heslo“, a privilegia) neposílám v tom scopes?

Výsledek tedy je, že když vyrobím emailového klienta, a ten má podporovat všechny možné poskytovatele (stejně jako dříve podporoval všechny poskytovatele co měli „normální IMAP s heslem“) - GMail, MS365, různé MS365 hostované u každé firmy on-premise - tak si musím u každého založit účet, „appku“, a co teda vlastně ta appka přesně dělá? Přesněji, založení aplikace mi dá client id (které nemůže být tajné, protože je třeba nahardcodované v Thunderbirdu a každý si ho může přečíst) a to pak zadávám když žádám o autentizaci (tj. client ID není ID „počítače“ ale appky?), secret je předpokládám unikátní vygenerovaný na „počítači“, a co dělá online část té aplikace? Uloží token zašifrovaný secretem(?) který dostane POSTnutý od Authorization serveru a pak ho mému emailovému klientovi poskytne poté co se zeptá jestli už autorizace proběhla?

> Aplikaciu musis pouzit pretoze nikto nevie ako ty konkretne mas nastavenu autorizaciu, login/pass, 2nd factor, aky 2nd factor, crossdomain autorizaciu, rozne dalsie vyzvy, ...

Ne, to mě přece nezajímá, pointa je že klient požádá o autorizaci a pak uživatel toto schvaluje libovolným způsobem (ideálně ve svém browseru, v horším případě - Thunderbird - v embedded browseru), klientovi je úplně jedno jak.

(díky moc jestli mi tohle vysvětlíš, už jsem to chtěl dlouho nastudovat a přišlo mi to právě hrozně komplikované)

Ano je to komplikovane ;-)
Token nie je plain random cislo ale tzv JWT token pretoze google podporuje OIDC. Vo vseobecnosti token MOZE byt random cislo ale v pripade OIDC to musi byt podpisany kus informacie. Viac napriklad tu:
https://stackoverflow.com/questions/20159782/how-can-i-decode-a-google-oauth-2-0-jwt-openid-connect-in-a-node-app
Ak si ho chces dekodovat skus toto:
https://jwt.io/

Google nic nepostne urobi redirect (302). To co posle google zalezi od nastaveneho FLOW. Tych flow je niekolko:
https://darutk.medium.com/diagrams-of-all-the-openid-connect-flows-6968e3990660

No a to ako funguje Thunderbird je prave dovod preco je prehlaseny za nebezpecnu aplikaciu pretoze si drzi access_token (a refresh_token) u seba a je to tucna aplikacia. Nefuguju tam aspon zakladne ochrany ako napr CORS v browseri. Ktorykolvek doplnok moze 'uniest' refresh_token a tym padom tvoj account aj ked nema pristup k login/password-u.

Pokial tvoja aplikacia podporuje viacero IdP (Identity Provider) musi si tam zalozit account aby mal ten client_id a client_secret ktorym tam bude pristupovat a ano aj ten by mal byt tajny za beznych okolnosti ale v Thunderbirde bude nahardkodovany takze dalsi dovod preco je prehlaseny za nebezpecny. Normalne ide redirect cez browser takze ten client_id/cli­ent_secret tiez vidis ale naspat ide iba 'code' takze cez tvoj browser access_token nejde. Ak nedoverujes klientskej aplikacii v browseri ze si z code ten token nevypyta mozes pouzit specialny flow 'code flow with pkce'.

No oAuth a OIDC je dost komplikovane ale aspon nejako standardizovane takze sa to da pouzivat cross domain. Odporucam citat zdroje na auth0 ti to maju dobre spracovane a je to napriklad centralizovany IdP co by sa v minulosti nedalo urobit. Ak by si chces nejaky open source IdP odporucam keycloak.

Aha, díky, snad chápu.

A že Google vyžaduje tu registraci aplikace, tak to je z "politických důvodů" aby mohl admin GSuite třeba říct "uživatelům nepovolíme Thunderbird"? Protože „normální IMAP“ přece funguje tak, že uživatel dostane heslo, a jakého mail klienta použije, to už je na něm… (ale jakmile uživateli povolíme jakoukoli desktopovou aplikaci, tak si stejně může použít libovolnou jinou, protože si z té první ukradne buď získané tokeny, nebo rovnou client id pokud je to ten „thunderbirdí“ flow)

> No oAuth a OIDC je dost komplikovane

No a to je právě ten problém, že se jako uživatel bojím že když nerozumím tomu, co který token znamená, který mám chránit a na co vlastně klikám (podpořeno tou UX embedded browseru, který bohužel Thunderbird používá, a vypadá to úplně jak phishing), tak se dostávám do pozice BFU který neví co dělá a bude z toho průšvih. A přitom si myslím že pro naprostou většinu normálních použití by úplně stejně fungovalo „app specific password“, které před rokem zrušili…

Je to podobná situace jako naprosto jasné oprávnění klíčů třeba v SSH nebo keyslotů v LUKSu v linuxovém světě vs. celá ta tragédie kolem pass-the-hash a klíče pro Bitlocker ve Windows světě…

Podobný „dark pattern“ jsem zažil když jsem třeba chtěl otevřít soubor z Google Drive v https://app.diagrams.net/ - zaboha jsem nedokázal rozlišit, jestli tomu dávám přístup jenom k vybranému souboru, nebo k celému drive, a navíc se celá ta interakce odehrává v „iframe“, takže netuším, jestli mi ta aplikace nekreslí divadlo. Upřímně, naprosto to nechápu, jak se počítá, že se v tomhle zorientuje BFU, když já, byť s těmito konkrétními technologiemi nemám zkušenosti, ale jinak si myslím že jsem technicky dost znalý, nedokážu zjistit co se děje? Nebo se spoléhá na to že „google schválil diagrams.net aplikaci a tak nebude evil“?

(no a pak je tu ještě ten problém s funkcionalitou, já naštěstí používám Thunderbird, kde je to nějak, byť tragicky, implementované, ale kdybych používal třeba fetchmail+mutt, tak vyletím z kůže…)

Furt mi přijde divné, že kdyby tohle zavedl ještě Seznam a Centrum a Vodafone a já nevím kdo ještě, tak budou autoři emailových klientů konfigurovat 10000 služeb na světě a registrovat nějaké aplikace, zatímco teď to bylo „zjistěte si od poskytovatele adresu IMAP a SMTP serveru a zadejte to do tohoto políčka“. Nebo se očekává že se „aplikace“ registrovat nebudou a většina to bude mít nějak „otevřené“ a emailovému klientovi se řekne adresa endpointu a on se připojí s nějakým svým client_id a nazdar?

No je to technologia na WEB/browser, akonahle opustite tuto zahradku tak to zacina byt komplikovane. Keby napriklad aplikacia bezala v browseri tak ani nezbadate ze ta aplikacia pristupuje na nejake API googlu vsetko je to single sign on.
Na klasicke IMAP api podla mna nadalej staci username/password. Problem je ze thunderbird (myslim, nepouzivam ho) chce pristupovat aj na ine Google API za ucelom ziskavania dalsich informacii (calendar, ...) takze tam uz potrebuje tie tokeny. A ano teoreticky by stacilo preniest refresh_token do thunderbirdu a mozete fungovat.
Tu je nahlad na tie API:
https://developers.google.com/workspace

Kdyby běžela v prohlížeči, tak buď musím plně důvěřovat poskytovateli služby (který musí řešit úplně ty stejné problémy které jsem popsal - jak to připojit na GMail, MS365, Seznam, … - ne, ve skutečnosti navíc místo IMAPu bude používat nějaké provider-specific API?), nebo si ji provozuju lokálně a pak to řeším taky ;)

> Na klasicke IMAP api podla mna nadalej staci username/password.

Bohužel nestačí, minimálně pro GSuite účty zakázali i app-specific password a enforcují oauth.

Ale já nechci speciální Google API, já chci používat poštovní klient přes POP3/IMAP jako to funguje všude jinde na světě… (a říkám že teď mám štěstí že to za mě naštěstí nějak vyřešili vývojáři Thunderbirdu)

Ak to bezi v browseri celkom tak nemusite pretoze ked sa pouzije ta PKCE extension tak v browseri tokeny nemate, dokonca vdaka PKCE to viete garantovat ze sa tam ani nikdy nedostanu (neviete CODE premenit refresh_token), su tam iba session ID ulozene ako cookie ku ktory sa JS ani nedostane.

Pavel Tavoda
chce pristupovat aj na ine Google API za ucelom ziskavania dalsich informacii (calendar, ...) takze tam uz potrebuje tie tokeny

GMail od 30.5.2022 neumoznuje pouzit name+passwd pro pristup k mailum, resp. ani pro odeslani, pouzivam gmail na notifikace ze serveru a "musel" sem resit prechod na OAuth2:

- zaregistrovat si u nej nejakou vymyslenou aplikaci, abych ziskal client_id a client_secret (povolit ji gmail api, scopes gmail.compose, credential oauth2)

- pro ziskani oath2_token pomoci refresh_tokenu pak pouzit jejich gmail-oauth2-tools/oauth2.py

- protoze nemam workspace musela "app" byt jako externi (ne interni) a v rezimu testing, coz omezuje platnost refresh_token na 7dni

- msmtp pak misto jmeno+heslo autorizovat pres passwordeval volane bash script vyuzivajici ten oauth2.py

- ale pro obnoveni refresh_token po 7dnech musim pustit skript co mi vygeneruje url na kterem musim rucne v web prohlizeci 2x potvrdit ze jde o neoverenou aplikaci, ziskam verification_code, z ktereho skript dale ziska ten refresh_token a zmeni v configu/profilu

to vse "jen" pro "odesli mail z meho gmail uctu pres smtp"

btw: snazil sem se pochopit/probrat, zda mi neco neunika nebo je to opravdu takto "uchylne" a jen na 7dni tu, bez vysledku:
https://www.abclinuxu.cz/poradna/linux/show/479886

Proč by nešlo použít to řešení s impersonací Thunderbirdu? (ale samozřejmě nevím jak ho technicky realizovat a jestli na to už existuje nějaký program, nebo by to bylo potřeba nahackovat)

priznam se ze to sem nezkousel...
ted zkusil, z thunderbird source zjistil jeho hardcodovane client_id a client_secret, to nastavil do meho oauth2 profilu, zkusil s tim ziskat pres url refresh_token (pres oauth2.py, postup jak delam pro ty sve client_*) a zarvalo...

patral sem dal a zjistil ze refresh_token si uklada thunderbird jako heslo k uctu, v Thunderbird/Nas­taveni/Zobrazit­Hesla, radek s Poskytovatel oauth://accou­nts.google.com, zkopiroval ho, pridal do oauth2 profilu a msmtp diky temto 3 udajum si pres ty skripty vytahl oauth2_token s platnosti 60m

takze by to takto asi fungovalo, jen nevim jak dlouho, zahlidl sem info ze long time refresh_token je na 2roky, mozna 200dni, tim ze thunderbird normalne nepouzivam nevim zda se po teto dobe znovu zada pres ten web popup prihlaseni k GMail...

Napadl mě třeba další UX problém:

> Ak nedoverujes klientskej aplikacii v browseri ze si z code ten token nevypyta mozes pouzit specialny flow 'code flow with pkce'.

I pokud jako uživatel vím, že taková věc existuje a že některé flows umožňují takové zneužití a některé ne (na jednu stranu mi tohle přijde jako příšerně složitá problematika na vysvětlení, na druhou stranu můžeme očekávat, že „desktopové aplikace“ v dnešní době používají spíš power-useři), jak poznám, který flow se zrovna teď používá? Maximálně studiem protokolu a zkoumáním fragmentů otevřené URL… Google to tam myslím fakt nikde nepíše…

Ved google to vyriesil za vas, prehlasil ze ta aplikacia je neporiadne zabezpecena ;-).
To za vas v principe riesi ciastocne google zas na druhej strane je zodpovednost aplikacie. V principe nic nebrani zneuzitiu ale zas na druhej strane ak k tomu dojde google dokaze dohladat komu token vydal a pozerat ci sa to deje casto a pripadne taku aplikaciu zakazat.
Pripadne ak odovzdavate tieto tokeny dalej tak si to mozte riadit aj sam cez AUD (audition).
V reale sa IdP obvykle sustreduje na tu cast ktora bezi v browseri respektive na strane klienta. To ze server niekomu praskne vas token sa zabranit neda ale da sa velmi presne zistit komu (ktore aplikacii client_id+aud) bol token vydany.