Názory k článku Device Authorization Grant: přihlášení bez rozumného uživatelského vstupu

Já jsem u OAuth nějak nepochopil tohle: představte si, že dělám „Thunderbird“, a chci, aby ho mohli používat lidi s GMailem, Seznamem, Microsoftem a já nevím čím vším (stejně jako ho doteď mohli používat, když se přihlašovalo heslem, vyplněním POP/IMAP serveru, jména a hesla). Jenže teď potřebuju client_id a případně podle implementace jakousi „aplikaci“ registrovanou u každého z těchto poskytovatelů. Takže se musím: 1) u všech možných poskytovatelů nějak registrovat a celé to adminovat a držet pro ně podporu, 2) když nějakého poskytovatele vynechám, tak si uživatel „Thunderbirdu“ musí projít celým tím neuvěřitelně komplikovaným procesem registrace aplikace a rozdojení celého toho traktoru, což jsem nedal ani já (zkoušel jsem si „zaregistrovat aplikaci“ u Googlu, byla tam na výběr nějaká developer varianta a pak ostrá kde by to někdo nějak schvaloval a celé to mělo strašně dark UX patterny, že třeba nebylo poznat, jestli mě za to bude google cloud nějak účtovat nebo wtf). Celé je to navíc úplné divadlo, protože jakmile svoji aplikaci („Thunderbird“) nabídnu uživatelům ke stažení, client_id (resp. odpovídající secret) si z ní snadno vyextrahují a pak ho může používat kdokoli (e.g. Mutt/Fetchmail).

Chápu původní motivaci, ale proč jsme nemohli mít pro tenhle use-case device-specific resp. app-specific password?

Sekundárně se pak s tím, jak strašně složité to je, pojí to, že jako uživatel detailů protokolu neznalý naprosto netuším, komu k čemu dávám přístup a co s ním může a nemůže dělat. Například když jsem rozcházel google-drive-ocamlfuse (neúspěšně, nepodařilo se mi připojit sdílený firemní disk, jen můj osobní, byť dříve "google-drive-ocamlfuse -label Jméno_disku" fungovalo), tak vyskočí taková stránka že „gdfuse wants to access your Google Account. This will allow to: See, edit, create, and delete all of your Google Drive files. Make sure you trust gdfuse.“ ale nechápu jestli to povoluji desktopové aplikaci, nebo provozovateli toho autentizačního wrapperu (tj. jestli on dostává nějaké secret kterým mě pak může impersonovat) a proč tam vůbec ten wrapper je, když to má fungovat tak, že mě to přesměruje na nějakou URL s uděleným tokenem a ten si přece můžu vykopírovat z adresního řádku prohlížeče a té desktopové aplikaci ho předat ručně.

Terciálně :) je pak naprosto příšerné UX třeba v tom Thunderbirdu, kdy zavedení OAuth u Googlu proběhlo tak, že mi najednou při stahování mailů vyskočilo okno s embedded prohlížečem, u kterého nešlo zjistit URL/stav HTTPS/nic, a chtělo to přihlášení master heslem k mému firemnímu GSuite účtu. Vypadalo to úplně jak nějaký phishing / že někdo našel exploit jak donutit Thunderbird otevřít okno s formulářem a teď loví credentials.

Já jsem po x letech co s OAuth dělám a využíváme ho došel k názoru, že OAuth 2 je dobrý akorát ve webových prohlížečích. Všude jinde je to naprostý pain.

My třeba na začátku projektu potřebovali aby naše aplikace mohla komunikovat s cloudem a využívat OAuth 2. Takže Authorization Code Flow nemůžete použít, když tam není interakce s uživatelem. Takže chcete použít Client Credential. No ale v Keycloak byla chyba, že při několika tisíc klientech přestal být totálně funkční. Tak ok použijeme Resource Owner Password Credentials. Jenže se rozhodli, že ROPC je deprecated v OAuth 2.1 a teď musím každý bezpečnostní audit vysvětlovat, že když je jenom pro komunikaci machine to machine, že to rozhodně není míň nebezpečné než Client Credentials a API keys rozhodně nejsou bezpečnější. Bohužel přechod na Client Credentials je dnes opravdu skoro nemožný a v Keycloak je to trochu špatně použitelné oproti userům.

Další co chcete, tak povolit uživatelům využívat vaše API v jejich skriptech aplikacích a kdo ví v čem. No jo, ale to musí pak s aplikací interagovat člověk, protože musí využít Authorization Code Flow, nebo si musí vytvořit clienta nebo udělat API key. Ale proboha proč? Já chápu, že když budu Google tak nechci aby mi někdo podhodil přihlašovací stránku a zadal tam svoje jméno a heslo.

Suma sumárum nápad, podpora a funkce OAuth2 pěkné, ale pokud chcete poskytovat API i pro něco jiného než webové prohlížeče, tak bych si to příště dvakrát rozmyslel.

Odpoviem aj kolegovi pred vami:
> nechápu jestli to povoluji desktopové aplikaci, nebo provozovateli toho autentizačního wrapperu
Povolujete to tej aplikacii, VY musite vediet co ta aplikacia robi. Ak posiela ziskane tokeny niekam tak tam maju pristup ktory ste pre tu aplikaciu povolili. Preto vas Google vyzyva ci 'doverujete' aplikacii.

> ten si přece můžu vykopírovat z adresního řádku
No pri code flow ano ak viete co a ako ona ho aplikacia moze celkom dost rychlo schovat a ak pouzije rozsirene 'code flow with PKCE' ktore sa pouziva prave v pripade ze nedoverujete prostrednikovi tak tam si nemate co vykopirovat

> využívat vaše API v jejich skriptech
Na to sluzi 'Client Credentials Grant Flow' a vygenerovanie robime v aplikacii ktora registruje klientov pre API. Proste vyuzijeme keycloak API a vygenerujeme client z nasej aplikacie cez keycloak API.

> Povolujete to tej aplikacii, VY musite vediet co ta aplikacia robi. Ak posiela ziskane tokeny niekam tak tam maju pristup ktory ste pre tu aplikaciu povolili. Preto vas Google vyzyva ci 'doverujete' aplikacii.

OK a jak se to má používat, když věřím aplikaci ve smyslu toho programu co spouštím na počítači (ve smyslu že v podstatě všichni musíme věřit, že přes code review, release a následně do balíčků v distribucích neprošel backdoor), ale ne online službě co autoři programu provozují? (což minimálně přidává attack vector, a taky mi přijde jednodušší, aby to tam nějaký admin odposlouchával, než že by takový jednotlivec dokázal nacpat backdoor přímo do „Thunderbirdu“, udělat release a nepřišlo by se na to)

To PKCE?

Jak zjistím jestli se v daném případě používá? Měl by mi to říct ten Google, ale neříká (a navíc musíš všechny lidi poučit jak to teda funguje a na co si dát pozor -- zatímco teď jsme rádi, že jsme BFU naučili alespoň trochu základům bezpečnosti, a najednou tu máme takovouhle věc co málem vyžaduje doktorát) a pak viz ta UX disaster s embedded prohlížečem :/.

Celkově je to možná hezká technologie, ale přijde mi úplně nezvladatelně komplikovaná (což u bezpečnosti není dobré, naopak chceš všechno co nejzjevnější) a současné implementace zoufalé.

20. 4. 2023, 18:26 editováno autorem komentáře

1) Ked tej sluzbe neverite tak ju nepouzivajte. Minimalne sa asi chysta spracovavat nejako vase udaje. K inym ako deklarovanym udajom sa nedostane aj ked by mali vas token. Takze ak deklaruju ze idu k dokumentom k mailom pristup nemaju.

2) PKCE sa da zistit s obsahu requestu ale to vy nemusite. To si riesi prislusna sluzba ci doveruje danej aplikacii.

3) UX disaster je problem Thunderbirdu nie IdP (Google, Facebook, ...)

Na to sluzi 'Client Credentials Grant Flow' a vygenerovanie robime v aplikacii ktora registruje klientov pre API. Proste vyuzijeme keycloak API a vygenerujeme client z nasej aplikacie cez keycloak API.
Já to chápu, ale proč by nešlo pro uživatele použít ty samé credentials co používají a musí se vytvořit další client. A zrovna Keycloak není na clienty moc dobře připravený (mimochodem ve skutečnosti se v Keycloak vytvoří user pod clientem). Chápu, že s Resource Owner Password Credentials lze podvrhnout stránku na přihlášení a tak získat token, ale jak tohle zlepší když se využije Client Credentials? Odpovím vůbec nijak, protože pro něj můžete využít úplně stejný útok jako pro ROPC. OAuth2 je celkem komplikovaný a díky tomu jsou pak uživatelé celkem zmatení, pak jim ještě řeknete, že mají používat místo jedněch credentials dvoje.
Je mi jasné proč tohle dělat u Google atp. služeb, ale pokud ten authorization server provozuji a využívá se jenom pro jeden systém, tak nevidím jediný důvod, proč by to nemělo jít. Smůla je, že moc jiných alternativ jak řešit zabezpečení API není.

Tak pokial si ho bezite sam a viete ze autorizaciu mate nastavenu na login/password tak mozete pouzit aj simulovany form submit na prihlasenie. Nemusite pouzivat clientId/clien­tSecret.

To jste OAuth skutečně nepochopil :-) OAuth není univerzální prostředek pro přihlašování. OAuth je prostředek, jak může jedna aplikace (třeba GMail) dát přístup konkrétní jiné aplikaci ke zdrojům, které spravuje. Je to tedy záměr, že aplikace poskytující přístup musí o aplikaci, která žádá o přístup, předem vědět.

To, co byste chtěl, je OpenID Connect. To je nadstavba nad OAuth a řeší právě to univerzální přihlašování. Tedy aplikace vlastnící zdroje nemusí o aplikaci žádající přístup předem nic vědět, aplikace se „seznámí“ teprve v okamžiku, kdy uživatel chce poskytnout přístup.

No jo, jenže proč vlastně? Co je "aplikaci poskytující přístup" do toho, jaká aplikace k ní přistupuje? Aplikace přece (zatím) není něco živého s vlastním rozumem, o datech by měl rozhodovat výhradně uživatel. A pokud si já jakožto uživatel chci ke GMailu připojit jakéhokoli myslitelného klienta, včetně toho, kterého jsem si včera večer ubastlil, co mi má Google do toho co kecat? Proč je třeba každého klienta třeba napřed nechat prolustrovat poskytovatelem služby místo toho, aby se rozhodování nechalo na uživateli?

Pokial viem Google vasu aplikaciu nelustruje iba pozaduje zriadenie prislusneho clientId aby sa prihlasovacie tokeny dali jednoznacne identifikovat a nedali sa zneuzit inym klientom. Sluzi to v podstate na vasu ochranu a ochranu vasej aplikacie.

Aplikace je desktopový program co se distribuuje uživatelům, takže jakmile má tento program nějaký secret, tak je veřejný jakmile si to stáhne první uživatel a podívá se dovnitř.

Možná je to fakt jenom blbou současnou implementací, ale tak jak je to teď je to prostě tragédie.

To je ovšem velmi naivní přístup, který předpokládá, že uživatel je vševědoucí.

Když si chcete jakéhokoli myslitelného klienta připojit ke GMailu, ani vás zjevně při psaní komentáře nenapadlo, že stejné přihlašovací údaje, jaké máte pro GMail, máte i pro všechny ostatní služby Googlu. A co teprve uživatelé, kteří o nějakých aplikacích a autorizaci nevědí vůbec nic. Takže Google logicky chce poskytnout uživatelům dobré služby, takže jim například při přihlašování umožnit určit, k čemu aplikaci přístup dají (k e-mailů) a k čemu ne (ke všemu ostatnímu) – k tomu slouží OAuth. No a také je dobré vědět, komu ten přístup uživatel vlastně uděluje – a k tomu je potřeba tu aplikaci registrovat. Mimo jiné to slouží i k dalšímu zabezpečení, protože kdyby ta aplikace zacházela se získanými přístupovými údaji lehkovážně, není jednoduché je vzít a použít je v jiné aplikaci.

> ani vás zjevně při psaní komentáře nenapadlo, že stejné přihlašovací údaje, jaké máte pro GMail, máte i pro všechny ostatní služby Googlu

To dříve řešili pomocí speciálního hesla k imapu, které bylo jiné, než heslo ke google účtu.

> No a také je dobré vědět, komu ten přístup uživatel vlastně uděluje – a k tomu je potřeba tu aplikaci registrovat. [...] kdyby ta aplikace zacházela se získanými přístupovými údaji lehkovážně, není jednoduché je vzít a použít je v jiné aplikaci

Je, stačí vykopírovat client_id a client_secret z Thunderbirdu a použít.

A ještě navíc je tam ta wtf online část (což by asi mělo řešit to PKCE které nikdo nepodporuje).

> No a také je dobré vědět, komu ten přístup uživatel vlastně uděluje – a k tomu je potřeba tu aplikaci registrovat.

Takže opravdu správné řešení je, že se tvůrci Thunderbirdu/Mut­tu/Fetchmailu/i­mapsyncu/... budou registrovat u milionu poskytovatelů emailových služeb?

Resp. myslím, že tady došlo ke zmatení pojmů: první tři komentáře hovořili o aplikaci ve smyslu softwaru, který uživatel provozuje („Thunderbird“), zatímco tento váš komentář hovoří o způsobu přihlašování vhodném pro aplikace ve smyslu služby třetích stran / SaaSS, ne? O aplikacích v tom prvním smyslu jste už hovořil („To, co byste chtěl, je OpenID Connect.“ - ale neznám detaily jestli to jde normálně používat pro ten „Thunderbird“ use-case).

No dobře, takže problém je, že se tlačí špatně nastavený do věcí, pro které nebyl určen? (aktuálně je to myslím např. jediný způsob jak si připojit GSuite GMail do normálního mailového klienta, u MS365 pokud vím podobně)

Mimochodem když už jsme u toho, jak si lidi připojujou sdílené Google disky na Linuxu? Nebo jsem jenom lama že to google-drive-ocamlfuse neumím nastavit a ukazuje mi to jenom můj disk a ne ty sdílené firemní?

A tie zdielane disky mate zdielane do svojho profilu alebo firemneho? Prihlasujete sa firemnym uctom?

Firemního a ano. I s -label <jméno co vidím na drive.google.com v podsložce Shared drives> tam vidím jen obsah "My Drive" (firemní) a v adresáři .shared je nějaké wtf, většinou .desktop soubory i úplně cizích dokumentů co jsem kdy navštívil.

My řešíme podobný problém, že máme zařízení a to dáváme zákazníkům a aby bylo prostě plug and play. Nakonec jdeme cestou, že pro zabezpečení využíváme TPM čip v zařízení. V podstatě zaregistrujeme public klíč z TPM u nás v systému a zařízení se po zapojení do sítě automaticky dokáže přihlásit do našeho systému. Uživatel si ho může pak v portálu přiřadit kam potřebuje. Je to v podstatě to samé jako kdybyste do zařízení nahráli privátní klíč jenom s tím rozdílem, že ten klíč z TPM by nemělo jít jak dostat ven.

Takze pokud tomu spravne rozumim, vy vite, ktere zarizeni komu prodavate, takze ho muzete tomu zakaznikovi priradit jeste predtim, nez mu ho odeslete? A riziko, ze by se k zarizeni nekdo dostal cestou, treba na poste, povazujete za zanedbatelne?

Protoze tyhle problemy muze spravne implementovany Device Auth. Grant resit:
1. Zakaznik prokazuje svoji identitu a opravneni zaregistrovat zarizeni zalogovanim se do naseho online systemu
2. Zakaznik muze zaregistrovat pouze zarizeni, na ktere vidi - user code je nahodny a meni se co par vterin. Nelze prebrat zarizeni, ktere je treba teprv na ceste (potencionalne k jinemu zakaznikovi :D)
3. Behem registrace muzeme pozadovat EULu. Zakaznik potvrzuje, ze od teto chvile prebira za zarizeni odpovednost a pokud si ho necha ukrast, pripadny unik firemnich dat jde na jeho triko.
4. Nemusime predem vedet, ktery zakaznik zaregistruje ktere zarizeni. Takze je muzeme mit naskladnene zabalene, muzeme je ruzne preprodavat pres prostredniky a pod.

Podotykam, ze mluvim o Device Auth. Grantu jako protokolu, ne konkretni implementaci.

Ne žádné riziko tam není, protože zákazník musi zařízení někam přiřadit. Takže i kdyby se ztratilo cestou tak jediné co může útočník udělat je, že se zařízení přihlásí k nám a v tu chvíli ho my můžeme na dálku zablokovat. Bez přiřazení ho nemůže nijak využít vlastně je připojený a poslouchá příkazy.