Ako zelis nesto kao facebook, google, twitter... login, onda ti je oAuth2 standardni protokol.
Ne znam koji framework koristis, za laravel imas vec gotov oAuth api server passport.

Baš obrnuto, treba mi nešto jednostavno za internu upotrebu i nevezano za frejmvork.

Obično je upravo jednostavnije kad se nešto piše za frejmvork nego kad se piše od nule.

Pa za PHP ne bi moglo jer to sto ti hoces je cross-site koliko mi se cini. Da ne pricam o tome da ako cuvas u cookie-ju i nekako izvrdas da radi na cross-site, imas ogroman security flaw.

Mozes da sprcas nesto u RESTu, ali prvo moras da razmislis kako bi se sa klijentske strane cuvale informacije, tacnije, na osnovu cega bi verovao da je taj korisnik bas taj korisnik.

Mozemo da diskutujemo o problematici jer i mene iskreno zanima.

Gledam sad "php cross domain authentication", izgleda se sve svodi na pisanje svog OAutha.

https://paragonie.com/blog/201...re-cross-domain-authentication

Ovo mi deluje zanimljivo.

Moze u php-u, ali je malo komplikovanije nego -nesto jednostavno- plug&play, odnosno svi sistemi moraju da podrzavaju jedan standard. Zato ljudi i preporucuju oAuth2 koji to resava, i identifikaciju i autorizaciju poziva. Isto i passport koji moze da zameni oAuth odnosno olaksava pravljenje sopstvene alternative ako "cloud" opcija nije primamljiva.
U svakom slucaju nije previse komplikovano da se napravi koristeci gotove alate/servise, ali treba da se razume kako i zasto tako radi, i kako ga pravilno primeniti na SVIM relevantnim pozivima i u svim aplikacijama.
Praviti bezbedan i pouzdan oauth od nule mislim da je neisplativo jer ima puno promenjivih i puno prostora za gresku (opet ovde je naglasak na bezbedan i pouzdan)

Ukoliko nije obavezno da bude implementirano u php-u,

https://www.keycloak.org/

Dok sam čitao o AWS servisima letimično sam pročitao o Cognito servisu i pretpostavljam da se koristi za takve stvari. Mada možda i grešim
https://aws.amazon.com/cognito/


_{[Ovu poruku je menjao CoyoteKG dana 14.06.2019. u 21:51 GMT+1]}

Mislim da je cognito isto sto i OAuth. Ne vidim nigde da nude third party servise kao opciju logovanja. Ovo mi deluje samo kao jos malo extra funkcija na OAuth i eventualni pregled korisnika direktno iz AWS konzole.

Evo moje ideje:

Napraviš auth sajt na posebnom domenu. Tamo je baza korisnika, baza tokena, bekend za administraciju i slično. Kad se neko loguje na web sajt, radi se redirekcija na auth sajt i posle logovanja lokalno se snima token. I tako na svakom sledećem sajtu. Uvek prvo redirekcija na auth koji proverava dal postoji token ili prima user/pass. Token bi se čuvao kao kuki ili u local storage i pristup bi imao jedino auth sajt.

Cross site autentifakcija mi nije neophodna. Rekao sam da ne bi bilo lose imati je.

Zadovoljilo bi me i samo to da se na svim sajtovima korisnici loguju sa istum user i passwordom makar i da moraju na svaki sajt da se uloguju posebno.

Pošto se radi o internoj potrebi, radilo bi mi posao i da sajt na kome se korisnik loguje, preko apija komunicira sa centralnim servisom a ne da se petlja sa redirekcijom korisnika da se uloguje pa vraćanje nazad.

Recimo, meni bi posao radilo i to da napravim jednostavan sistem koji se oslanja na postojeći POP3 server tako da se korisnici autentifikuju userom i passwordom koji već koriste i za imejl.

U svakom slučaju, pokrenuo sam ovu temu da čujem mišljenja ljudi koji imaju iskustva sa tim., da ne izmišljam toplu vodu. Jasno je da ljudi kojiimaju isksutva odmah gledaju šitu i komplikovaniju sliku pa su im takva i rešenja.

Pa , mozda samo da koristis jednu bazu za logovanje na svim sajtovima. Ako se korsnici registruju, sacuvas u tu jednu bazu i dostupno je svim sajtovima.

Ako ces svoj auth server, moraces da koristis tokene, da proveravas... i na kraju se svodi na oAuth (standardizovan protokol).

Cross site logovanje, jedino sto mi pada na pamet je da napises neki browser plugin, pa da sacuvas JWToken kad se user negde uloguje, pa da proveravas na drugim sajtovima.

Ako sam dobro shvatio, mislim da je to izvodljivo sa lokalnim php built-in serverom u pozadini na nekom portu, ukoliko ti production server omogućuje solidnu php-cli interakciju.

@generalizovanje:

Nekako negde, nakon _POST provere - u toku POST procesa, .. onda kada se korisnik loguje, odakle god to bilo, podaci koji su krucijalni, neka upiše u neki fajl (FILE_APPEND) koji će moći da se čita/upisuje samo uz pomoć built-in servera..



$prepend_file je isto što i u .htaccessu `php_value auto_prepend_file`

U .myUserCheckScript.php ukucaš dalju proveru, logiku, query, šta god ti navika.

I nateraš tu logiku da odradi dobar posao kroz sve form > method > post ( .. curl() ? ) zahteve i da napuca kukije na glavni `localhost:80|443` shodno built-in embeded server odgovoru ... Tj. da vrati recimo serijalizovanu listu uz pomoć koje ćeš znati koji je device, itd. i šta će da bude u kolačićima.

_{[Ovu poruku je menjao plus_minus dana 15.06.2019. u 15:54 GMT+1]}

OAuth2 naravno da bi svi znali kako da pisu request ali to i nije tolko bitno, bitnije je vrsta tokena koji mislis da im vratis pa bi ti ja preporucio JWT jer je on private-public tako da deo moze da se koriste bez kljuca a deo zahteva kljuc.

Pedja, jesi li uradio nesto? Kako je proslo?

Nisam još, pritegle obaveze.

Ne razumem sta je problem da napravis centralnu bazu sa korisnicima i jednu API klasu.
Radis kao sto i sada radis, imas methode login, logout i isLogged s tim da u ovim metodama ne citas po bazi vec obradis API response.

Da bi ti login bio validan na svim sajtovima onda na sajtu na kojem si vec ulogovan treba da imas linkove svih sajtova. Tekst linka je naziv sajta a sam link je trenutni sajt sa parametrom na koji sajt hoces da se ulogujes automatski.
Kada kliknes na jedan od linkova ti si na trenutnom sajtu, tu proveris da li si ulogovan i ako jesi onda mozes da se logujes na drugi sajt, generises neki token, stavis ga u centralnu bazu preko apija (jos jedna API metoda), redirektujes se na zeljeni sajt sa tokenom koji je u bazi.
Na zeljenom sajtu uporedis parametar token i token (jos jedna API metoda) koji je u bazi i ako je dobar onda mu odradis logovanje.

Vlado, ti stvarno sumnjaš da ja to ne umem da napravim? Nije stvar u znanju nego u oskudaciji sa vremenom.

Pa bilo mi je cudno. Ne razumem sta je onda problem? Mozes da koristis gotove klase nekog frameworka, treba ti samo API sloj. Duze traje ova rasprava na forumu nego sto se napravi.

Ovo sa cross sites logovanjem moze i bolje. Kada god se ulogujes na bilo koji sajt treba preko tokena da odradis redirekciju sa tokenom na centralni sajt i da se tamo automatski ulogujes.
Na drugi sajt kada odes i nisi ulogovan redirektujes se na na centralni, proveris da li je ulogovan na centralnom sajtu i ako jeste vratis ga sa tokenom za login na prvi sajt i tu ga ulogujes. Za ovo ti je potreban centralni domen ili poddomen

Generalno odluka o tome sta izabrati zavisi od odgovora da li ti kontrolises (razvijas i integrises) sve sajtove za koje ti treba SSO/centralni login ili ne.
Nije vezano za konkretan zahtev pokretaca teme ali moze da bude korisno nekom ko bude citao https://backstage.forgerock.com/

u jednom projketu za vise korpo sajtova koristimo stariju verziju OpenAM-a ali iz iskustva kazem da je poprilicno prilagodjena i skrojena da radi sa vise modula:
- LDAP-om
- custom DB user tabelom,
- network radius bazom,
- facebook/google


A takodje je i sarenilo klijenata:
- IIS (asp.net aplikacije)
- Tomcat
- IBM websphere,
- Erlang klijenti
- razni OAuth2 (uglavnom mobilne aplikacije)

Hocu reci da su Identity server i SSO funkcije prilican zalogaj sto tice obima posla.
(verovatno za jedan sajt u okviru istog domena, se ne isplati pristupiti na opisan nacin)

Rešio sam ovo zasad tako što sam jedan sistem php klasa za login usera, koji sam ranije radio, preuredio tako da se umesto sopstvene baze kači na eksterni servis koji ima API a ima i user-e.

Tako da sad mogu da za php aplikacije prosto upotrebim taj sistem za login i sve dele istu bazu korisnika.

Ja bi napravio WCF service ili u PHP stranicu koja bi radila to sto ti treba.
Znaci jedan sajt koji bi obradjivao sve login zahteve od drugih sajtova.
I naravno koristio bi Ajax za sve te pozive.
Podesio headere da CORS ne pravi problem.

Koriscenje Ajaxa za te provere, pozive itd je lose resenje.API je ipak bolji i jednostavniji.

Dobra praksa je koristiti autentikaciju sa 2 faktora. Podržavam ovu temu.

Srdačan pozdrav, Marko Radojčić (SamubucusELF).

P.S. SambucusELF potiče od: zove (ja sam iz Pazove), a ELF je ELF binarni format ili Samba server na GNU/Linuks operativnim sistemima koji može da razmenjuje datoteke, programoteke i druge fajlove sa Windows računarima od verzije 3.11 na dalje...

Moze ovo mnogo prostije
DaloRadius i LDAP koji pita radius. Zatim pGina na svaku windows masinu a za cisco/networking sve usmeris da pita radius.