Použití JSON Web Token

[Honza]

Ahoj,
uvažoval jsem o použití JWT namísto session na serveru (= uložení stavu na straně klienta), ale zdá se, že to přináší více starostí než užitku, z pohledu bezpečnosti, a při potřebě zneplatnění tokenu před vypršením jeho platnosti je beztak potřeba zavádět nějaký stav na serveru, nebo ověřovat každý požadavek, čímž se postupně ztrácí všechny jeho výhody.

Používáte to v praxi někdo?

[Reklama]

[john]

JWT je standart siroko pouzivany napr. pri Google/Github OAuth, roznych APIs,...  = v praxi sa teda pouziva dost casto.

Existuju rozne "auth wall", ktore das ako reverse proxy pred tvoju app a oni potom spravuju JWT auth - pozri napr. keycloak-proxy, caddy s jwt/login pluginom,...

[Mirek Prýmek]

Ahoj,
uvažoval jsem o použití JWT namísto session na serveru (= uložení stavu na straně klienta) [...] při potřebě zneplatnění tokenu před vypršením jeho platnosti je beztak potřeba zavádět nějaký stav na serveru

Podle mě sis odpověděl sám. Pokud platí tyhle dvě premisy:

1. chceš to použít jenom jako storage uživatelských dat nebo session id - nechceš to použít na integraci s nějakou další službou apod.

2. chceš mít tokeny časově omezené

...tak ti JWT nepřinese oproti klasické session v DB (nebo ručně zašifrovanému tokenu) nic než komplikace.

[Honza]

Podle mě sis odpověděl sám.

No i přesto jsem se chtěl zeptat, jestli mi něco neuniklo,

JWT je standart siroko pouzivany napr. pri Google/Github OAuth, roznych APIs,...  = v praxi sa teda pouziva dost casto.

Existuju rozne "auth wall", ktore das ako reverse proxy pred tvoju app a oni potom spravuju JWT auth - pozri napr. keycloak-proxy, caddy s jwt/login pluginom,...

Já vím, že to používá Google, asi i FB, ale zajímaly mě menší projekty.
Mrknul jsem na ten "keycloak-proxy" a jenom jsem si potvrdil tušení, umí to sice i load-balancing, ale když mám L-B svůj, tak zase jenom komplikace místo zjednodušení.

Každopádně dík za náměty.

[perceptron]

jwt je sešna, ktora sa neda na strane servera revokovat. teda da. ale je s tym opruz.
jwt je sešna s verejnymi datami. teda daju sa kryptovat. ale je s tym opruz

nase sluzby z toho vycitaju public data o userovi kvoli ktorym nemusia v kuse konkaktovat third-party servicy

[Reklama]

[Filip Jirsák]

Podstatné není ani tak to, že by to Google nebo Facebook používali interně pro svoje služby, ale že to umožňuje bezpečně se přihlásit na váš web třeba přihlašovacími údaji Googlu nebo Facebooku, aniž by se je váš web dozvěděl, a zároveň Google nebo Facebook pořád bezpečně ví, o jakého se jedná uživatele (pokud třeba používáte nějakou jejich službu).

Používat to na svém vlastním webu, kde máte vlastní autorizaci uživatelů a jen vlastí služby, je trochu kanón na vrabce. Využití to má tam, kde uživatel (web) a poskytovatel nějaké služby jsou různé subjekty, které důvěřují nějaké společné autoritě zajišťující přihlášení uživatelů (často je to ten poskytovatel služby, ale nemusí být).

[Honza]

Podstatné není ani tak to, že by to Google nebo Facebook používali interně pro svoje služby, ale že to umožňuje bezpečně se přihlásit na váš web třeba přihlašovacími údaji Googlu nebo Facebooku, aniž by se je váš web dozvěděl, a zároveň Google nebo Facebook pořád bezpečně ví, o jakého se jedná uživatele (pokud třeba používáte nějakou jejich službu).

Toto je trochu nepřesné, kouknul jsem se schválně, jak to má udělané Google, pro autorizaci uživatelů používá čistě a pouze OAuth2 protokol, bez JWT. Ten je potřeba až tehdy, pokud je potřeba komunikace server-server (ne pro přihlašování uživatelů).
A navíc, JWT se použije pouze pro vyžádání access_tokenu od G, který má potom platnost pouze 1 hodinu. K dalšímu přístupu se použije jen ten. Což je hezký kompromis, ale je vidět, že ani G to pro klasické přihlašování nepoužívá.

[Martin]

Mrknul jsem na ten "keycloak-proxy" a jenom jsem si potvrdil tušení, umí to sice i load-balancing, ale když mám L-B svůj, tak zase jenom komplikace místo zjednodušení.

Nie, keycloak-proxy nevie load balancing. Je navrhnuta ako microservice, ktory si integrujes podla potreby. Za beznych okolnosti ti prida max 2ms latenciu. Pocas mojho stres testu zvladla s 3VCPU/34MB RAM spracovat 2k validnych JWT requestov za sekundu (a pritom median latencia bola ~100ms) alebo 9k nevalidnych JWT requestov za sekundu.

Pokial nepotrebujes skalovatelne stateless auth a robis s klasickymi plnotucnymi (makro) aplikaciami, tak potom pre teba asi pouzitie JWT nebude vhodne.

[Honza]

Nie, keycloak-proxy nevie load balancing. Je navrhnuta ako microservice, ktory si integrujes podla potreby.

Našel jsem tohle - KeyCloak Load Balancer.
Píšou "Built-In Load Balancer", ale umí pracovat i s externím L-B. Ale to je přesně to, čím jsem to komplikovat nechtěl, i když je to asi nejblíž tomu use-case.

[Martin]

OK, moja chyba. Este raz na vysvetlenie aj s linkami.

Keycloak http://www.keycloak.org/ je mega velke tazke kladivo od RedHatu na Identity and Access Management (IAM) a veci okolo - to je navrhnute pre velke organizacie a v tvojom pripade by jeho pouzitie bolo ako kanon na vrabce.
Existuje vsak https://github.com/gambol99/keycloak-proxy o ktorom som hovoril ja. Ma sice v nazve Keycloak, ale vie robit s akymkolvek OpenID.

Dalsie alternativy:
- Caddy s loginsrv/jwt pluginom - https://github.com/tarent/loginsrv/blob/master/caddy/README.md
- https://github.com/bitly/oauth2_proxy
- nginx/apache - primarne su web servery ale nejako sa to tam da dostrikovat, napr. cez LUA v pripade nginxu

Z mojej skusenosti je keycloak-proxy najsofistikovanejsi (token encryption, refresh tokens, certificate rotation, let's encrypt, sec. headers, ...). Samozrejme vzdy si to mozes naimplementovat aj sam vo svojej app.