Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: malachovicky.jan 20. 06. 2022, 12:03:28
-
Ahojte, zacali sme pracovat na refaktore appky ktora je momentalne jeden velky spring bootovy monolit v jave. Povodny core planujeme nechat, a popri nom budovat nove mikrosluzby a postupne urezavat z monolitu logiku ktora by bola vhodna na to aby z nej bola mikrosluzba.
Autentifikacia a autorizacia bude riesena jwt tokenmi. Tu sa ale dostavame do oblasti ktoru velmi nepoznam, a ani nikto z kolegov, dostal som za ulohu pripravit nejaky proof of concept, ktory to riesil. Narazil som na 2 otazky na ktore neviem odpoved, a akekolvek dalsie nasmerovanie uvitam.
1. Kedze klient pozaduje autentifikaciu pomocou google uctu (neskor mozno pribudne facebook alebo twitter), mame autentifikaciu a autorizaciu a tiez refresh tokenu riesit vyhradne len s google? Ak sa koncovy pouzivatel prihlasi cez nasu appku, tak ziskame access a refresh token, ktore posunieme potom koncovemu pouzivatelovi. On pomocou nich bude pristupovat k nasej appke, a kazdym requestom si ich nejak overime proti google?
Alebo autentifikaciu koncoveho pouzivaela v google pouzijeme len na to, aby sme ziskli informaciu o tom "kto to je", jeho meno, email, a sparovali si toho cloveka s uctom v nasom systeme, a nasledne aj cela orchestracia s tokenmi by bola na nas mimo google?
2. Ako som spominal, k nasemu monolitu budu pribudat dalsie mikrosluzby, a verim ze nastane situacia, kedy budeme potrebovat riesit security pri volaniach medzi mikrosluzbami, alebo z monolitu na mikrosluzbu. Z toho co som nasiel s na to pouziva grant client_credentials. Je aj na toto ok pouzit google oauth, alebo by ste na to sli inac?
Budem naozaj vdacny za akekolvek rady, aj mimo mojich otazok, pripadne nieco z vlastnej skusenosti ako ste nieco podobne riesili. Dakujem.
-
https://developers.google.com/identity/sign-in/web/sign-in
-
https://developers.google.com/identity/sign-in/web/sign-in
To som uz pozeral, aj nejak to rozchodil v tom svojom POC, teraz neviem ako s tym tokenom dalej nalozit.
-
U nás to řešímě přesně jak si to popsal zde:
Alebo autentifikaciu koncoveho pouzivaela v google pouzijeme len na to, aby sme ziskli informaciu o tom "kto to je", jeho meno, email, a sparovali si toho cloveka s uctom v nasom systeme, a nasledne aj cela orchestracia s tokenmi by bola na nas mimo google
Jen ten email není nejlepší volba, existuje tam přímo id uživatele to svazujeme s účtem u nás, tímto způsobem u nás může mít účet i někdo kdo se chce přihlašovat přes login a heslo a zároveň je možnost přihlásit se přes google a další.
Na základě autentizace vygenerujeme jwt token tím se pak autentizuje client dál, platnost jwt tokenu máme 14 dní. U jwt tokenu doporučuji vynutit při ověření hash funkci, určitě nepoužívat autodetekci.
-
U nás to řešímě přesně jak si to popsal zde:
Alebo autentifikaciu koncoveho pouzivaela v google pouzijeme len na to, aby sme ziskli informaciu o tom "kto to je", jeho meno, email, a sparovali si toho cloveka s uctom v nasom systeme, a nasledne aj cela orchestracia s tokenmi by bola na nas mimo google
Jen ten email není nejlepší volba, existuje tam přímo id uživatele to svazujeme s účtem u nás, tímto způsobem u nás může mít účet i někdo kdo se chce přihlašovat přes login a heslo a zároveň je možnost přihlásit se přes google a další.
Na základě autentizace vygenerujeme jwt token tím se pak autentizuje client dál, platnost jwt tokenu máme 14 dní. U jwt tokenu doporučuji vynutit při ověření hash funkci, určitě nepoužívat autodetekci.
Dakujem, tiez sa mi tato moznost viac pozdava, problem moze byt mozno len to, ze google a asi aj iny provideri eviduju , ake aplikacie tretich stran overuju cloveka oproti tomu uctu, a ak by pouzivatel zistil, ze jeho jwt token niekto ziskal a chce vynutit odhlasenie, tak zakazanie pristupu v google, alebo inom provideri mu nepomoze, a budeme musiet aj toto posefovat u nas, ze?
-
JWT neověřujete s každým požadavkem ověřovat u toho, kdo jej vydal. Právě naopak – JWT je elektronicky podepsaný, takže jenom ověříte podpis a na jeho základě víte, že ho opravdu vydal ten, kdo měl (ve vašem případě Google). Proto se také používá refresh token – vy ověřujete access token sám, bez Googlu, a tím pádem se nedozvíte, když se uživatel třeba odhlásil. Proto access token neplatí moc dlouho, a máte ještě refresh token, na jehož základě získáváte nový access token. Pro tu obnovu už musíte kontaktovat Google, a to je ta chvíle, kdy vám Google může odmítnout vydat access token (třeba protože už se uživatel odhlásil).
Jinak se používají obě vaše varianty. To přímé použití JWT vydaného Googlem je jednodušší na první implementaci (nemusíte řešit vydávání vlastních tokenů). Naopak při použití vlastních tokenů máte vše v ruce – můžete sjednotit data v tokenu napříč poskytovateli (tj. když přidáte Facebook a Twitter, pro koncovou aplikaci se nic nezmění), můžete si do tokenu přidat další informace, které potřebujete, třeba role, do kterých uživatel patří.
-
Jeste je mozny pouzit neco jako Keycloak v roli identity broker a to vam muze schovat detaily o tom, zda uzivatel pouziva FB nebo Google.
-
JWT neověřujete s každým požadavkem ověřovat u toho, kdo jej vydal. Právě naopak – JWT je elektronicky podepsaný, takže jenom ověříte podpis a na jeho základě víte, že ho opravdu vydal ten, kdo měl (ve vašem případě Google). Proto se také používá refresh token – vy ověřujete access token sám, bez Googlu, a tím pádem se nedozvíte, když se uživatel třeba odhlásil. Proto access token neplatí moc dlouho, a máte ještě refresh token, na jehož základě získáváte nový access token. Pro tu obnovu už musíte kontaktovat Google, a to je ta chvíle, kdy vám Google může odmítnout vydat access token (třeba protože už se uživatel odhlásil).
Jinak se používají obě vaše varianty. To přímé použití JWT vydaného Googlem je jednodušší na první implementaci (nemusíte řešit vydávání vlastních tokenů). Naopak při použití vlastních tokenů máte vše v ruce – můžete sjednotit data v tokenu napříč poskytovateli (tj. když přidáte Facebook a Twitter, pro koncovou aplikaci se nic nezmění), můžete si do tokenu přidat další informace, které potřebujete, třeba role, do kterých uživatel patří.
Chapem, a ako vyriesit teda scenar, ak pouzivatel chce niektore zariadenie odrezat od pristupu? Je v poriadku kombinacia JWT a session? Session pre uvedeny scenar, a jwt pre autorizaciu medzi servisami na backende.
-
Session je nesmysl, to nechcete – s mikroslužbami to nejde dohromady. Potřebuje uživatel odříznout zařízení od přístupu okamžitě? Pokud ne, pak JWT s refresh tokenem stačí.
Pokud je teď vyžadováno jen přihlášení přes Google, začal bych tou první variantou (budete používat přímo JWT od Googlu). Pokud budete potřebovat později silnější nástroj, doimplementujete si autorizační server. Nebo použijete Keycloak, pokud mermomocí budete potřebovat něco hodně velkého.
-
Session je nesmysl, to nechcete – s mikroslužbami to nejde dohromady. Potřebuje uživatel odříznout zařízení od přístupu okamžitě? Pokud ne, pak JWT s refresh tokenem stačí.
V appke sa pracuje aj s financnymi prostriedkami klienta, takze ano
-
Session je nesmysl, to nechcete – s mikroslužbami to nejde dohromady. Potřebuje uživatel odříznout zařízení od přístupu okamžitě? Pokud ne, pak JWT s refresh tokenem stačí.
V appke sa pracuje aj s financnymi prostriedkami klienta, takze ano
Tak je JWT potom nesprávne riešenie. Token platí až do svojej expirácie, klient sa odreže tým, že sa mu nepodpíše nový token. Pokiaľ sa to nedá dosiahnuť vhodným intervalom obnovy tokenu, treba použiť niečo iné.
-
Session je nesmysl, to nechcete – s mikroslužbami to nejde dohromady. Potřebuje uživatel odříznout zařízení od přístupu okamžitě? Pokud ne, pak JWT s refresh tokenem stačí.
V appke sa pracuje aj s financnymi prostriedkami klienta, takze ano
Tak je JWT potom nesprávne riešenie. Token platí až do svojej expirácie, klient sa odreže tým, že sa mu nepodpíše nový token. Pokiaľ sa to nedá dosiahnuť vhodným intervalom obnovy tokenu, treba použiť niečo iné.
Z toho co som studoval zatial na forach a blogoch, tak autentifikacia cez jwt token bolo najviac odporucane riesenie pre microservice architekturu. Co sa tyka toho okamziteho odhlasenia, myslel som ze by to mohlo ist vyriesit black listom tokenov, napr. v redise. Samozrejme ak ma ktokolvek lepsi napad, ale skusenosti s podobnym problemom som otvoreny navrhom, s refaktorom este len zaciname.
-
Je to doporucovane reseni prave kvuli tomu, ze ta service nemusi vedet vubec nic o IDP, ktery ji poskytlo informace o uzivateli. Ten vas Redis tohle porusuje.
-
Ano, JWT jsou doporučené řešení pro mikroservisy, protože mikroservisy jsou bezestavové, což právě JWT umožňují (na rozdíl od session). Otázka je, co se s těmi finančními prostředky dělá, že chcete okamžité odhlášení. Pokud je to důležité, měl by to naopak uživatel extra potvrdit. Zároveň chcete mít přihlašování přes Google, takže i když se uživatel okamžitě odhlásí z vaší aplikace, případný útočník se stejně může znovu přihlásit přes Google.
V tom vašem případě by bylo možné při tom provádění operace s finančními prostředky ověřovat, že token není na blacklistu, a tím zařídit to okamžité odhlášení alespoň v kritických případech. Ale spíš mi připadá, že je potřeba ještě definovat, jaké požadavky na bezpečnost vlastně máte. Protože jak jsem psal výše, nedává mi to dohromady smysl (což neznamená, že to smysl nemá – víme od vás jen útržky).
-
Ano, JWT jsou doporučené řešení pro mikroservisy, protože mikroservisy jsou bezestavové, což právě JWT umožňují (na rozdíl od session). Otázka je, co se s těmi finančními prostředky dělá, že chcete okamžité odhlášení. Pokud je to důležité, měl by to naopak uživatel extra potvrdit. Zároveň chcete mít přihlašování přes Google, takže i když se uživatel okamžitě odhlásí z vaší aplikace, případný útočník se stejně může znovu přihlásit přes Google.
V tom vašem případě by bylo možné při tom provádění operace s finančními prostředky ověřovat, že token není na blacklistu, a tím zařídit to okamžité odhlášení alespoň v kritických případech. Ale spíš mi připadá, že je potřeba ještě definovat, jaké požadavky na bezpečnost vlastně máte. Protože jak jsem psal výše, nedává mi to dohromady smysl (což neznamená, že to smysl nemá – víme od vás jen útržky).
Taky je dulezite mit na pameti, ze v pripade microservice architektury bezi business logika aplikace v Javascriptu Browseru a tudiz je pristupna pro manipulaci.
Microservice architektura dava smysl hlavne, pokud potrebuju obsouzit radove miliony uzivatelu, pro pouziti v mensim rozsahu to oproti Spring Boot monolitu prinese leda DevOps opruz, slozity debugging a hromadu potencialnich bezpecnostnich problemu.
Osobne bych se silne branil migrovat web, na kterem tecou prachy, do stateless microservice formatu se session a business logikou drzenou v browseru ve volne citelne skriptovacim jazyce.
Pokud je duvodem zvyseni vykonu, asi bych premyslel o spis o horizontalnim skalovani vice Springu pres F5/nginx load balancer se session afinity.
-
Taky je dulezite mit na pameti, ze v pripade microservice architektury bezi business logika aplikace v Javascriptu Browseru a tudiz je pristupna pro manipulaci.
Ne, v případě microservice architektury běží byznys logika aplikace v těch microservisách na serveru.
Microservice architektura dava smysl hlavne, pokud potrebuju obsouzit radove miliony uzivatelu, pro pouziti v mensim
rozsahu to oproti Spring Boot monolitu prinese leda DevOps opruz, slozity debugging a hromadu potencialnich bezpecnostnich problemu.
Microservice architektura dává smysl také tehdy, když chcete službu provozovat bez výpadků. Nebo když ji chcete snadno škálovat (to nemusí být jen miliony uživatelů, zdroje můžete ušetřit i tehdy, když máte špičku s desetitisíci uživatelů dva dny v měsíci). Nebo když chcete mít jednotlivé části oddělené z hlediska vývoje, aby bylo možné je nezávisle na sobě vyměnit.
Microservice architektura je dost široký pojem, ony ty služby nemusí být zas až tak „micro“. Nějakou komplexitu to přináší, ale ve výsledku je jednodušší udržet dlouhodobě použitelnou microservice architekturu. Platí, že když někdo neumí udělat dobře monolit, nebude umět udělat dobře ani microservisy. Ale microservisy vyvíjejí větší tlak na tu správnou architekturu.
do stateless microservice formatu se session
To je nonsense. Session drží stav, nemůžete mít bezestavovou architekturu se stavem.
-
Pokud potrebujete uzivatele odhlasit a zaroven chcete pouzit oidc/jwt authorizaci resi se to to scenarem v jednomz prvnich prispevku: Backend ziska tokeny a vygeneruje session s expiraci stejnou jako ma access token a ty posle fe(uzivateli). Pokud uzivatele potrebujete okamzite odhlasit, znevalidujete jeho session v aplikaci a tokeny v idp (tedy autentizace pres refresh selze) a vynutite jeji opetovne prihlaseni. Jak to udelat primo skrz google/fb apod netusim, ncimene treba konkretne keycloak ktery umi idp brokering pro zminene providery to umi: odhlasite session a tim padem se pres refresh uz neprihlasite. Zaroven tez muzete uzivatele uplne zablokovat. Pozor v tomto pripade musite take nejak zajistit samotnou refresh fazi s idp po te co expiruje access_token a to nejlip nejak transparentne (tedy beze zmeny user session). Vyhoda takove postupu je ze fe/uzivatel nema vybec sajnu o nejakych tokenech a tudiz vubec nevi jake interni prava ma. Nevyhodou je komplexita se kterou se ale da hrat. Session overovani Vsm muze delat treba nejaka proxy/apigw a na be budou chodit jen claimy z tokenu (ulozene interne nebo v nejake key/val) takze i kdyz vyvojari be nechtej zabrednout do bazin oidc, lze to nechat na nejakem lepsim ifrastrukturnim prvku co to umi :)
-
Ano, JWT jsou doporučené řešení pro mikroservisy, protože mikroservisy jsou bezestavové, což právě JWT umožňují (na rozdíl od session). Otázka je, co se s těmi finančními prostředky dělá, že chcete okamžité odhlášení. Pokud je to důležité, měl by to naopak uživatel extra potvrdit. Zároveň chcete mít přihlašování přes Google, takže i když se uživatel okamžitě odhlásí z vaší aplikace, případný útočník se stejně může znovu přihlásit přes Google.
V tom vašem případě by bylo možné při tom provádění operace s finančními prostředky ověřovat, že token není na blacklistu, a tím zařídit to okamžité odhlášení alespoň v kritických případech. Ale spíš mi připadá, že je potřeba ještě definovat, jaké požadavky na bezpečnost vlastně máte. Protože jak jsem psal výše, nedává mi to dohromady smysl (což neznamená, že to smysl nemá – víme od vás jen útržky).
To okamzite odhlasenie nema byt z dovodu, ak by sa utocnik dostal k jeho jwt tokenu, alebo by sa mu niekto prihlasil jeho menom a heslom, tak aby vedel dane zariadenie okamzite odrezat a odhlasit.
-
To okamzite odhlasenie nema byt z dovodu, ak by sa utocnik dostal k jeho jwt tokenu, alebo by sa mu niekto prihlasil jeho menom a heslom, tak aby vedel dane zariadenie okamzite odrezat a odhlasit.
K čemu to bude, když se útočník na tom zařízení okamžitě zase může přihlásit přes Google?
-
To okamzite odhlasenie nema byt z dovodu, ak by sa utocnik dostal k jeho jwt tokenu, alebo by sa mu niekto prihlasil jeho menom a heslom, tak aby vedel dane zariadenie okamzite odrezat a odhlasit.
K čemu to bude, když se útočník na tom zařízení okamžitě zase může přihlásit přes Google?
Nemusi to nutne riesit tento scenar, moze sa stat ze zostal prihlaseny niekde na verejnom PC a chce sa z neho proste odhlasit.
-
Nemusi to nutne riesit tento scenar, moze sa stat ze zostal prihlaseny niekde na verejnom PC a chce sa z neho proste odhlasit.
To je ale úplně něco jiného. To se udělá prostě tak, že se v prohlížeči zahodí uložený token.
-
Nemusi to nutne riesit tento scenar, moze sa stat ze zostal prihlaseny niekde na verejnom PC a chce sa z neho proste odhlasit.
To je ale úplně něco jiného. To se udělá prostě tak, že se v prohlížeči zahodí uložený token.
A da sa to urobit ak sa v blizkosti takeho PC uz nenachadza?
-
Imho nevidim duvod proc neresit vyse zmineny problem prave pres sessions vydane na zaklade oidc tokenu (treba pres auth code flow). V praxi i v microservice architekture je to vcelku bezna metoda, ktera resi prave problem okamziteho odhlaseni. Pokud jde distribuci stavu a jeji dopad na skalovatelnost pak ji lze castecne resit session affinity. Proste zaridite, aby pozadavky od konkretniho klienta koncily vzdy na stejne instanci/podu a session budete na ostatni pody replikovat jen pro ucely ha. Jasne, nebudete moc skalovat az do vesmiru kvuli overheadu na distribuci, ale budete skalovat nejspis dostacne na to, aby to pokrylo Vas load.
Dalsi moznosti je presunout celej oidc stack na nejakou apigw/proxy pred microservice svet (k8s) na nejakej nadupanejsi hw pripadne se podivat zda to neumi treba cloudflare nebo jinej provider. Tim Vam odpadne nutnost resit do detailu tyto veci(authorizaci, refresh fazi, synchronizaci apod) na samotnych microservisach a nechat jejich logiku zamerenou na vas business problem se vsema vyhodama co microservice svet prinasi. Opet v praxi se tento scenar normalne pouziva.
Proti argumentu "pouzij jwt token authorizaci protoze microservices" muze stat argument bezpecaku "kdyz jwt tak oidc a kdyz uz oidc tak auth codeflow a zadny tokeny na fe/v browseru). Muzeme vest dlouhe filosoficke disputace jak moc stateless ma microservice svet byt, nicmene "opet v praxi" to zalezi na konkretnim pripadu a vysledku PoC.
Jinak zkuste se podivat jak funguje oidc codeflow, relaying party a vytvoreni session (v tomhle pripade auth cookie) zde:
https://www.nginx.com/blog/authenticating-users-existing-applications-openid-connect-nginx-plus/amp/
Navod je na nginx plus (placena verze nginxu), nicmene muzete pouzit jine reseni. Melo by Vam to dat ale predstavu jak to cele funguje a co od toho chtit.
-
A da sa to urobit ak sa v blizkosti takeho PC uz nenachadza?
Token se zahodí automaticky s ukončením prohlížeče. Pokud se někdo na sdíleném počítači přihlásí do Google účtu, pak do aplikace a pak to tam celé nechá otevřené a odejde, nepomůže mu odhlášení z aplikace na jiném počítači – protože ten, kdo si sedne k původnímu počítači, se do aplikace znovu přihlásí přes Google účet (který tam zůstal odemčený).
-
Taky je dulezite mit na pameti, ze v pripade microservice architektury bezi business logika aplikace v Javascriptu Browseru a tudiz je pristupna pro manipulaci.
To jsou mi věci…
-
autentifikacia cez jwt token bolo najviac odporucane riesenie pre microservice architekturu
Příčetně navržená aplikace s mikroslužbami používá gRPC bez autentifikace.
-
autentifikacia cez jwt token bolo najviac odporucane riesenie pre microservice architekturu
Příčetně navržená aplikace s mikroslužbami používá gRPC bez autentifikace.
To jsou mi věci. Teda pokud jste tím chtěl naznačit, že slovo „autentifikace“ neexistuje, pak máte pravdu.
-
autentifikacia cez jwt token bolo najviac odporucane riesenie pre microservice architekturu
Příčetně navržená aplikace s mikroslužbami používá gRPC bez autentifikace.
To jsou mi věci. Teda pokud jste tím chtěl naznačit, že slovo „autentifikace“ neexistuje, pak máte pravdu.
Kdo se vyzná v mikroslužbách, ví, o co jde. Jinak viz slovník.
-
Kdo se vyzná v mikroslužbách, ví, o co jde. Jinak viz slovník.
OK, oficiální slovníky tuhle zkomoleninu slova autentizace neznají, nicméně jazyková příručka ÚJČ nebo připravovaný akademický slovník současné češtiny už tenhle patvar uvádějí jako přípustný. Bod pro vás.
Nicméně by mne opravdu zajímal takový e-shop, elektronické bankovnictví, webmail, úložiště souborů apod. (všechno to jsou aplikace, které mohou být založené na mikroslužbách), které nepoužívají autentizaci.
-
Nicméně by mne opravdu zajímal takový e-shop, elektronické bankovnictví, webmail, úložiště souborů apod. (všechno to jsou aplikace, které mohou být založené na mikroslužbách), které nepoužívají autentizaci.
Chyba bude v porozumění psanému textu, viz ta část o gRPC.
-
Chyba bude v porozumění psanému textu, viz ta část o gRPC.
Tak to popište, jak s gRPC bez autentizace zařídíte, aby třeba v e-shopu nemohl jeden uživatel vidět objednávky jiného uživatele.