Sådan oprettes magiske links til Node

Det kodeordløse system introduceret af Slack som et magisk link er et rigtig godt alternativ til det grundlæggende e-mail / adgangskodegodkendelsessystem af mange grunde. Selv hvis du ikke kontrollerer sikkerhedsniveauet for adgangskodekryptering, overvejer du, at din brugerpostkasseudbyder er sikker nok, og at det faktum, at de giver dig et symbol, som du lige har sendt dem, er måde nok til at autentificere dem. På denne måde kan vi se dette som en billig OAuth-godkendelse (som Facebook), der ikke giver os nogen oplysninger om brugeren.

forskel mellem oAuth og magisk link

Hvad med implementeringen?

Med det forrige skema ved vi, at vi kun bliver nødt til at implementere 2 slutpunkter. Én til at indsende en anmodning om en godkendelsesnøgle og en om at blive godkendt.

I godkendelsesendepunktet har vi brug for 3 ting. Adgangen til vores database til at fortsætte kontoen, genereringen af ​​token og genereringen af ​​mailen. For at generere token bruger vi en JSON Web Token-tilgang. Fordelen er, at vi kan integrere noget indhold i token og være sikker på, at det ikke er ændret.

Vi genererer nu et link, der indeholder tokenet i forespørgslen og sender det link til vores bruger pr. Mail.

Når vores bruger skal klikke på det link, er vi nødt til at opfange det token, der sendes som en forespørgselseparameter, afkode indholdet og sætte det i sammenhæng med anmodningen. Til dette formål er vi bare nødt til at bruge en ekspress mellemvare kaldet express-jwt.

Når brugeren klikker på linket, har vi hans oplysninger i konteksten, og vi kan bare bruge dem.

Og her er vores livscyklus afsluttet. Vores brugere kan nu kun autentificere ved hjælp af deres e-mail-adresse.

Hvad med sikkerheden?

Først må vi tage hensyn til, at vores brugers postkasse kan blive kompromitteret. Hvis nogen anden opfanger e-mailen, der indeholder tokenet, kan de have adgang til hans konto i vores tokenes levetid. Der er flere muligheder for at løse dette.

Den første ville være at have en sortlistetabel til det token, vi vil annullere. Ganske irriterende og imod princippet om at fremstille JWT-symboler.

Så hvad med at sætte et revisionsindeks i det token, som vi ville gemme i databasen? På den måde er det kun symbolet med den sidste revision, der kunne logge ind. Med den løsning mister vi også princippet om JWT, fordi vi skal kigge i databasen, hver gang en bruger fremsætter en anmodning.

Den bedste løsning kan være at gøre, at tokenet, vi sender med mail, har en rigtig kort levetid, som 1 time, og på den første anmodning, som brugeren fremsætter til serveren, genererer vi et nyt token med en længere levetid.

En anden stærk løsning ville være at opdele tokenet i to stykker. Send det første stykke pr. Mail til brugeren og giv det andet stykke tilbage til applikationen som svar på anmodningen. På den måde er det kun denne mobil eller browser, der er i stand til at genopbygge token og blive godkendt.

Et eksempel ville være rart!

Kildekoden til et kørende eksempel er tilgængeligt på følgende link.

Er du interesseret i at indgive en ansøgning?