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   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é, [   ] le mot de passe. Stockez tout cela quelque part, généralement dans une base de données. Et voilà, inscription terminée. 2012. saler  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   (nous sommes toujours au pays de PHP ici - non pas que la logique globale soit trop différente dans d'autres écosystèmes). setcookie  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   . 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. SuperTokens  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 :  Un serveur qui gère les itinéraires - inscription, connexion, déconnexion...  Une sorte de stockage pour conserver les enregistrements des utilisateurs (un tableau en mémoire fonctionne également)  Vues - écrans de connexion, d'inscription et de « tableau de bord » authentifié.  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 :   . La section suivante sera une explication superficielle de ce qui se passe dans le code, alors n'hésitez pas à   si vous connaissez déjà les concepts. L'application express est de toute façon un PoC. https://github.com/supertokens/auth-express/blob/master/index.mjs passer à la section suivante  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   fera très bien l'affaire :  ejs https://github.com/supertokens/auth-express/tree/master/views  Ajout d'itinéraires  Sur la base de quelques exemples   , mais simplifiés davantage, nous avons besoin des éléments suivants : de passport.js  Quelques dépendances :   . Passons brièvement en revue chacun d'eux : npm i passport passport-local express-session    - le middleware d'authentification OG pour Express et Node. Passport.js    - 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. passport-local    - 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. express-session  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  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  Initialisez le passeport (   ) et express-session (   ). https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 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 :   Oh, et au fait, celles du dépôt ne sont pas valides, au cas où vous vous inquiéteriez ;) https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app  Intégration de GitHub OAuth2 dans notre PoC  Tout d'abord, nous avons besoin d'une dépendance supplémentaire,   .   est une stratégie d'authentification pour Passport, nous permettant de nous intégrer à l'API OAuth2 de GitHub. npm i passport-github2 passport-github2  Quelques gestionnaires (   ) et configurations (   ) 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.  https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45  La grande idée  À présent, nous pouvons probablement convenir qu'Auth n'est pas difficile à   . 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. construire  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    - 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. Lucia    - 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. Auth.js   Serveurs d'authentification    - 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. Keycloak    (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é. SuperTokens    - 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). FusionAuth    - 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. Authelia   Stockage + Authentification    - 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. Supabase    - 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. Pocketbase  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.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Mais, mais, mais l'autorité est HaaRrRrRrRrRd

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Le guide complet pour réussir une migration vers le cloud : stratégies et bonnes pratiques

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps