Sa zicem ca un site ofera optiunea utilizatorilor sa se infregistreze fie cu email/parola, fie cu LinkedIn sau Facebook login.
S-au inregistrat un numar de utilizatori cu LinkedIn/Facebook, dar proprietarii site-ului se hotarasc sa renunte la social login.
Ce se poate face cu utilizatorii deja inregistrati cu platformele astea?
Pentru ca daca este scos social login, o parte din utilizatori nu se mai pot loga.
Poate sa fie invitati sa isi seteze parola?
Trebuie să oferi o perioada de tranziție și să înviți/“forțezi” utilizatorii loghinați prin FB să-și facă cont “normal”. Sau le dai opțiunea să-și steargă contul…
1 Like
Ai emailul de la reteaua sociala, adaugi un camp in db pentru parola si-l completezi prin implementarea “recuperare parola”. Tehnic e simplu, practic poti scoate logarea de tot. Nu-mi pot imagina un context in care hotararea proprietarilor site-ului sa fie buna.
4 Likes
Depinde daca la social login tu salvezi de la callback-ul de OAuth email-ul utilizatorului sau nu la autorizare.
Daca ai deja email-ul pur si simplu il pui sa dea click intr-un link din email cand se logheaza ca sa isi seteze o parola.
Altfel mentii social login-ul, dar ii schimbi scopul doar intr-o inregistrare cu email si parola la contul existent.
Eu zic sa incerci sa ii convingi sa pastreze OAuth-ul deoarece la inregistrarea cu email si parola trebuie sa pui captcha, utilizatorul e obligat sa confirme contul pe email si o sa ai mult mai putini utilizatori confirmati, daca ii lasi fara confirmare o sa fie mii si mii de boti intr-o luna. Acum nu zic sa se poata loga cu fiecare cont posibil, Google/Facebook sunt de ajuns.
Nu știu ce vrea OP să facă, dar presupun că uitați cu toții cât de fragil este internetul și cum ți se poate tăia accesul la un anumit serviciu (își aduce aminte cineva de Iran și de accesul tăiat la github, de ex?). Nu ai vrea să ai un backup plan în cazul în care jumătate din utilizatorii tai nu mai au (brusc) acces la SSO-ul folosit până în acel moment?
2 Likes
Iranul precum si alte tari din zone mai sensibile ale lumii au parte de sanctiuni. Nicio companie nu doreste sa fie tarata prin procese cu guvernul SUA sau unui alt stat. Am vazut acel lucru si pe twitter.
Sunt de acord cu tine ca Internetul este fragil si este nevoie sa se supere un guvern/companie si adio servicii si altele.
In afara de Facebook, Google, Twitter, se mai pot folosi si alti provideri de sso. Pt aplicatiile web de la munca folosim Ping Identity. Pe langa acesta avem mai multe.
Oricum, dupa cum s-a mai spus, se poate oferi si optiunea de login cu user/email si parola, cum are si Discourse
E fragil internetul, dar OAuth-ul in majoritatea cazurilor ofera multe avantaje si nu e problema ta daca o tara e blocata de SUA. La firme SSO, mai exact OAuth pe contul de email de la firma (Office365/Google/Okta/Auth0) este cel mai ieftin/sigur mod de a avea control asupra accesului angajatilor si de a avea un grad de securitate conform ISO. (ceea ce e foarte important acum cu GDPR)
La B2B OAuth este practic obligatoriu (doar ca ai friendly name pe firma). Imagineaza-ti ce complicat e sa respecti procedura de a da parola de la un cont daca e sa o faci cum trebuie, cati stiu sa iti foloseasca GPG de aici de pe forum ca si programatori ?
Stai sa înțeleg: ai un site, o aplicație, ceva. Și ai SSO. Iar un guvern decide să taie accesul utilizatorilor la acel SSO. Și… NU E PROBLEMA TA? Dar a cui o fi problema? Observă în lista aia de mai sus că google este site-ul cu cele mai multe servicii blocate!
Nu are nici o legătură GDPR în toată povestea asta.
2 Likes
Corect, nu e problema ta daca nu e in cerinte ca aplicatia ta trebuie sa fie redundanta la razboi nuclear, razboi economic, catastrofe naturale, etc.
Daca e in cerinte trebuie sa te gandesti la multe alte detalii decat pur si simplu sa le dai acces la oamenii pe care Google ii blocheaza, ca nu ii blocheaza doar asa fiindca vrea sa piarda milioane de dolari pe zi din reclame. Plus nu stiu daca e o idee buna sa te loghezi oricum din acele tari fiindca poate ai stack-ul de HTTPS modificat cumva, ti se instaleaza ceva autoritate SSL cu un backdoor de guvern si cand iti introduci userul si parola si guvernul vede ce ai introdus. Adica nu poti cumpara laptop/telefon in Iran/China fara backdoor.
Acum e alta treaba daca de exemplu Google blocheaza Romania de pe o zi pe alta sau daca Google cade de tot. Sansele sunt mici, dar e un risc la care se face analiza de risc, notezi intr-un document persoane responsabile care pot sa repuna sistemul in functiune fara Google si vezi daca se merita sau nu sa implementezi fallback sau sa nu folosesti SSO.
1 Like
Continui să te concentrezi pe problema greșită.
Pe vremea mea™ programarea se făcea ceva mai defensiv. Adică pleci de la „ce se poate întâmpla rău?”, continui cu „ce altceva se poate întâmpla rău?” și tot așa. De la un timp observ un optimism nesănătos și o înclinație excesivă înspre externalizare, PaaS-uri & co.
Tu pleci de la premisa (falsă) că „nu se poate întâmpla”, mai ales de pe o zi pe alta. Uită-te la Iran (îl zic pe ăsta pentru că-i cel mai recent exemplu, dar în trecut s-au mai întâmplat sanscțiuni și în alte țări). Literalmente de pe o zi pe alta au fost blocate o grămadă de servicii.
La cum pui tu problema, trebuie să analizezi dacă merită sau nu să lași utlizatorii/clienții să… se autentifice.
Mai știi când a picat cloudflare pentru o zi și jumătate din internet era mort? Cum ar fi să ai tot serviciul up & running darrrrr… pentru că autentificarea este externalizată, utilizatorii să nu se poată autentifica?
Nu zic să nu folosești SSO, dar poate că un fallback nu strică și poate că nu ar trebui implementat în momentele de criză…
@George_Ilie a întrebat cum poate face să renunțe, voi încercați să îl convingeți să… renunțe la renunțat. Nu știți context, nu știți motivație, dar sigur face el ceva greșit.
Dacă ție îți cere clientul/angajatorul să faci ceva (care nu este nici ilegal, nici imoral; este doar un feature în plus/minus) o să spui… ce? „Oh, stai să-ți arăt ce am văzut eu pe forumul asta mișto! Sigur-sigur te va face să te răzgândești!”
3 Likes
In primul mesaj i-am raspuns, dupa am continuat discutia.
Eu tot imi mentin opinia ca OAuth nu este optional in 2019, toate firmele cu standarde de securitate interzic utilizarea unui nume de utilizator si parola. Totul trebuie sa treaca printr-un singur SSO cu MFA/2FA administrat de HR. Iar pe persoana fizica multi isi uita parola dupa fiecare utilizare sau si-o refolosesc. Sa nu mai zic nimic ca 50% nu stiu de butonul de recuperare parola si isi fac mereu alt cont.
Nu vreau sa ma gandesc la ce se intampla daca cade Google sau e interzis la noi, faptul ca utilizatorii nu se pot loga in aplicatie ar fi cea mai mica problema a mea. N-ar avea de unde sa ia aplicatia, nici macar nu li s-ar deschide :D.
Problema e atat de mare incat daca Google cade, nici macar Google nu poate intra pe Google Cloud sa isi repare serverele. (inginerii Google nu se pot loga cu user si parola/cheie personala, inclusiv SSH are SSO)
Produsul despre care vorbesc are doua categorii de utilizatori. Pentru o categorie Oauth este un beneficiu, pentru cealaltă un dezavantaj sau inutil.
Soluția de mijloc este renunțarea completă la Oauth.
Motivul simplu pentru care Oauth nu mai este util in cazul de față este ca LinkedIn și-a schimbat accesul la API si este nefolositor. Până la 1 Martie 2019 se putea obține si altceva in afara de email, nume si poză.
In principiu Oauth este util, mai ales la începutul de drum al unei platforme, pentru că utilizatorii vor să afle repede beneficiile unui produs, fără a completa niște etape mai complicate.
Exista cazuri, ca si cel de fata, unde Oauth nu este util. Daca li se da opțiunea sa se logheze cu LinkedIn, o vor face cu contul de email propriu. Insa fiind un produs B2B, conturile cu adresa de email personala nu sunt dorite, ci cele date de către angajator.
Din sugestii cred ca mai simplu este sa li se dea opțiunea ca după logare, utilizatorii existenți sa isi seteze o parolă, iar cei care doresc sa se înregistreze cu LinkedIn, sa li se spună ca nu mai e posibila înregistrarea, ci doar logarea.
1 Like
am văzut că thread-ul ăsta a fost promovate pe Facebook și am zis să-l readuc la viață, că-mi place subiectul.
m-am logat înainte să postez prin Oauth de la Google 
nu vând nimic, doar mă laud 
joke aside: da, poate tăierea unui acces la o resursă de genul Facebook / Google / Twitter / LinkedIn / Github să-ți facă viața grea ca dezvoltator de aplicație, dar în aceeași măsură, nu cred că nu există soluții facile, la îndemână, prin intermediul cărora să ocolești situațiile de acest gen.
de exemplu: ascunzi butoanele de social login și schimbi formularul de login din formular cu 2 câmpuri, în formular cu un singur câmp. îl pui pe om să își bage adresa de email și verifici la nivel de aplicație dacă anterior era un user logat cu Oauth.
dacă da, atunci îi arunci un mesaj în interfață și-i spui că nu mai suporți acest tip de login și că-l rogi frumos să se ducă la email și să dea click pe linkul pe care i l-ai trimis pentru a-și seta o parolă.
aproape la fel ca la reset password.
acum, înțeleg ce spune @iamntz cu abordarea defensivă, dar dacă nu îți asumi niște riscuri și nu folosești ceva deja construit care să-ți faciliteze în 99% dintre cazuri o experiență mai plăcută, s-ar putea să chinui o mulțime de oameni cu pași inutili pentru că s-ar putea, în 1% dintre cazuri, să se certe niște guverne între ele și să te lase pe dinafară.