Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - malachovicky.jan

Stran: [1]
1
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 23. 06. 2022, 19:34:15 »
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?

2
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 23. 06. 2022, 17:03:10 »
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.

3
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 22. 06. 2022, 10:40:12 »
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.

4
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 21. 06. 2022, 00:04:46 »
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.

5
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 20:07:05 »
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

6
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 18:43:03 »
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.

7
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 13:26:35 »
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?

8
Vývoj / Re:Google OpenID connect a mikrosluzby
« kdy: 20. 06. 2022, 12:53:50 »
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.

9
Vývoj / Google OpenID connect a mikrosluzby
« kdy: 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.


Stran: [1]