DIY Auth. sans mot de passe

Prépa démo :

Delete le container docker pcrops-db
Recréer le container
Re-créer le schéma (npx prisma migrate deploy)
Préparer le client mail (ouvrir protonmail ou mailhog)
Si mailhog : changer les variables d'env

Contexte

Stack technique

Application React avec Server-Side Rendering
Framework : Remix
BDD : Postgres (avec prisma)
C'est tout

Démo (déjà !)

Sauf login/register
attirer l'attention sur le fait qu'on peut utiliser l'application sans s'enregistrer -> Il y a une session utilisateur "anonyme" pour presque tout le monde

Authentification sans mot de passe : pourquoi ? Comment ?

Défauts du mot de passe

Pour l'utilisateur (mémoriser, règles de "sécurité", perte...)
Pour le développeur (Responsabilité des mots de passe)

Première solution : OAuth / Social Log-in

Questions sur la vie privée, toujours plusieurs comptes
Complexité
Vendor lock-in

Seconde solution : Externaliser

Pas toujours plus simple
Payant à partir d'une certaine échelle
Pas vraiment de changement pour l'utilisateur

Tous les problèmes viennent du mot de passe

Déléguons le problème

Tout le monde a un compte mail et y est déjà connecté
le fournisseur de mail gère le mot de passe
Beaucoup plus simple que OAuth

Ceux qui doutent de la simplicité de la solution, c'est pour ça que je suis là

Comment ça marche ?

* Au lieu de renseigner login/mdp, on renseigne uniquement une adresse mail * à la validation du formulaire, on reçoit un mail * Le clic sur le lien contenu dans le mail nous renvoie sur l'application, mais connecté cette fois (avec un ID de session stocké dans un cookie)

Le principe du mot de passe c'est que seul l'utilisateur "légitime" le connait
Le secret généré côté serveur est un peu comme un mot de passe à usage unique. Pour s'assurer que seul l'utilisateur le connait, on lui envoie par email
L'hypothèse importante est que seul l'utilisateur a accès à ses mails.

Fonctionnement détaillé côté serveur

Génération du secret

⚙️ JWT ⚙️

token-encoded

* La génération du secret n'a rien de compliqué : on utilise JWT. C'est une manière robuste et standard pour stockée de la donnée dans un token signé * Note : dans mon cas spécifique il y a trois cas, mais dans la plupart des cas il y en a deux (login et register). On peut même se passer du champ type dans ce cas * J'ai fait le choix de ne pas aller en base à ce stade : cette étape n'échoue jamais, c'est à la vérification du token qu'on ira regarder en base. Il peut être plus judicieux de vérifier ici si l'utilisateur existe en cas de login, et si l'adresse est bien inutilisée en cas de register.

Penser à proposer un rappel sur JWT

Vérification du token

Décoder le token et le vérifier grace au secret avec lequel on a signé le JWT
Vérifier et agir selon le cas :
1. type=login : Login classique
2. type=register et sub=null : on veut créer un utilisateur
3. type=register et sub!=null : on veut associer un email à un utilisateur existant

* la première étape ici est celle qui assure la majeure partie de la sécurité. Il n'est pas possible de falsifier un token et donc il faut forcément avoir accès au compte mail pour avoir un token valide qui contient le mail en question

Cas 1 : Login

Utilisateur inexistant : échec ❌ (Mais on peut lui proposer de s'enregistrer)
Utilisateur trouvé en base : login success ✅ (On crée sa session et on stocke l'id de session dans un cookie.)

* C'est ici que mon choix est douteux. Si le mail ne correspond pas à un utilisateur, la personne a perdu du temps (mais on a l'opportunité de lui proposer de s'enregistrer)

Cas 2 : register d'un nouvel utilisateur

L'email est déjà utilisé : échec ❌ (Mais on peut lui proposer de se connecter)
L'email est libre : on peut créer l'utilisateur ✅ (On crée aussi sa session et on stocke l'id de session dans un cookie.)

Encore une fois on pourrait vérifier que le mail est libre avant d'envoyer le mail. Attention par contre à ne pas donner l'info directement si le mail est pris ou non (sinon on divulgue le fait qu'une personne a un compte sur le site. ça peut être un problème sur un site de rencontre adultère)

Mais on pourrait transformer le lien de register en lien de login dans le mail directement

Cas 3 : register d'un utilisateur existant

L'email est déjà utilisé : échec ❌ (Mais on peut lui proposer de se connecter)
L'email est libre : on peut associer le mail à l'utilisateur dont l'id est présent dans le token ✅ (Puis on crée sa session, finalement tous les cas sont un cas de login)

Démo / Code

Démo login / register
code :
- plan/crops.tsx pour parler rapidement de l'anatomie d'une route remix
- Formulaire de login/register et son utilisation dans la route (login.tsx / register.tsx)
  - l'absence de hook
  - l'absence d'attribut "action" (car on utilise l'action de la route courante)
- Action (login.tsx/register.tsx). Expliquer le principe des actions en remix.
- Génération du token et envoi de l'email : rien de spécial, on utilise les library jwt et nodemailer. Mentionner l'intérêt d'avoir un backend.
- loader de la route de vérification (magic.$token.tsx)
  - Montrer les paramètres en remix
  - Déroulé : vérif avec jwt puis code custom pour le métier

Aller plus loin

Variantes

Au lieu du mail on peut imaginer plusieurs choses

SMS
Message teams
Push sur téléphone

On peut imaginer une réponse au lieu du clic sur un lien (attention à la sécurité)

Falsifier l'expéditeur d'un mail est un peu plus facile. Il faut aussi inclure un secret dans le mail.

Si on veut éviter l'utilisation d'un secret, le processus devient stateful.

Améliorations

Avec du polling ou des websocket, on peut rafraichir la session sur la page ou on est après avoir entré son email

Avantage : on peut ouvrir son mail sur un autre device
Complique le processus qui ne peut plus être stateless

Si on combine les deux...

teams-example

Merci !

DIY Auth. sans mot de passe