Mais, mais, mais l'autorité est HaaRrRrRrRrRd

Non, ce n'est pas le cas. C'est ennuyeux, bureaucratique, un problème résolu... mais ne dites pas que c'est difficile.

J'ai "j'ai utilisé MD5 pour hacher des mots de passe en PHP" il y a des années. Bien sûr, c'était une idée horrible, même en 2012. Mais, à l'époque, je ne me souviens pas avoir considéré l'authentification comme "difficile". C'était une épreuve assez simple en soi - obtenir une adresse e-mail ou un nom d'utilisateur, obtenir un mot de passe, le hacher (avec MD5, comme "Dieu l'a voulu"), et si vous étiez particulièrement soucieux de la sécurité, [ saler ] le mot de passe. Stockez tout cela quelque part, généralement dans une base de données. Et voilà, inscription terminée.

Aujourd’hui, le discours a changé. « L’authentification est difficile » semble être un discours omniprésent qui se trouve à un clic de HackerNews ou de Reddit. Mais est-ce vraiment le cas ? À mon avis, la vérité est que l’authentification n’est pas difficile à mettre en place – tout le monde peut l’apprendre (et tout le monde dans ce domaine devrait en apprendre les bases). Le véritable défi réside dans les extras : MFA, gestion des utilisateurs, réinitialisations de mot de passe, chacun des centaines de fournisseurs OAuth et fusions de comptes de différents fournisseurs. C’est la mort à petit feu. Puisque l’authentification est un problème résolu, réinventer la roue n’est pas la meilleure utilisation de votre temps. Mais cela ne signifie pas que « l’authentification est difficile » en tant qu’affirmation générale est correcte ou même proche de l’être. Vous devez expérimenter, comprendre les bases et construire à partir de là. La complexité ne fait qu’augmenter avec l’échelle (ou l’échelle potentielle) de ce que vous créez.

Alors, à quel point l'authentification peut-elle être difficile ? Creusons un peu le sujet.

Autrefois...

Pour reprendre là où j'ai laissé l'histoire de PHP et md5, la création d'une fonctionnalité de connexion a suivi une série d'étapes similaires : obtenez un e-mail et un mot de passe, vérifiez l'existence de l'e-mail dans votre stockage, hachez le mot de passe avec le sel stocké pour cet e-mail, comparez le hachage résultant avec celui stocké dans la base de données, et si tout fonctionne bien, définissez un cookie via setcookie (nous sommes toujours au pays de PHP ici - non pas que la logique globale soit trop différente dans d'autres écosystèmes).

La déconnexion était encore plus simple : il suffisait d'invalider le cookie sur le serveur et c'était terminé. Si le serveur ne voit pas de cookie lors de la prochaine requête, vous n'êtes pas connecté. Par conséquent, l'exécution d'itinéraires authentifiés était également une épreuve simple dans l'ensemble. Les choses pouvaient devenir compliquées en ce qui concerne les autorisations, mais le plus souvent, avec les applications que j'ai dû créer, nous n'avions que des administrateurs et des utilisateurs. C'était quelque chose que vous pouviez simplement stocker avec l'enregistrement de l'utilisateur ou dans une table d'autorisations si jamais vous aviez besoin d'étendre le nombre de rôles que vous aviez pour votre application.

Divulgation complète : je travaille pour SuperTokens . Cet article est toutefois né d'une frustration personnelle face à un discours omniprésent sur la façon dont l'authentification stricte est une déclaration générale. En d'autres termes, je n'essaie pas de « vous vendre mon truc ». Utilisez ce que vous voulez.

Roulez vous-même – une version « moderne »

E-mail/mot de passe et authentification sociale

Pour en arriver là où nous en sommes aujourd'hui, nous allons commencer par le commencement... Étonnant, je sais. Nous pouvons probablement convenir que ces composants sont suffisants pour réaliser un PoC email/mot de passe + connexion sociale :

1. Un serveur qui gère les itinéraires - inscription, connexion, déconnexion...
2. Une sorte de stockage pour conserver les enregistrements des utilisateurs (un tableau en mémoire fonctionne également)
3. Vues - écrans de connexion, d'inscription et de « tableau de bord » authentifié.
4. Gestionnaires pour l'autorité sociale

En utilisant Express et Passport, comme nous n'allons pas réinventer la roue, nous arrivons exactement à 150 lignes de code très, très ennuyeux et répétitif : https://github.com/supertokens/auth-express/blob/master/index.mjs . La section suivante sera une explication superficielle de ce qui se passe dans le code, alors n'hésitez pas à passer à la section suivante si vous connaissez déjà les concepts. L'application express est de toute façon un PoC.

Décortiquons-le rapidement :

Rendu des éléments à l'écran

À mon avis, il y a deux façons d'aborder ce problème : commencer par le rendu et passer à la voie d'authentification ou l'inverse. C'est surtout par hasard que je me suis retrouvé à être un fervent adepte de FE (je peux toujours faire du SQL, au cas où vous vous poseriez la question), donc je vais commencer par l'approche « rendu des éléments à l'écran ».

Comme il s'agit d'un PoC, nous n'allons pas nous lancer dans un React fantaisiste. Un simple SSR avec ejs fera très bien l'affaire : https://github.com/supertokens/auth-express/tree/master/views

Ajout d'itinéraires

Sur la base de quelques exemples de passport.js , mais simplifiés davantage, nous avons besoin des éléments suivants :

1. Quelques dépendances : npm i passport passport-local express-session . Passons brièvement en revue chacun d'eux :

   1. Passport.js - le middleware d'authentification OG pour Express et Node.
   2. passport-local - une stratégie d'authentification pour Passport ; Une stratégie d'authentification dans un module qui gère le processus d'authentification pour une méthode d'authentification spécifique - dans ce cas, une connexion locale utilisant un nom d'utilisateur (e-mail) et un mot de passe.
   3. express-session - un middleware qui gère les données de session, vous permettant de stocker et de conserver les sessions utilisateur entre les requêtes HTTP. Il fonctionne en attribuant un identifiant de session unique à chaque client, qui est stocké dans un cookie côté client et utilisé pour récupérer les données de session sur le serveur.

2. Un endroit pour stocker nos utilisateurs (l'exemple lié ci-dessus utilise un tableau en mémoire) : https://github.com/supertokens/auth-express/blob/master/index.mjs#L13

3. Configuration de notre instance de passeport et de notre instance LocalStrategy pour gérer les requêtes entrantes pour la recherche d'utilisateurs : https://github.com/supertokens/auth-express/blob/master/index.mjs#L18

4. Initialisez le passeport ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) et express-session ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L69 ).

Verbeux, bien sûr. Difficile ? Je ne pense pas, du moins pas dans le sens où on pourrait l'implémenter comme un jouet. Mais nous avons dépassé depuis quelque temps l'utilisation des combinaisons e-mail/mot de passe. Voyons à quel point il est difficile d'ajouter un fournisseur social en plus de ce que nous avons.

Pour un exemple de fournisseur ici, j'ai décidé d'utiliser GitHub pour une raison simple : si vous décidez de suivre pleinement, c'est l'un des fournisseurs les plus faciles à utiliser (je vous regarde, Google).

Si vous décidez de suivre cette procédure dans son intégralité, voici un lien décrivant comment obtenir ces clés GitHub : https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app Oh, et au fait, celles du dépôt ne sont pas valides, au cas où vous vous inquiéteriez ;)

Intégration de GitHub OAuth2 dans notre PoC

Tout d'abord, nous avons besoin d'une dépendance supplémentaire, npm i passport-github2 . passport-github2 est une stratégie d'authentification pour Passport, nous permettant de nous intégrer à l'API OAuth2 de GitHub.

Quelques gestionnaires ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) et configurations ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45 ) plus tard, eh bien, c'est tout. Compliqué ? Probablement pas. De la paperasserie ? Vous pariez. Ennuyeux ? Absolument. Surtout si vous devez le faire encore et encore. C'est un problème résolu ; réinventer la roue n'est souvent pas la meilleure utilisation de son temps, comme nous l'avons établi.

La grande idée

À présent, nous pouvons probablement convenir qu'Auth n'est pas difficile à construire . Par conséquent, ce n'est pas cette chose magique que seuls les sorciers à barbe blanche qui parlent le langage mystique des JWT peuvent comprendre et mettre en œuvre.

Non, en fait, je dirais qu'en tant que développeur, il faut comprendre les bases du fonctionnement de l'authentification. Et je vois souvent un discours qui prétend le contraire, quelque chose du genre : « Fais-moi confiance, mon frère, nous pouvons nous en occuper pour toi ». Et bien sûr, je suis d'accord pour dire que, dans la plupart des cas, créer sa propre authentification est une perte de temps. Mais ce n'est pas si difficile à mettre en place, et ce n'est certainement pas une chose mystique. Là où cela devient vraiment compliqué, c'est avec tout ce qui entoure l'authentification et l'expérience utilisateur.

Considérez ceci : dans l'exemple ci-dessus, nous avons une fonction d'authentification qui fonctionne. En quelque sorte. Mais voici ce qu'elle ne peut pas faire (également mentionné dans l'ouverture de l'article) :

• 2FA, MFA
• Réinitialisations de mot de passe
• Chacun des centaines de services OAuth avec sa spécificité
• Gestion des utilisateurs
• Fusion de comptes de différents fournisseurs
• Couvrez tous les cas limites possibles et les failles de sécurité potentielles
• ...et je peux continuer

Nous pouvons probablement mettre en œuvre chacun de ces éléments. Et pris séparément, chaque élément peut être considéré comme simple. Mais tout s'additionne. Donc, ce n'est pas nécessairement la mise en œuvre, c'est la maintenance, la responsabilité, le respect des normes, les failles de sécurité, etc. De plus, un vote à main levée : combien d'entre vous aiment lire les RfC ? Je ne pense pas que je verrais beaucoup de mains levées si nous étions en réunion.

Ce que je veux dire, c'est que l'authentification n'est pas simple, dans son ensemble. Bien sûr, nous pouvons facilement bricoler quelque chose pour un PoC, comme nous l'avons fait ci-dessus. Mais ce n'est pas magique, ce n'est pas impossible à comprendre, et s'il vous plaît, ne dites pas que c'est le cas. Cette ligne de pensée (et de marketing), à mon avis, est préjudiciable à l'industrie dans son ensemble.

Alors, la question qui se pose naturellement est : quand devriez-vous créer votre propre compte ?

Projet de jouet, indépendant et activités éducatives

...par tous les moyens. Je l'encouragerais même. On apprend beaucoup en faisant, alors pourquoi pas ? Si votre projet ou blog indépendant/jouet grandit et a une base d'utilisateurs ou de followers considérable, passez à un service, une solution auto-hébergée ou autre chose. Après tout, vous avez un produit à ce stade, et votre temps sera sans aucun doute mieux utilisé à construire ce produit plutôt qu'à maintenir l'authenticité.

Les startups

En règle générale, si vous créez des produits, ne créez pas votre propre système d'authentification. Cela revient à réinventer une roue très ennuyeuse et bureaucratique. Vous avez le choix entre de nombreuses options. De plus, vous créez quelque chose, n'est-ce pas ? Pourquoi avons-nous cette conversation si votre produit n'est pas authentifié ?

Scaleups et plus (quelle que soit la manière dont nous choisissons de les définir)

Ne le faites pas. Même raison que pour les startups, mais cela s'applique certainement davantage ici.

Vous voyez probablement où je veux en venir. « L’authentification est difficile » est, je dirais, un argument marketing utilisé comme une déclaration générale. Vous pouvez comprendre l’authentification, vous pouvez la construire, mais c’est ennuyeux, ce n’est pas amusant à maintenir et c’est un problème qui est résolu. Ainsi, on peut la considérer comme un produit de base, que vous pouvez choisir dans le commerce dans la version de votre choix (quelques options ci-dessous).

Le paysage auto-hébergé et FOSS

Pour ceux qui aiment posséder leur propre pile (comme c'est le cas pour vous), vous avez également de nombreuses options parmi lesquelles choisir :

Bibliothèques d'authentification

• Passport.js, abordé ci-dessus en détail
• Lucia - Une bibliothèque d'authentification simple et flexible pour les applications Web modernes, axée sur l'expérience du développeur et la facilité d'utilisation.
• Auth.js - Une bibliothèque d'authentification légère et personnalisable pour Node.js, conçue pour être facilement intégrée dans divers frameworks et applications. A commencé comme une bibliothèque pour Next.

Serveurs d'authentification

• Keycloak - Un serveur de gestion des identités et des accès open source offrant des fonctionnalités telles que l'authentification unique (SSO), le courtage d'identité et la fédération d'utilisateurs.
• SuperTokens (voir clause de non-responsabilité ci-dessus) - Une solution d'authentification open source offrant des fonctionnalités prédéfinies telles que la gestion de session, la connexion sociale et l'authentification par e-mail/mot de passe en mettant l'accent sur la sécurité et la simplicité.
• FusionAuth - Une plate-forme d'authentification flexible destinée aux développeurs, offrant des fonctionnalités telles que la gestion des utilisateurs, l'authentification multifacteur (MFA) et l'authentification unique (SSO).
• Authelia - Un serveur d'authentification open source fournissant une authentification multifacteur (MFA) et SSO, conçu pour sécuriser les applications à l'aide de proxys inverses.

Stockage + Authentification

• Supabase - Une plate-forme backend-as-a-service (BaaS) open source fournissant des capacités de base de données, d'authentification et de temps réel, conçue comme une alternative à Firebase.
• Pocketbase - Une solution backend open source combinant base de données, authentification et stockage de fichiers, visant à simplifier le développement d'applications Web et mobiles modernes.

Ainsi, même si vous n'êtes pas intéressé par l'utilisation de logiciels tiers pour l'authentification, vous pouvez simplement en choisir un open source disponible dans le commerce, en fonction de vos besoins et de vos préférences, et vous en servir.

À retenir : l'authentification est la « paperasserie » du développement

Mon « grand » message à retenir est qu’il faut éviter de réinventer la roue, surtout s’il s’agit d’un problème résolu, comme c’est le cas de l’authentification. Informez-vous sur ces roues, expérimentez-les, construisez une roue jouet et comprenez-la. Mais s’il vous plaît, s’il vous plaît, ne la vendez pas comme quelque chose d’incroyablement difficile à comprendre et à construire. Éduquez, ne contrôlez pas.