Devez-vous créer votre propre auth pour les applications ?

Contexte#

J'ai vu beaucoup de développeurs poser des questions comme "Dois-je créer ma propre auth pour mon application ?". Bien que la réponse e puisse être un simple "Oui" ou "Non", j'aimerais écrire un article pour décomposer la mise en œuvre et démontrer les avantages et les inconvénients pour vous aider à décider.

TL;DR Il est écessaire de trouver une solution existante qui répond à vos besoins, à moins que vous e souhaitiez vraiment un contrôle total ou que vous soyez encore en train d'apprendre le développement logiciel.

Introduction#

En tant que développeur, j'ai construit de ombreuses applications au cours de ma carrière. Quel que soit le langage de programmation, il y a une fondation commune que je dois toujours construire : l'authentification de l'utilisateur.

C'était une partie égligeable car tout était simple il y a 20 ans :

• Mettre en œuvre un système d'inscription et de connexion avec un om d'utilisateur et un mot de passe.
• Créer un mécanisme pour maintenir la session d'un utilisateur.
• La sécurité ? MD5 est la réponse.

C'est tout. Ensuite, je pouvais me concentrer sur "le vrai business". Vous 'avez pas entendu parler de MD5 ? Vous avez raté les "bons moments" du développement de logiciels. Aujourd'hui, les développeurs sont confrontés à plus de défis lors de la création d'une inscription/connexion.

Cela peut paraître alarmiste, mais laissez-moi expliquer avec un exemple.

Exemple : Une librairie en ligne#

Supposons que vous essayez de construire une librairie en ligne avec un service API et une application web frontend.

Tout d'abord, la portée de l'"auth" doit être définie. L'auth peut être expliquée comme l'authentification et l'autorisation, et elles ont des définitions et des cas d'utilisation totalement différents :

J'ai écrit un article CIAM 101 : Authentication, Identity, SSO pour discuter en détail de ces concepts.

Choisir les méthodes d'authentification#

Commençons par l'"authentification", qui est la connexion de l'utilisateur dans otre exemple. Outre la méthode du om d'utilisateur et du mot de passe, voici quelques méthodes tendance que les gens adoptent pour une meilleure conversion des utilisateurs et une sécurité accrue :

• Sans mot de passe, c'est-à-dire un code de vérification dynamique (par e-mail ou sms)
• Connexion sociale (Google, Facebook, etc.)

Le choix de la méthode dépend de la décision commerciale, mais ous pouvons examiner l'effort technologique :

• Pour le sans mot de passe, vous devez trouver un fournisseur pour envoyer des codes de vérification par e-mail ou sms ; puis intégrer avec votre service API (de ouvelles API peuvent être écessaires).
• Pour la connexion sociale, vous devez adhérer aux directives d'intégration du ou des fournisseurs d'identité sociale que vous souhaitez utiliser. De plus, vous devez créer une correspondance entre les ID utilisateur de votre librairie et ceux du fournisseur d'identité.
  • Par exemple, lorsqu'un utilisateur se connecte avec un compte Gmail [email protected], vous pouvez lier cette adresse e-mail à l'utilisateur foo dans la librairie. Ce processus vous aide à construire un système d'identité unifié et permet à l'utilisateur de modifier ou de dissocier son identité sociale à l'avenir.

Concevoir et mettre en œuvre l'expérience de connexion#

Après avoir décidé des méthodes d'authentification, une expérience de connexion gracieuse et fluide pour vos utilisateurs finaux est la cible suivante. La conversion ici est fondamentale mais cruciale pour l'entreprise car c'est une manière aturelle de conserver les données du client.

Lorsque je travaillais pour Airbnb, il y avait une équipe entière dédiée à l'optimisation de l'expérience de connexion sur plusieurs plateformes. Ils ont mené de ombreux tests A/B pour déterminer quelle combinaison avait le taux de conversion le plus élevé.

Il 'est pas pratique de le faire lorsque l'entreprise démarre. Mais ous devons quand même essayer de faire en sorte que chaque pièce soit correcte. Sur quelles plateformes souhaitez-vous faire fonctionner la librairie ? Vous pouvez commencer par le mobile, le web, ou les deux. Le design exact dépendra des méthodes d'authentification que vous choisissez :

• Nom d'utilisateur et mot de passe : Le plus facile, juste quelques boîtes de saisie et des boutons.
• Sans mot de passe : Entrez le téléphone / le courrier électronique, puis envoyez et vérifiez un code dynamique.
• Connexion sociale : Lisez les documents du fournisseur d'identité sociale choisi, suivez les directives visuelles, gérez la logique de redirection et liez enfin l'identité sociale à l'identité de la librairie.

D'autres choses à considérer pour améliorer :

• Avez-vous besoin de combiner le processus de connexion et d'inscription pour une méthode spécifique ?
• Avez-vous besoin d'un flux "mot de passe oublié" pour permettre aux clients de réinitialiser leurs mots de passe de manière indépendante ?

Si vous optez pour le développement atif, la charge de travail sera presque doublée pour une plateforme supplémentaire.

Sécurité et échange de jetons#

La sécurité peut être un iceberg caché. Ce sera formidable si vous êtes familier avec OpenID Connect ou OAuth 2.0, car ils sont largement utilisés et éprouvés. OpenID Connect est relativement ouveau mais est conçu pour "l'authentification de l'utilisateur", ce qui est parfait pour une librairie en ligne.

Sans entrer dans les détails des ormes, il y a encore quelques choses à considérer :

• Quelle méthode de cryptage doit être utilisée pour les mots de passe ?
• Quel est le processus pour l'authentification et l'autorisation standard ?
• Comment fonctionne l'échange de jetons (Access Token, Refresh Token, ID Token, etc.) ?
• Comment les clés de signature peuvent-elles être utilisées dans les jetons et comment la signature peut-elle être validée pour protéger les ressources ?
• Comment prévenir les attaques client et serveur ?

Enfin, vous pouvez obtenir une bonne expérience de connexion et la livrer à vos clients.

Modèle d'autorisation#

En tant que librairie, vous devez séparer les ressources pour les clients et les vendeurs. Par exemple, les clients peuvent parcourir tous les livres, tandis que les vendeurs peuvent gérer leurs livres en vente. Il est OK de commencer par des vérifications simples si-sinon ; cependant, à mesure que l'entreprise grandit, vous devrez peut-être utiliser un modèle plus flexible comme le contrôle d'accès basé sur les rôles (RBAC) ou le contrôle d'accès basé sur les attributs (ABAC).

J'ai également écrit un article CIAM 102 : Autorisation & Contrôle d'accès basé sur les rôles pour illustrer les concepts de base de l'autorisation et le modèle RBAC.

Prendre la décision#

Vous pouvez voir que l'auth 'est pas un problème de "tout ou rien", car elle implique plusieurs composants techniques et vous ou votre équipe pouvez avoir des compétences techniques différentes dans ces domaines. Il est important de la décomposer en petits morceaux pour mieux comprendre la situation actuelle.

Pour prendre la décision, je me poserais les questions suivantes :

• Quelle est l'urgence du projet ?
• Quel effort suis-je prêt à mettre dans l'auth par rapport à l'entreprise ?
• Quelle est la priorité de l'expérience utilisateur, de la sécurité et de la maintenabilité ?
• De quelle(s) partie(s) ai-je besoin de contrôle total ? Dois-je me familiariser avec elles ?
• Si je choisis certains cadres / solutions, sont-ils suffisamment bons pour la personnalisation ou l'extension ?
• Si l'entreprise se développe, devrai-je introduire un ouveau modèle d'authentification ?
• Si je trouve un fournisseur approprié, est-il assez sûr à utiliser ? Ai-je besoin d'un plan de retrait si quelque chose arrive au fournisseur ?

Avec ces questions en tête, j'ai découvert deux faits :

• Créer un système d'authentification fiable est très complexe.
• Les fournisseurs existants e peuvent pas répondre à tous les critères écessaires.

J'ai donc décidé de démarrer un projet dédié (Logto) pour l'auth, et d'embrasser la communauté open-source dès le premier jour.

J'espère que cet article vous aidera.