Google OpenID connect a mikrosluzby

[Filip Jirsák]

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.

[Reklama]

[bobprasak]

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

[malachovicky.jan]

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.

[Filip Jirsák]

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?

[malachovicky.jan]

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.

[Reklama]

[Filip Jirsák]

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.

[malachovicky.jan]

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?

[bobprasak]

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.

[Filip Jirsák]

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

[Idris]

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…

[Idris]

autentifikacia cez jwt token bolo najviac odporucane riesenie pre microservice architekturu

Příčetně navržená aplikace s mikroslužbami používá gRPC bez autentifikace.

[Filip Jirsák]

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.

[Idris]

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.

[Filip Jirsá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.

[Idris]

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.