Názory k článku Přihlášení pomocí třetí strany: ověření identity s OAuth 2.0

Tak super a jak může babička hlídat co o ní myslivcová karkulce vykecá? Třeba chce aby karkulce řekla že je babička, pro sněhurku se identifikovala jako tetička a pro vlka náhodně vybrala každý den jiného trpaslíka? V jednom obchodě nakupuju jako fyzická osoba v druhém jako právnická a třetí je stránka kde se vlastně přihlašovat nechci ani nepotřebuju, jenom je to vyžadováno.

To je velmi dobrá otázka.

Babička nedokáže hlídat nic. Právě proto se jedná o otázku důvěry: Babička důvěřuje Myslivcové, že tato předá třetí straně jen ty informace, se kterými Babička souhlasí (a před jejich předáním je na webu Myslivcové typicky s touto situací seznámena). I proto existují nařízení typu GDPR, která tento vztah alespoň částečně formalizují.

No právě a Myslivcová je známá drbna a co neví to nepoví. Se souhlasem je to jako všude, všechno nebo nic. Jo takhle kdyby se Autorita umožňovala uživatelům spravovat co kam poslat a neposlat to by byla jiná.

MojeID to umožňuje: zvolíte si, co všechno tomu serveru, pro který se provádí ověření, může předat.

Uživatel nemůže mít žádný mechanismus, kterým by povahu předávaných údajů mohl technologicky omezovat a/nebo kontrolovat, neboť předávaná data tečou kanálem, který nemá pod kontrolou.

Pokud uživatel poskytovateli identity nevěří, pak by asi neměl využívat jeho služeb.

Dobrý poskytovatel identity by měl také nabídnout možnost revokovat vydaný OAuth token, aby mohl uživatel svůj souhlas s předáním identifikačních dat odvolat, pokud bude mít takovou potřebu.

Preco je pouzity iba standard OAuth a nie uz Open ID Connect (ktory je postaveny nad OAuth)? Tiez si neviem predstavit ako je mozne implementovat prihlasenie so Seznamem u verejnych klientov (SPA, mobilne aplikacie), ktore nemozu z principu udrzat client secret utajeny. T. j. sirsia podpora roznych flows pre rozne pripady by sa tiez hodila. V zasade je chvalihodne, ze Seznam nieco take poskytuje. Asi by to vsak chcelo este o kusok pokrocilejsie standardy.

Tiez, by som si prial aby som sa k samotnemu Seznamu vedel prihlasit cez inych IDP poskytovatelov (Google v mojom pripade, mojeID v pripade ceskych pouzivatelov a pod.)

viz https://www.root.cz/zpravicky/seznam-cz-email-konci-s-podporou-openid/

Dívám se, že do https://vyvojari.seznam.cz/ se lze přihlásit i účtem s mailem na vlastní doméně, který mám na seznam profi email.

To je docela příjemné.

Jak by bylo dobré řešit situaci, kdy:

- chci aby nový uživate našeho spolkového webu se zaregistroval
- dostal emailovou adresu na naší doméně
- vytvořila se mu schránka na seznamu profi email
a tímto účtem by se pak přihlašoval na náš web.

díky

> - chci aby nový uživate našeho spolkového webu se zaregistroval
> - dostal emailovou adresu na naší doméně

Pokud se jedná o doménu spravovanou v rámci Email Profi, pak takovou schránku smí založit jen správce domény. Uživatel sám si ji založit / registrovat nemůže.

> - vytvořila se mu schránka na seznamu profi email

To se stane automaticky, jakmile mu správce domény v Email Profi vytvoří e-mailovou adresu v předchozím bodě.

> tímto účtem by se pak přihlašoval na náš web.

Zde lze použít Přihlášení přes Seznam, ale v rámci toho se pak stane, že na web přijde přihlášený uživatel Seznamu s nějakým úplně nesouvisejícím účtem (example@seznam­.cz). Takže na webu bude nutné kontrolovat doménu přihlášeného uživatele (část za zavináčem) a pokud bude jiná, než ta vaše spolková, tak mu situaci vysvětlit a poslat jej pryč.

moment. Já jsem se přihlásil na vyvojari.seznam.cz přes seznam.

Mohl jsem tak učinit přes svůj účet na @seznam.cz (který mám asi sto let už) a nebo i přes některý z účtů na vlastní doméně, které si spravuji přes email profi.

Zkusil jsem to druhé, což jsem myslel že nebude fungovat.

Platí tedy, že účet na doméně @seznam.cz a na @mojedomana.xx jsou si rovny s tím rozdílem, že nad těmi účty @mojedomana.xx má kontrolu správce domény (v tomto případě já se svým @seznam.cz účtem) přes rozhraní email profi?

Vnímal jsem to tak, že emailprofi mi vlastně umožní něco podobného jako správa mailů na webhostingu. S tím, že místo třeba roundcube dostanu standartní rozhraní seznam mailu a pak mám samozřejmě přístup přes IMAP a SMTP protokoly podbně jako na běžném hostingu.

Ale já tímto způsobem získám identitu, která jde napříč službami seznamu, že?

6. 5. 2021, 10:36 editováno autorem komentáře

> Platí tedy, že účet na doméně @seznam.cz a na @mojedomana.xx jsou si rovny s tím rozdílem, že nad těmi účty @mojedomana.xx má kontrolu správce domény (v tomto případě já se svým @seznam.cz účtem) přes rozhraní email profi?

Ano, presne tak. Ziskane e-mailove adresy @mojedomena.xx jsou fakticky uzivatelske ucty, ktere funguji napric vsemi sluzbami Seznamu, vcetne Prihlaseni ke tretim stranam.

díky.

A ještě prosím, chystá se nějaké API k email profi? Našel jsem jen diskusi na

https://napoveda.seznam.cz/forum/threads/77930/1

kde naposledy paní Ivana 25. ledna slibuje, že to předá kolegům jako námět.

Jen se ptám, dík.

Prosím, komunikácia je vždy na https (443)? Alebo je bežnou praxou používať aj iné porty kvôli mixu Oauth appiek (Tomcat, nginx, iis...)?
Ide mi len o FW rules kvôli rozbehnutiu OAuthu vnútropodnikovo.

Ano, je to všechno HTTPS.

Pak by teda mohly nastat tyto situace při přihlášení k mému webu přes seznam oauth:

- uživatel má mail (účet) u seznamu) a přihlásí se pomocí něj
- uživatel má účet u seznamu zřízený přes emailprofi správcem naší domény

- uživatel nemá účet u seznamu a aby se mohl přihlásit, vytvoří si sám mail u seznamu

- uživatel nemá účet u seznamu a zřídí mu ho náš správce domény na naší doméně

A nebo se samozřejmě přihlásí jiným způsobem, který by náš web podporoval. Ale to neřeším.

Všechny OAuth přihlášení jsou skvělé, dokud je uživatele zvládnou používat. Problém je, že ne každý má nebo chce použít nabízené třetí strany. Takže používáme přihlášení e-mailem. Na email zašleme kód a dotyčný ho opíše do formuláře. A je to (nebo SMS)

To je "dobré" zabezpečení, ideální pro "one-time" přihlášení: založit e-mail, počkat na kód, přepsat kód, projít webem, zapomenout/zahodit.
Pro nás, roboty, je navíc pohodlné mít na doméně e-mailový koš, kde si posbíráme a odklikáme kody z každého mailu, který tam dorazí.

Nejlepší zabezpečení proti robotům je captcha ne? Považovat mail za zabezpečení bych si netroufnul.

Záleží samozřejmě co chcete. Jestli chcete autorizovat existující uživatele, které znáte, nebo uživatele které neznáte, kterým pro jejich pohodlí chcete jen vytvořit profil, ale není to něco, co by bylo mandatorní pro funkci vašeho byznysu (tedy do té doby, než váš byznys je založen na spamování těch lidí)

Omlouvám se za tu ironii.Máte pravdu, že CAPTCHA je proti robotům dobrá - alespoň mne vyřadí skoro stoprocentně. ;oD
Chtěl jsem jen poukázat na to, že používání této "přímé e-mailové cesty" není právě ideální systém. Pro zákazníka je to vcelku pohodlné (mnohem lepší než SMS, kterou nedostanete rozumně do clipboardu), ale provozovatel nemá žádnou jistotu - snad jen tu, že na druhé straně je někdo, kdo se dostane k tomu e-mailu, ale to vůbec nemusí být stejná osoba, která to byla posledně. Což neznamená, že nemůže existovat služba, kde to stačí.

Úplně nechápu tu úsporu pro provozovatele v tom, že by nemuseli vést databázi uživatelů. Pokud to přihlášení chtějí k něčemu použít, tak stejně musí mít databázi uživatelů s nějakými jejich nastaveními, daty apod. Takže jediné, co si ušetří je ten vlastní akt přihlášení, resp. ještě registrace.

Z pohledu uživatele je to pak jasné, kupuje si svoje pohodlíčko za cenu prozrazení něčeho ze svého soukromí.

NechcI být rejpal, ale vlastní databázi uživatelů potřebuji snad i tehdy, pokud uživatele ověřuji přes externí službu, pochybuji že mi bude seznam ukládat kdejaké informace, které si usmyslím, ze chci vědět o uživateli. Já takové přihlašování vnímám jako volitelné a život ulehčující, ale rozhodně ne jako jedinou možnost

Jistě, ale otázka je, co taková databáze musí obsahovat. Pokud člověk řeší přihlášení svépomocí, musí evidovat přihlašovací údaje (hash hesla, ...), doplňkové údaje pro jeho obnovu (e-mail a míru jeho ověřenosti, telefonní číslo a míru jeho ověřenosti), případně cokoliv by souviselo s vícefaktorovým ověřením...

Sohlasím, věcí na řešení je opravdu mnoho. Jak u přihlašování třetí stranou potom rozjedu např. něco jako přihlašování přes terminál, nejsem si jisty konkrétním prikladem, ale myslím ze nějaký Git s tím mel problem, pokud jsem se zaregistroval takhle a nevytvořil si lokální heslo u dané služby, prostě to nejelo

Ten priklad je strasne necitatelny kvoli pouzitym menam.
To neslo pouzit nieco zrozumitelnejsie?

Myslím, že takových příkladů se online válí stovky, třeba v rámci RFC na OAuth. Pokud je ten z článku nečitelný, nebude problém najít nějaký zřetelnější.

Je až ironické, že na ROOTu vyjde takový článek, ale možnost přihlášení se tímto způsobem na https://www.root.cz/prihlasit/ stále není :-)