UX este motivul PENTRU care ai vrea sa folosesti asa ceva. Cel putin eu asta incerc sa obtin cu solutia asta.
Tu pleci de la o premisă (posibil) greșită: că toți userii au client de mail configurat pe sistem
Ai dreptate, este posibil ca un procent mare de utilizatori sa nu aibe aplicatia de mail configurata. De aceea sistemul va oferi fallback pe magic links. Adica o sa fie in pagina de login butonul de send mail si mai jos “Or we could send you a magic link”.
un mailto: nu va face decât să deschidă un ecran de configurare unde trebuie să se autentifice (în cel mai bun caz) sau să bage servere smtp, porturi și alte minuni.
Nu, daca nu ai aplicatia de mail configurata, mailto: nu face nimic. Si am gasit o metoda prin care sa pot detecta cazul asta. Iar atunci, butonul de login va fi inlocuit cu 3 butoane (Gmail, Outlook, Yahoo). Daca apesi pe Gmail de exemplu, va deschide un tab nou cu gmail web catre URL-ul de compose new email precompletat. Chestia asta ar trebui sa rezolve o parte din probleme pe desktop unde oamenii folosesc majoritar Gmail pe web.
cum procedez dacă folosesc pc-ul unui prieten care are clientul de mail configurat?
Folosesti optiunea de magic link.
Ca idee, solutia asta este mai potrivita pentru mobile devices, acolo unde majoritatea utilizatorilor au aplicatie de mail. Pe desktop intinde putin coarda :))
Uite aici gresești. mailto: nu face nimic dacă nu ai o aplicație de mail instalată (cel puțin pe windows). În momentul în care instalezi o aplicație de mail, acea aplicatie se înregistrează ca handler de mailto:, chiar dacă nu e configurată. Și chiar dacă nu ai o aplicație, face un nimic foarte dubios:
Uite un usecase mai deosebit pe mobil: am un client de mail cu un cont adăugat în clientul de mail (i.e. mailul nu există în Settings → Accounts). Practic acel cont nu există în afara acelui client de mail. Eh, cum procedăm în cazul ăsta? Afișezi un magic link care mă trimite la google/yahoo/outlook? Dar mailul ăsta este pe un domeniu custom, n-are treabă cu jucătorii mari. Cum procedăm?
Ok, o sa incerc sa explic putin flow-ul. Cand un serve iti trimite pe mail un link chiar daca e interceptabil nu poate fi modificat de un tert pentru ca serverul stie unde l-a trimis, ce contine si ce asteapta. Intrand la tine in cont si confirmand link-ul dovedesti indirect ca esti posesorul contului fara sa precizezi serverului ce cont ai folosit, altfel nu ai fi putut avea link-ul.
In cazul tau (reverse) chiar daca serverul iti trimite un cod si il retrimiti (confirmi) dintr-un client de mail nu dovedeste clar ca tu esti cel care trimite codul pentru ca o interceptare a mesajului tau poate fi replicata avand date de identificare in continut si nu deductibile din contextul comunicatiei.
LE: Nu te supara, nu e troll, nu vreau sa iti contest idea dar cel putin partea asta nu pare safe 100% sa o folosesti in productie. Poate ma insel dar cel putin asa vad lucrurile in acest context de care spui…
Uite aici gresești. mailto: nu face nimic dacă nu ai o aplicație de mail instalată
Ai dreptate, ma gandeam la cazul in care nu ai instalata o aplicatie de mail.
Eh, cum procedăm în cazul ăsta? Afișezi un magic link care mă trimite la google/yahoo/outlook? Dar mailul ăsta este pe un domeniu custom, n-are treabă cu jucătorii mari. Cum procedăm?
Acele linkuri catre gmail/outlook/yahoo sunt tot un fel de mailto:, adica tot te pun pe tine ca utilizator sa trimiti mail catre sistem.
Magic links se refera la faptul ca iti introduci adresa de mail intr-un input, si sistemul iti trimite un link te autentificare. Pentru cazul de care ai zis tu se poate folosi optiunea asta.
Este obligatoriu sa existe mecanism de magic links ca alternativa, pentru ca solutia cu mailto: va merge poate in 60% din cazuri. Dar speranta mea e ca pt acele 60% din cazuri, va face autentificarea mai usoara.
E de apreciat initiativa si sper sa reusesti sa o implementezi desi la momentul acesta o metoda de autentificare mai ciudata fata de ce suntem obisnuiti. Chiar daca executia nu o sa fie un success, exista sansa ca ideea in sine sa aiba potential si sa fie baza unui nou protocol/standard ce o sa fie rafinat si implementat cu timpul si as fi mandru sa stiu ca un roman a contribuit la asta.
Oare cum au fost percepute OAuth sau OpenID acum multi ani cand erau erau doar niste idei ? Poate erau combatute cu aceeasi inversunare. Ce sa mai zic de U2F sau de FIDO2 care incepe sa fie folosit ptr autentificarea passwordless si probabil in cativa ani o sa fie norma fiind suportat de majoritatea browserelor moderne.
Eu lucrez in cadrul unui proiect bazat pe IdentityServer 4, care pe langa altele face ce fac Auth0 sau Okta sau oricare IdentityProvider public, dar in cadru unei companii private ce asigura autentificarea si autorizarea pentru aproximativ 2 milioane de utilizatori.
E un domeniu unde se inoveaza foarte greu si orice idee e bine venita.
Cand ai ceva concret (chiar si un MVP buggy) daca doresti sa iti validezi ideea, poti sa imi lasi un mesaj privat cu detalii de contact si continuam de acolo.
In cazul tau (reverse) chiar daca serverul iti trimite un cod si il retrimiti (confirmi) dintr-un client de mail nu dovedeste clar ca tu esti cel care trimite codul pentru ca o interceptare a mesajului tau poate fi replicata avand date de identificare in continut si nu deductibile din contextul comunicatiei.
Inteleg ce spui, crede-ma ca am stat mult timp sa ma gandesc daca se poate face safe treaba asta. Si e posibil sa fie, doar ca nu imi dau eu seama.
Ideea e in felul urmator, acel cod pe care il trimite userul nu este folosit ca sa se verifice autenticitatea.
Implementarea sistemului e cam asa:
website-ul face un request sa i se genereze un cod
userul apasa pe mailto: links si deschide app de mail
website-ul deschide un websocket catre server folosind acel cod ca sa intre intr-un room de socket.io
back end ul primeste mailul de la user, genereaza un token (jwt) si il trimite prin websocket pe room-ul cu numarul acelui cod.
Deci codul este folosit doar ca legatura pentru websocket sa stie serverul catre cine sa trimita.
Autenticitatea este verificata din primirea emailului. Am stabilit ca DKIM ne garanteaza cel putin ca domeniul e bun :).
LE: Nu te supara, nu e troll, nu vreau sa iti contest idea dar cel putin partea asta nu pare safe 100% sa o folosesti in productie. Poate ma insel dar cel putin asa vad lucrurile in acest context de care spui…
Nu ma supar, chiar ai niste comentarii bine venite. Sistemul este momentan la stadiul de prototip, inca nu cred ca am descoperit toate problemele. Poate se va dovedi ca nu este o varianta fezabila pana la urma (dpdv al securitatii, UX etc). Momentan explorez cu diferite implementari in directia asta si caut sa adun cat mai mult feedback si pareri contra :))
So far acest thread mi-a dat de gandit destul de mult despre implementare.
Mai ai o eroare în flow: email-ul NU este un protocol în timp real. Poate dura până la câteva zile ca un email să ajungă dintr-o parte în alta, în funcție de mai mulți factori (e.g. trimite un mail la o adresă inexistentă, vezi în cât timp primești failed delivery).
E o idee buna, cu o singura exceptie:
Poate tu nu vrei sa te loghezi cu email-ul personal pe calculatorul de firma sau invers. Mie imi place login-ul cu QR code de exemplu care e ceva similar.
Daca exista OAuth, de ce sa nu-l folosesti ? Un email e destul de scump, vine cineva cu intentii mai putin bune si iti pune serverul de email pe butuci destul de usor. Un server de email bine configurat care scaleaza te arde la buzunar.
Mie cel mai dubios mi se pare ideea de a lua de bun ce zice în MAIL FROM. Sistemul de autentificare imaginat de colegul nostru are prea multă încredere că senderul chiar este cine spune că este.
Din moment ce RFC-urile care reglementeaza protocoalele folosite de sistemele de email permit să pui orice in MAIL FROM (inclusiv <>, adică nimic), nu văd cum te-ai putea baza pe aşa ceva, mai ales într-un domeniu atât de sensibil.
Dacă era atât de simplu, nu se mai obosea lumea cu PGP, cu semnarea mesajelor etc.
Poate verifica serverul de email, dar intradevar cu un mail custom nu garanteaza nimeni ca este cine spune. Oricum daca ai access la domeniu poti sa faci forward la mail-urile de la toate adresele pe una singura si ceri reset password. Pe gmail/outlook/yahoo e putin probabil.
Eu am testat ceea ce este pe pagina de prezentare si am observat ca nu putut sa folosesc acel magic link. Nu am primit mail-ul(am verficat inclusv in spam)
Dimineata a fost nevoie sa dau cateva mail-uri ca sa pot intra in acel dashboard.
Cateva idei pe viitor din partea mea.
SDK-uri, biblioteci pt limbaje(PHP, Java .NET, Javascript, Python, Go etc), framework-uri web. Asta poate mai tarziu
Documentatie publica cu ideea de baza plus conceptele tehnice. Este un site mai mult de prezentare, iar singurul lucru mai tehnic ca sa zic asa este in acel dashboard. Ca sa zic asa, este mai multa documenatie pe forum.
Poate o aplicatie de demo.
Vad ca ai niste link-uri de Facebook, Twitter, Github. Nu ca ar fi estentiale in momentul de fata, dar cred ca pe viitor ar fi bine sa functioneze. Pentru dezvoltatori cel de Github ar fi tentant.
Parerea mea cel putin.
Te incurajez sa continui cu ideea si sa o perfectionezi. Cum a zis si @razvanp.
În plus, îl avem pe cel care administrează serverul de email, care poate trimite în numele oricui vrea el.
O rezolvare ar fi să-l obligi pe cel care se înroleaza în acest sistem să-şi semneze cumva digital mesajele (PGP sau certificat digital, ceva care să dovedească fără putinţă de tăgadă că este cel care se pretinde).
Mie imi place mecanismul existent chiar aici pe forum: la autentificare am optiunea with email care imi trimite un magic link pe adresa din formular.
E posibil sa ma insel, dar mi se pare ceva mai sigura decat trimiterea unui mail de pe contul meu catre server.
Ai dreptate, viteza de trimitere a emailului este o problema. Dar la fel este si pentru alte sisteme. De ex cand iti faci cont pe un site, primesti un email sa iti validezi adresa. La fel si la magic links, poate dura putin pana primesti linkul pe mail. Asa ca nu mi se pare o problema specifica acestui sistem.
Intr-adevar, problema cu logat pe un alt device este reala si trebuie sa o rezolv. Apropo de QR code, chiar ma gandisem fix la ceva de genul. Adica sa ti se afiseze un QR code care contine linkul de mailto: si dupa ce il scanezi sa ti se deschida aplicatia de mail. Desi ma indoiesc ca poate functiona asa :)), dar merita incercat. Cred ca in acest caz, to faci fallback sa primesti un magic link
Poate intelegem diferit ce inseamna OAuth. Asta presupune sa iti delegi autentificarea catre un alt sistem, gen facebook. Solutia mea presupune sa te loghezi folosind mailul tau, nu cu contul de pe un alt site. Iar in legatura cu serverul, foloses AWS SES, e ieftin si se ocupa ei de scalare.
Cred ca privesti problema putin diferit. Cred ca e irelevant daca tu ai un server de mail si reusesti sa iti faci 2 conturi folosind adrese diferite. Asta pentru ca iti permite serverul sa setezi adresa de FROM. Solutiile comerciale nu te lasa sa faci asta. Iar eu mizez pe useri de gmail, outlook, yahoo in principiu. restul intra la exceptii.
Exact.
Optiunea de magic link inca nu merge in pagina de login. Doar flow-ul reverse deocamdata.
Mersi pentru feedback, dar site-ul este in constructie. Nu e aproape nimic gata, e doar un proof of concept cu care am vrut sa adun feedback.
Ideea e sa se simplifice procesul de sign in, nu sa fie mai complicat. Incearca sa ii explici unui user non-tehnic cum sa foloseasca un PGP key. Caci lor li se va adresa solutia. Gen, gandeste-te la vecinul tau de bloc care e mecanic si vrea sa isi comande ceva de pe net si il pune site-ul sa isi faca un cont. I-ar fi mult mai usor gen click login, click send, account is ready.
Stiu, este unul din riscurile pe care mi le asum, ca va fi prea dubios de folosit si nu va prinde.
Ideea este inspirata din Sign in with Apple. Mi se pare absolut geniala chestia asta, iar UX-ul este perfect. Ai acel buton de sign in, il apesi, se incarca putin si gata, you’re in. Am folosit asta pe Apple Watch, unde varianta sa iti scrii emailul si parola ar fi chin.
Iar pana acum, din ce am testat, merge ok ish. Pe IOS si Android poti trimite acel mail cu 2 clickuri. Pe windows (daca ai app de mail) iar e super simplu si pe MacOS (unde banuiesc ca procentul celor care folosesc aplicatia nativa de mail e mai mare) e la fel, se deschide un pop-up, dai send si se inchide singur.
Sigur, sunt multe gauri de rezolvat, dar sper sa ajung la ceva functional. Daca e un improvement pt 60-70% din cazuri, e good enough :).
Cand am scris descrierea site-ului “Not the paswordless system we deserve, but the one we need right now”, fix FIDO2 aveam in minte. Adica ce propun eu nu e ce trebuie, dar pana avem o solutie buna, avem nevoie de asta :)).
În toată discuția asta de passwordless flux-ul cu magic link trimis pe email are cel mai mult sens. Să inversezi procesul ăsta nu prea are sens.
Slack mi se pare că cea mai bună abordare aici - îi dau pe ei exemplu doar pentru că sunt foarte cunoscuți. Ai opțiune cand te autentifici prin magic link pe mail sau poti sa folosești autentificarea clasică cu username/email și parolă.
Motivul pentru care ei oferă ambele variante este tocmai pentru că așa cum au zis deja ceilalți trimiterea unui email este best effort - faptul ca noi primim astazi aproape instant un email nu înseamnă că asta se întamplă mereu, pentru toată lumea. Iar faptul că tu vrei sa te adresezi doar celor care folosesc Gmail sau alt furnizor mare de servicii de genul ăsta nu e te scapă de problemă, pentru că și ei au cateodata probleme. Și atunci ai nevoie de o metodă de autentificare alternativă.
Acceași problemă o au și sistemele care folosesc SMS-uri pentru 2FA/MFA. Acolo unde am de ales folosesc o aplicație, nu mă bazez pe SMS.
De ce nu are sens? Eu asta incerc sa demonstrez aici, ca ARE sens.
Da, momentan solutiile passwordless sunt complementare celei clasice, nu o inlocuiesc.
Iti dau un exemplu. La ING cand faci un transfer din homebank mai mare de o anumita suma, iti trimite de fiecare data un cod prin SMS sa confirmi tranzactia. E o solutie good enough.
Cat despre aplicatiile de autentificare (gen Google Authenticator), incercati sa iesiti putin din bula voastra. Si eu folosesc asta, dar noi facem parte dintr-o categorie mai tech savvy, nu poti sa le ceri userilor obisnuiti de aplicatii sa instaleze si sa foloseasca asa ceva. Not gonna happen.
