Avtentikacija - najboljsa praksa?

Pozdravljeni,

razmisljam o spletni strani ki bi bila postavljena z Bootstrap+Jquery frontendu in PHP+SQL na backendu. Projekt je precej preprost, tako da mislim da ne bom imel potrebe po PHP frameworkih.

Sedaj pa me zanima, kako naj se lotim avtentikacije? Spletna stran bo v celoti dostopna samo avtenticiranim uporabnikom, in rad bi zagotovil, da so vsi requesti ki pridejo do PHP skipt avtenticirani. Klici do PHPja bodo verjetno vsi narejeni z jQeury.Post() in jQuery.getJSON().

Ima kdo link do kaksnega primera kaj je trenutno najboljsa praksa in kako bi se lahko lotil avtentikacije? Glavna stvar ki jo zelim prepreciti, je da PHP vrne vsebino DB-ja anonimnemu uporabniku.

Hvala!

Mislim da on niti še nima loginov urihtanih, to je prvi korak. Tisti drugi, da backend na to zvežeš, je načeloma lažji.

Najnovejša/najboljša praksa za logine je OAuth 2.0 z JWT tokeni.

Najboljša praksa je tudi da se NE lotiš svoje implementacije identity/login providerja, ampak dobiš nekaj že narejenega, ker se ni s tem za igrat. Če hočeš najmanj eforta in si pripravljen plačevat izbereš implementacijo kot service (naprimer Azure AD B2C). Če ti ni problem, da sam en docker postaviš in vzdržuješ, si omisliš morda Keycloak.

Ta example ki si ga dal je sicer specifičen za ponudnika Okta, ki je še en primer identity providerja "as a service". Ampak veliko kode je najbrž enake ne glede na providerja.

Širina izpostavljenosti ter "seperation of concerns".

Pri tokenih (pa naj bo to Oauth 2.0 ali pa kak drug) je identity server edini backend, ki ima karkoli opraviti z loginom uporabnika. Ostali backendi zgolj preverjajo, če je uporabnik že logiran ko pride request (pogledajo v token) in z gesli ter loginom nimajo opravka. S stališča "seperation of concerns" to pomeni tudi single source za "login logiko" (audit,...). Identity backend ima navadno tudi ločene pravice kateri developerji lahko to upravljajo (ali pa izbereš celo zunanji service) in ima praviloma tudi precej bolj strogo politiko razvoja in spremembe kode.

Pri basic auth na varnost veliko bolj vpliva čisto vsak posamezni API endpoint, že napaka posameznega endpointa lahko pomeni "credentials leak". Tko se ne dela več, če je na public internet zadeva.

Hexx je 17. jan 2021 ob 11:32 izjavil:

mislim da ne bom imel potrebe po PHP frameworkih.

Ce ne uporabljas frameworka, si samo nakopljes vec dela, saj moras sam implementirati avtentikacijo, prav tako pa je vec moznosti, da bo tvoja koda imela vec bugov, kot ce uporabis uveljavljen framework.

Uporabi npr. precej popularen Laravel, ki ima celotno upravljanje z uporabniki in avtentikacijo ze vgrajen.

kuall je 17. jan 2021 ob 13:22 izjavil:

potem shrani ta user pass v cookie v neki zakriptirani obliki in ob vsakem obisku strani pošlje ta cookie. če cookie zbrišeš se moraš spet prijavit, da se cookie spet zgenerira.

Gesla nikoli ne hranis nikjer, niti v zakriptirani obliki. V skoraj vseh primerih je najboljsa resitev generiranje nakljucnega token-a, ki ga shranis v DB ter v cookie. Ob vsakem requestu pa preveris, ce je ta token se valid.

Se vidi, da nimate pojma...

Protokol OAuth2 se uporablja za avtorizacijo in ne avtentikacijo. Poglej si protokol OpenID Connect, ki temelji na OAuth2 in se uporablja za prenos avtentikacije na neko tretjo zaupanja vredno osebo (v primeru STja je to Google). V tem primeru tvoj page na nobeni točki ne pride v stih z uporabnikovim geslom, saj ga tvoj page redirecta na google login, kjer se prijavi z google accountom (lahko 2FA in podobno) in dobi s strani googla podpisan JWT žeton, kjer je navedena njegova identiteta. Različni flowi sicer predvidevajo različne načine, kako tvoj page pride do tega žetona. Malo starejši je protokol SAML, ki v principu deluje enako.

Zakaj je to super:
Ker se ti ni treba ukvarjati s hash funkcijami, pozabljenimi gesli in podobnimi nevšečnostmi.

Zakaj to ni super:
Če je identity provider evil ali pa down, imaš probleme.

Tako da pod črto je vse odvisno od specifičnega primera uporabe. Recimo v poslovnih okoljih bi za providerja identitete imel Azure AD ali pa on premise ADFS, ali pa Keycloak če niste MS fani.

edit: če že hočeš sam handlati avtenticiranje uporabnikov, ne tega delati iz nule, ker boš sigurno zajebal. Raje uporabi nek uveljavljen framework.

Dobro razmisli, ali se želiš vezati na nekega 3rd party ponudnika.

In dobro razmisli tudi, kaj je in kaj ni popoln overkill za tvojo aplikacijo.

Nekaj od naštetih stvari so bili dobri nasveti, predvsem pa ta, da se ne lotevaj stvari iz nule. Uporabi framework, vsaj za avtentikacijo in avtorizacijo. Glede na tvoje dejanske potrebe pa izberi, kako komplicirano se boš tega lotil.

Premalo si povedal, kdo bodo uporabniki. Najbolj simpl na server strani je če vklopiš avtentikacijo v HTTPS z uporabniškimi certifikati. Vse ti potem naredi web-server, ti dobiš id uporabnika serviran na krožniku in ga samo prepošlješ na backend?

Hexx je 17. jan 2021 ob 16:22 izjavil:

Ales je 17. jan 2021 ob 16:04 izjavil:

Uporabi framework, vsaj za avtentikacijo in avtorizacijo.

Se nanasas na framwork tipa Laravel ali na servis kot je Okta? Tale resitev z Okto se mi zdi, da ne prinese nobenega balasta, je pa res da je na meni da pravilno naredim implementacijo.

Zgolj strogo izvedbeni, programerki vidik, je le en del problematike.

Glede na to, kar si do sedaj povedal o aplikaciji, jaz ne bi uporabljal 3rd party servisov. IMHO ni nobene potrebe za tem.

Navodila za Debian in nginx:

apt-get install apache2-utils

htpasswd -B -C 10 -c /etc/nginx/user_pass_combo.db janez
htpasswd -B -C 10 /etc/nginx/user_pass_combo.db marija
htpasswd -B -C 10 /etc/nginx/user_pass_combo.db micka
....

# auth example
location /test/ {
        autoindex on;
        auth_basic "Analitika financ...";
        auth_basic_user_file /etc/nginx/user_pass_combo.db;
}

Dokumentacija:
https://docs.nginx.com/nginx/admin-guid...

Predlagam, da v kolikor boš dal spletno stran na public, da monitoriraš requeste oz. log fajle. V kolikor ne potrebuješ dostopa iz kitajske, rusije... jih pač v celoti zablokiraš. Mogoče lahko narediš tako, da odpreš dostop samo za slovenske IPje.

Ter seveda, da so gesla dolga npr. vsaj 12 znakov.