Google OpenID connect a mikrosluzby

[malachovicky.jan]

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.

[Reklama]

[alex6bbc]

https://developers.google.com/identity/sign-in/web/sign-in

[malachovicky.jan]

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.

[Charon351]

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.

[malachovicky.jan]

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?

[Reklama]

[Filip Jirsák]

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ří.

[none_]

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.

[malachovicky.jan]

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.

[Filip Jirsák]

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.

[malachovicky.jan]

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

[ja.]

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é.

[malachovicky.jan]

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.

[none_]

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.

[Filip Jirsák]

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).

[Standa Blábol]

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.