PHP - mikroslužby - autentizace

[vesterna12]

Cílem je opustit kompletně php_session().
Chci co nejsnadnější škálování.
Možná Docker/Kubernetes, ale to mi přijde jako zbytečná další abstrakce (a spotřeba HW + další údržba). Automatizací posílám "Git release" na příslušné stroje. Stroje mám škálované pomocí skriptů. Do 10 minut je server vzhůru.
Replikace relací je další zbytečná komplikace.
Je vyloučeno, aby klient při každém dotazu posílal znovu jméno a heslo uložené v nějakém objektu.
Nechci ani cache autentizace a autorizace na koncových bodech api.
Co nejméně volání do DB,AD,Kafky,AMQ, nebo Redisu.
Žádné sdílené disky mezi servery. Výjimku mají pouze CDN segmenty.
Funkci si chystám tak aby byla schopná dotazování AD, protože jeden zdroj pravdy už mám. Jako druhý autentizační poskytovatel bude MYSQL databáze a poslední CURL volání do extérního systému.
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče. Pokud se klient pokusí data podvrhnout je vyloučeno data podepsat důvěryhodným klíčem (uložen na HSM), který má pouze autentizační server.
Autorita je chráněná. Jen tak si někdo certifikát nepodepíše...

Programuju příležitostně a nevěděl jsem jestli není moje teorie zastaralá.
Děkuji panu Jiráskovi za jeho trpělivost a vysvětlení.

[Reklama]

[hurvajs spejbl]

@Death Walker: jediný kdo tu plácá hlouposti, jste vy. Pokud neumíte používat JWT, je to Váš problém. JWT si nikdy nehrálo na to, že nejde přečíst (ve standardní verzi) jde normálně dekódovat do čitelné podoby. Jak píše p. Jirsák, uložit si tam můžete co chcete. Samozřejmě validace tokenu je také na Vás, jak se poperete s invalidací vypršeného či revokovaného tokenu.

Ale na to, že obyvatelé tater, jsou ..., jsme my v ČR zvyklí :-)

[Filip Jirsák]

Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče.

Jenom pro přesnost, tohle je podepisování, ne šifrování. Šifrování by fungovalo opačně – to, co má být tajné se zašifruje veřejným klíčem, takže to následně může dešifrovat jen majitel privátního klíče. To, co vy potřebujete, je podepisování – takže postup jste popsal správně, jen se to jmenuje jinak. (Ano, na úrovni algoritmů je podepisování a šifrování to samé –  když po sobě provedete transformaci nejprve jedním a pak druhým klíčem z páru, dostanete zpět původní vstup.)

[Death Walker]

@Death Walker: jediný kdo tu plácá hlouposti, jste vy. Pokud neumíte používat JWT, je to Váš problém. JWT si nikdy nehrálo na to, že nejde přečíst (ve standardní verzi) jde normálně dekódovat do čitelné podoby. Jak píše p. Jirsák, uložit si tam můžete co chcete. Samozřejmě validace tokenu je také na Vás, jak se poperete s invalidací vypršeného či revokovaného tokenu.

Ale na to, že obyvatelé tater, jsou ..., jsme my v ČR zvyklí :-)

Vazne? Kde som pisal ze nejde precitat, link?

[Death Walker]

Tu mate popis ako sa prihlasuje do Gmailu cez Google account.
https://blog.theodo.com/2019/07/single-sign-on/
To je presne ten pripad ako sa ma JWT pouzivat. Ten token obdrzi len Gmail od GA. Klientovi vobec nedorazi pretoze si ho ukladat koli bezpecnosti nemusi.

[Reklama]

[Filip Jirsák]

Tu mate popis ako sa prihlasuje do Gmailu cez Google account.
https://blog.theodo.com/2019/07/single-sign-on/
To je presne ten pripad ako sa ma JWT pouzivat. Ten token obdrzi len Gmail od GA. Klientovi vobec nedorazi pretoze si ho ukladat koli bezpecnosti nemusi.

Na tom odkazu není popsáno konkrétně přihlášení ke Google účtu, je tam obecný popis přihlášení tak, jak je definován např. v OAuth 2 (přičemž Google opravdu používá tento standard). A v tom popisu ten token ke klientovi vždy dorazí. Všimněte si, že je tam vždy přesměrování prohlížeče na adresu poskytovatele služeb s tokenem připojeným v URL. V tomto okamžiku tedy prohlížeč vidí přihlašovací token, a je jenom na provozovateli té služby (v textu www.service-provider-1.com a totéž s 2), jestli si ten token uloží v prohlížeči nebo ne. No a pokud provozovatel služby chce provozovat mikroslužby a chce se tudíž vyhnout sdílené session, je logické zapamatovat si ten token v klientské aplikaci a autorizovat jím každý zaslaný požadavek.

Monolitická aplikace která tak jako tak bude používat session samozřejmě ten token u uživatele ukládat nemusí, protože ho nebude používat – server si na základě tokenu vytvoří pro uživatele session a uživatel je nadále identifikován tou session.

[Death Walker]

Ku klientovi sice dorazi, hned na to ale prebehne redirect na ziadanu stranku, pricom sa ten token neulozi  pretoze by bolo mozne ho zneuzit. OAuth2 funguje inak tam este server poziada cez api o token ktori si ulozi.

Vy mate ten dojem ze rozlisovacim znakom pre monolit je pritomnost session? Nie je to nahodou bezstavovost aplikacie? Session do aplikacie stavovost nezanasa. Maximalne si nejaka lopata moze do tej session zacat ukladat stavove premenne, ale to sa da odchytit pri code rewiev.

[Filip Jirsák]

Ku klientovi sice dorazi, hned na to ale prebehne redirect na ziadanu stranku, pricom sa ten token neulozi  pretoze by bolo mozne ho zneuzit. OAuth2 funguje inak tam este server poziada cez api o token ktori si ulozi.

Vy mate ten dojem ze rozlisovacim znakom pre monolit je pritomnost session? Nie je to nahodou bezstavovost aplikacie? Session do aplikacie stavovost nezanasa. Maximalne si nejaka lopata moze do tej session zacat ukladat stavove premenne, ale to sa da odchytit pri code rewiev.

Token dorazí ke klientovi, takže uživatel ho může získat a může si ho uložit. Což ale vůbec ničemu nevadí, protože jej nemůže vůbec nijak zneužít – je to jen potvrzení, že se přihlásil opravdu on. Je to asi jako kdyby se někdo pokoušel zneužít svou vlastní občanku.

Nic o rozlišovacích znacích monolitu jsem nepsal. Pouze jsem reagoval na vaše komentáře o monolitické aplikaci používající session. Session samozřejmě stavovost do aplikace zanáší. HTTP protokol jako takový je bezestavový, proto bylo vynalezeno to, že si server uloží stav pod nějakým identifikátorem a ten identifikátor se pak posílá klient s každým požadavkem. Tím se nad bezestavovým protokolem dá vytvořit stavovost. Takže HTTP session se používá právě proto, abyste do aplikace používající nestavové HTTP dostal stavovost. Ve stavu si pak můžete uložit třeba o jakého se jedná uživatele nebo jaké zboží má právě v košíku. Když si server nepamatuje stav, tyhle informace si musí pamatovat klient a předat je serveru pokaždé, když jsou potřeba.

No a tomu principu se začalo říkat session, protože to udržuje stav, ale ne trvale, pouze po dobu práce uživatele s tou aplikací. Což je v angličtině právě „session“, v češtině by tomu bylo asi nejblíž „sezení“ nebo „seance“.

Co je HTTP session se dočtete třeba na Wikipedii, kdybyste mi to nevěřil.

[FactChecker]

Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.

[Jvic V.]

Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování

Pokud uvažujete o microservisní architektuře, je třeba nekoukat jen na výhody, ale přečíst si i nevýhody... Z osobní zkušenosti bych tutu architekturu doporučil pouze v případě, že

A) Máte velmi velký SW
B) Máte několik týmů o několika vývojářích

Ve většině případu platí A, ale už nikdo nemá/nezaplatí B... V pár lidech microservisní architektura přináší víc nevýhod než výhod.

• Transakce, Rollback
• Error handling
• Autorizace/authentikace

[vesterna12]

Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče.

Jenom pro přesnost, tohle je podepisování, ne šifrování. Šifrování by fungovalo opačně – to, co má být tajné se zašifruje veřejným klíčem, takže to následně může dešifrovat jen majitel privátního klíče. To, co vy potřebujete, je podepisování – takže postup jste popsal správně, jen se to jmenuje jinak. (Ano, na úrovni algoritmů je podepisování a šifrování to samé –  když po sobě provedete transformaci nejprve jedním a pak druhým klíčem z páru, dostanete zpět původní vstup.)

Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".

[Filip Jirsák]

Nepoužívejte JWT s local storage. Použijte cookie s Secure, HttpOnly, SameSite=Strict. Cookie musíte chránit před CSRF/XSRF, což je triviální. Přístup k local storage získáte přes XSS, před kterým je dobrá ochrana složitá, nadarmo není v OWASP Top Ten.

Před XSS je potřeba web chránit tak jako tak. Pokud si útočník na vašem webu může spouštět libovolné skripty, nepomůže nic, ani HttpOnly cookie – útočník prostě útočný kód spustí rovnou z aplikace a nepotřebuje cookie znát, přiloží ji za něj rovnou prohlížeč. A ochrana před XSS zas tak složitá není – v první řadě je potřeba vyhnout se používání nebezpečných postupů (které obvykle nejsou k ničemu potřeba), v druhé řadě se dá přidat ochrana na úrovni prohlížeče (která je starší, tudíž více podporovaná, než SameSite cookies). Ochrana před CSRF/XSRF je právě ta SameSite cookie, starší ochrany nejsou „ochrany“ ale rozbíjení aplikace.

[vesterna12]

Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování

Pokud uvažujete o microservisní architektuře, je třeba nekoukat jen na výhody, ale přečíst si i nevýhody... Z osobní zkušenosti bych tutu architekturu doporučil pouze v případě, že

A) Máte velmi velký SW
B) Máte několik týmů o několika vývojářích

Ve většině případu platí A, ale už nikdo nemá/nezaplatí B... V pár lidech microservisní architektura přináší víc nevýhod než výhod.

• Transakce, Rollback
• Error handling
• Autorizace/authentikace

• Transakce, Rollback

- používám relační databázi

• Error handling

- i v případě monolitu

• Autorizace/authentikace

- to už tu teď řeším...

Aplikace není zase tak velká. Jde o jeden malý e-shop, ale je to skvělá příležitost a taky je tu potenciál růstu.

[Filip Jirsák]

Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php

V tom případě budou opačně ty klíče – autorizační server bude šifrovat veřejným klíčem, služby dešifrovat privátním. Správně by každá služba měla mít svůj privátní klíč. Ale počítejte s tím, že šifrovaná data nezaručují autenticitu. Tedy stejně bude potřeba je podepisovat.

V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".

To mi připadá trošku překombinované. Když se neověří podpis, stejně nemůžete těm údajům věřit. A na to, že je nemohl zašifrovat nikdo jiný, se spoléhat nedá – šifruje se veřejným certifikátem, tj. musíte počítat s tím, že data může zašifrovat kdokoli. Bez ohledu na to, zda si budete hlídat, aby se veřejný certifikát nedostal „ven“.

[vesterna12]

Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php

V tom případě budou opačně ty klíče – autorizační server bude šifrovat veřejným klíčem, služby dešifrovat privátním. Správně by každá služba měla mít svůj privátní klíč. Ale počítejte s tím, že šifrovaná data nezaručují autenticitu. Tedy stejně bude potřeba je podepisovat.

V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".

To mi připadá trošku překombinované. Když se neověří podpis, stejně nemůžete těm údajům věřit. A na to, že je nemohl zašifrovat nikdo jiný, se spoléhat nedá – šifruje se veřejným certifikátem, tj. musíte počítat s tím, že data může zašifrovat kdokoli. Bez ohledu na to, zda si budete hlídat, aby se veřejný certifikát nedostal „ven“.

Šifrovat řetězec můžu privátním klíčem a možné je ho dešifrovat pouze pomocí relevantního certifikátu generovaného z privátního klíče. Je to tak? Psal jsem klíče, ale myslel jsem klíč a certifikát. Pokud to tak je tak když se mi nepovede dešifrování certifikátem tak můžu považovat zdroj za nedůvěryhodný, protože byl šifrován očividně někým jiným.