Choisir une m\u00e9thode d’authentification\/un fournisseur<\/h2>\n
Il y a fondamentalement 1000 fa\u00e7ons d’int\u00e9grer l’authentification dans votre application. Plut\u00f4t que de se concentrer sur des fournisseurs particuliers (le sujet d’un autre article de blog), examinons les types de solutions d’authentification<\/strong> et quelques exemples de chacune d’entre elles. En termes d’impl\u00e9mentation, next-auth<\/a> devient rapidement une option populaire pour int\u00e9grer votre application Next.js avec plusieurs fournisseurs, ajouter le SSO, etc.<\/p>\n Celle-ci est aussi simple que possible : vous stockez les noms d’utilisateur et les mots de passe dans une base de donn\u00e9es relationnelle. Lorsqu’un utilisateur s’inscrit pour la premi\u00e8re fois, vous ins\u00e9rez une nouvelle ligne dans la table \u00ab users\u00a0 avec les informations fournies. Lorsqu’il se connecte, vous v\u00e9rifiez les informations d’identification par rapport \u00e0 ce que vous avez stock\u00e9 dans la table. Lorsqu’un utilisateur souhaite modifier son mot de passe, vous mettez \u00e0 jour la valeur de la table.<\/p>\n L’authentification traditionnelle par base de donn\u00e9es est certainement le syst\u00e8me d’authentification le plus populaire si l’on consid\u00e8re l’ensemble des applications existantes, et elle existe pratiquement depuis toujours. Il est tr\u00e8s flexible, bon march\u00e9 et ne vous enferme pas dans un fournisseur particulier. Mais vous devez le construire vous-m\u00eame et, en particulier, vous pr\u00e9occuper du cryptage et vous assurer que vos mots de passe ne tombent pas entre de mauvaises mains.<\/p>\n Au cours des derni\u00e8res ann\u00e9es (et pour Firebase, il y a plus de quelques ann\u00e9es), il est devenu relativement courant pour les fournisseurs de bases de donn\u00e9es g\u00e9r\u00e9es de proposer une sorte de solution d’authentification g\u00e9r\u00e9e. Firebase<\/a>, Supabase<\/a> et AWS<\/a> proposent tous une base de donn\u00e9es g\u00e9r\u00e9e et une authentification g\u00e9r\u00e9e en tant que service via une suite d’API qui fait facilement abstraction de la cr\u00e9ation d’utilisateurs et de la gestion des sessions (nous y reviendrons plus tard).<\/p>\n Pour connecter un utilisateur avec l’authentification Supabase, rien de plus simple<\/a>:<\/p>\n L’authentification en tant que service de votre DBaaS est peut-\u00eatre encore plus courante que l’authentification en tant que service d’une entreprise ou d’un produit entier. Auth0<\/a> existe depuis 2013 (et appartient maintenant \u00e0 Okta), et des ajouts r\u00e9cents comme Stytch<\/a> ont donn\u00e9 la priorit\u00e9 \u00e0 l’exp\u00e9rience des d\u00e9veloppeurs et ont gagn\u00e9 une certaine notori\u00e9t\u00e9.<\/p>\n Le SSO vous permet d’\u00ab externaliser \u00bb votre identit\u00e9 \u00e0 un fournisseur externe, qui peut \u00eatre une entreprise, un fournisseur ax\u00e9 sur la s\u00e9curit\u00e9 comme Okta<\/a> ou quelque chose de plus largement adopt\u00e9 comme Google<\/a> ou GitHub. Le SSO de Google est omnipr\u00e9sent dans le monde du SaaS, et certains outils destin\u00e9s aux d\u00e9veloppeurs ne<\/em> s’authentifient que<\/em> via GitHub.<\/p>\n Quel que soit le ou les fournisseurs choisis, le SSO est g\u00e9n\u00e9ralement un compl\u00e9ment aux autres types d’authentification mentionn\u00e9s ci-dessus et comporte ses propres particularit\u00e9s<\/a> en mati\u00e8re d’int\u00e9gration avec des plateformes externes (attention : SAML utilise XML).<\/p>\n Il n’y a pas de \u00ab bon \u00bb choix ici – ce qui convient \u00e0 votre projet d\u00e9pend de vos priorit\u00e9s. Si vous voulez que les choses bougent rapidement sans une tonne de configuration initiale, l’externalisation de l’authentification a du sens (m\u00eame l’externalisation compl\u00e8te, interface utilisateur incluse, \u00e0 quelqu’un comme Auth0). Si vous anticipez une configuration plus complexe, construire votre propre backend d’authentification est judicieux. Et si vous envisagez de soutenir des clients plus importants, vous aurez besoin d’ajouter le SSO \u00e0 un moment donn\u00e9.<\/p>\n Next.js est tellement populaire que la plupart de ces fournisseurs d’authentification ont des documents et des guides d’int\u00e9gration sp\u00e9cifiques \u00e0 Next.js.<\/p>\n Certains fournisseurs d’authentification comme Auth0 fournissent en fait des pages web enti\u00e8res h\u00e9berg\u00e9es pour l’inscription et la connexion. Mais si vous construisez ces pages \u00e0 partir de z\u00e9ro, je trouve qu’il est utile de les cr\u00e9er t\u00f4t dans le processus car vous en aurez besoin pour fournir des redirections lorsque vous mettrez en \u0153uvre votre authentification.<\/p>\n Il est donc logique de cr\u00e9er la structure de ces pages et d’ajouter les requ\u00eates au backend apr\u00e8s coup. La fa\u00e7on la plus simple d’impl\u00e9menter l’authentification est d’avoir deux de ces routes :<\/p>\n Au-del\u00e0 des principes de base, vous devrez couvrir les cas particuliers, par exemple lorsqu’un utilisateur oublie son mot de passe. Certaines \u00e9quipes pr\u00e9f\u00e8rent que le processus de r\u00e9initialisation du mot de passe se d\u00e9roule sur une route distincte, tandis que d’autres ajoutent des \u00e9l\u00e9ments d’interface utilisateur dynamiques \u00e0 la page d’ouverture de session habituelle.<\/p>\n Une belle page d’inscription ne fera peut-\u00eatre pas la diff\u00e9rence entre le succ\u00e8s et l’\u00e9chec, mais de petites touches peuvent laisser une bonne impression et am\u00e9liorer l’interface utilisateur. Voici quelques exemples de sites qui ont mis un peu plus d’amour dans leurs processus d’authentification.<\/p>\n L’appel \u00e0 l’action de Stripe dans sa barre de navigation change selon que vous avez une session authentifi\u00e9e ou non. Voici \u00e0 quoi ressemble le site de marketing si vous n’\u00eates pas authentifi\u00e9. Notez l’appel \u00e0 l’action pour vous connecter :<\/p>\n Et voici \u00e0 quoi ressemble la page d’accueil si vous \u00eates authentifi\u00e9. Notez que l’appel \u00e0 l’action change pour amener l’utilisateur \u00e0 son tableau de bord au lieu de se connecter :<\/p>\n Cela ne change pas fondamentalement mon exp\u00e9rience avec Stripe, mais c’est agr\u00e9able.<\/p>\n Une parenth\u00e8se technique int\u00e9ressante : il y a une bonne raison pour que la plupart des entreprises ne fassent pas d\u00e9pendre la barre de navigation de leur site marketing de l’authentification – cela signifierait une requ\u00eate API suppl\u00e9mentaire pour v\u00e9rifier l’\u00e9tat d’authentification \u00e0 chaque chargement de page, la majorit\u00e9 d’entre elles \u00e9tant destin\u00e9es \u00e0 des visiteurs qui ne sont probablement pas authentifi\u00e9s.<\/p>\n Au cours des derni\u00e8res ann\u00e9es, en particulier dans le domaine du SaaS, les entreprises ont commenc\u00e9 \u00e0 ajouter du contenu \u00e0 la page d’inscription pour \u00ab encourager \u00bb l’utilisateur \u00e0 terminer l’inscription. Cela peut contribuer \u00e0 am\u00e9liorer votre taux de conversion sur la page, au moins de mani\u00e8re progressive.<\/p>\n Voici une page d’inscription de Retool, avec une animation et quelques logos sur le c\u00f4t\u00e9 :<\/p>\n C’est \u00e9galement ce que nous faisons chez Kinsta pour notre page d’inscription :<\/p>\n Le petit contenu suppl\u00e9mentaire peut aider \u00e0 rappeler \u00e0 l’utilisateur ce pour quoi il s’inscrit et pourquoi il en a besoin.<\/p>\n Je me sens \u00e0 l’aise pour dire que les d\u00e9veloppeurs savent tous que les mots de passe sont intrins\u00e8quement peu s\u00fbrs, mais ce n’est pas<\/em> le cas de toutes les personnes qui s’inscriront \u00e0 votre produit. Encourager vos utilisateurs \u00e0 cr\u00e9er des mots de passe s\u00fbrs est bon pour vous et bon pour eux.<\/p>\n Coinbase est assez strict en ce qui concerne l’inscription et exige que vous utilisiez un mot de passe s\u00e9curis\u00e9 plus compliqu\u00e9 que votre simple pr\u00e9nom :<\/p>\n Apr\u00e8s avoir g\u00e9n\u00e9r\u00e9 un mot de passe \u00e0 partir de mon gestionnaire de mots de passe, j’\u00e9tais pr\u00eat \u00e0 partir :<\/p>\n L’interface utilisateur ne m’a cependant pas expliqu\u00e9 pourquoi<\/em> le mot de passe n’\u00e9tait pas assez s\u00fbr, ni quelles \u00e9taient les exigences au-del\u00e0 de la pr\u00e9sence d’un num\u00e9ro. Le fait d’inclure ces informations dans le texte de votre produit rendra les choses plus faciles pour votre utilisateur et permettra d’\u00e9viter les frustrations li\u00e9es aux tentatives de nouvel essai du mot de passe.<\/p>\n Un Am\u00e9ricain sur trois utilise un gestionnaire de mot de passe comme 1Password<\/a>, et pourtant de nombreux formulaires sur le web continuent d’ignorer le \u00ab type= \u00bb dans les entr\u00e9es HTML. Faites en sorte que vos formulaires soient compatibles avec les gestionnaires de mots de passe<\/a>:<\/p>\n Cela peut faire la diff\u00e9rence entre une connexion incroyablement fluide en 10 secondes et une connexion manuelle ennuyeuse, en particulier sur mobile.<\/p>\n Une fois que votre utilisateur s’est authentifi\u00e9, vous devez choisir une strat\u00e9gie pour conserver cet \u00e9tat lors des requ\u00eates suivantes. HTTP est sans \u00e9tat, et nous ne voulons certainement pas demander \u00e0 notre utilisateur son mot de passe \u00e0 chaque requ\u00eate. Il existe deux m\u00e9thodes populaires pour g\u00e9rer cela<\/a> – les sessions<\/strong> (ou cookies) et les JWT<\/strong> (jetons web JSON) – et elles diff\u00e8rent selon que c’est le serveur ou le client qui fait le travail.<\/p>\n Dans l’authentification par session, la logique et le travail de maintien de l’authentification sont pris en charge par le serveur<\/strong>. Voici le processus de base :<\/p>\n C’est assez simple et modifiable en ce qui concerne la dur\u00e9e des sessions, le moment o\u00f9 elles doivent \u00eatre r\u00e9voqu\u00e9es, etc. L’inconv\u00e9nient est la latence \u00e0 une \u00e9chelle significative, \u00e9tant donn\u00e9 toutes les \u00e9critures et les lectures dans la base de donn\u00e9es, mais ce n’est peut-\u00eatre pas une consid\u00e9ration majeure pour la plupart des lecteurs.<\/p>\n Au lieu de g\u00e9rer l’authentification pour les requ\u00eates ult\u00e9rieures sur le serveur, les JWT<\/a> vous permettent de les g\u00e9rer (principalement) du c\u00f4t\u00e9 client<\/strong>. Voici comment cela fonctionne :<\/p>\n Avec tout le travail d’authentification post-initiale d\u00e9charg\u00e9 sur le client, votre application peut se charger et fonctionner beaucoup plus rapidement. Mais il y a un probl\u00e8me majeur : il n’y a aucun moyen d’invalider un JWT \u00e0 partir du serveur. Si l’utilisateur souhaite se d\u00e9connecter d’un appareil ou si la port\u00e9e de son autorisation change, vous devez attendre que le JWT expire.<\/p>\n Une partie de ce qui rend Next.js g\u00e9nial est le rendu statique int\u00e9gr\u00e9 – si votre page est statique, c’est-\u00e0-dire qu’elle n’a pas besoin de faire des appels d’API externes, Next.js la met automatiquement en cache et peut la servir extr\u00eamement rapidement via un CDN. Pre-Next.js 13 sait si une page est statique si vous n’incluez pas de \u00ab getServerSideProps \u00bb ou \u00ab getInitialProps \u00bb dans le fichier, tandis que toutes les versions post\u00e9rieures \u00e0 Next.js 13 utilisent React Server Components<\/a> pour le faire \u00e0 la place.<\/p>\n Pour l’authentification, vous avez le choix<\/a> entre rendre une page statique de \u00ab chargement \u00bb et faire la recherche c\u00f4t\u00e9 client ou tout faire c\u00f4t\u00e9 serveur. Pour les pages qui requi\u00e8rent une authentification [1]<\/a>, vous pouvez rendre un \u00ab squelette \u00bb statique et effectuer les requ\u00eates d’authentification c\u00f4t\u00e9 client. En th\u00e9orie, cela signifie que la page se charge plus rapidement, m\u00eame si le contenu initial n’est pas enti\u00e8rement pr\u00eat.<\/p>\n Voici un exemple simplifi\u00e9 tir\u00e9 de la documentation qui rend un \u00e9tat de chargement tant que l’objet utilisateur n’est pas pr\u00eat :<\/p>\n Notez que vous devrez construire une sorte d’interface utilisateur de chargement pour conserver l’espace pendant que le client fait des requ\u00eates apr\u00e8s le chargement.<\/p>\n Si vous voulez simplifier les choses et ex\u00e9cuter l’authentification c\u00f4t\u00e9 serveur, vous pouvez ajouter votre demande d’authentification dans la fonction \u00ab getServerSideProps \u00bb, et Next attendra de rendre la page jusqu’\u00e0 ce que la demande soit compl\u00e8te. Au lieu de la logique conditionnelle de l’extrait ci-dessus, vous pouvez ex\u00e9cuter quelque chose de plus simple comme cette version simplifi\u00e9e de la documentation de Next :<\/p>\n Il y a toujours une logique ici pour g\u00e9rer l’\u00e9chec de l’authentification, mais elle redirige vers la connexion au lieu de rendre un \u00e9tat de chargement.<\/p>\nBase de donn\u00e9es traditionnelle<\/h3>\n
Solutions d’authentification de votre fournisseur de base de donn\u00e9es<\/h3>\n
async function signInWithEmail() {\n const { data, error } = await supabase.auth.signInWithPassword({\n email: 'example@email.com',\n password: 'example-password',\n })\n}<\/code><\/pre>\nDes solutions d’authentification qui ne proviennent pas de votre fournisseur de base de donn\u00e9es<\/h3>\n
![\"Auth0](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/Auth0-authentication.png\")
Authentification unique (SSO)<\/h3>\n
D’accord, alors lequel me convient le mieux ?<\/h3>\n
Construire des routes pour l’inscription et la connexion, et des conseils pour aller plus loin dans l’authentification<\/strong><\/h2>\n
\n
1. Mettez \u00e0 jour votre barre de navigation en cas de session active<\/h3>\n
![\"La](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage.png\")
![\"Modifications](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/stripe-homepage-changes.png\")
2. Ajoutez un contenu utile au formulaire d’inscription<\/h3>\n
![\"Si](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/retool-signup-page.png\")
![\"Page](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/mykinsta-sign-in.png\")
3. Si vous utilisez un mot de passe : sugg\u00e9rez ou imposez un mot de passe fort<\/h3>\n
![\"Mot](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-create-account.png\")
![\"Mot](\"https:\/\/kinqsta.com\/wp-content\/uploads\/2023\/11\/coinbase-password-strength.png\")
4. Labellisez vos entr\u00e9es pour qu’elles soient compatibles avec un gestionnaire de mots de passe<\/h3>\n
\n
Choisir entre Sessions et JWT<\/strong><\/h2>\n
Sessions, ou cookies<\/h3>\n
\n
Jetons web JSON (JWT)<\/h3>\n
\n
Choisir entre l’authentification c\u00f4t\u00e9 serveur et l’authentification c\u00f4t\u00e9 client<\/strong><\/h2>\n
import useUser from '..\/lib\/useUser'\n \nconst Profile = () => {\n \/\/ Fetch the user client-side\n const { user } = useUser({ redirectTo: '\/login' })\n \n \/\/ Server-render loading state\n if (!user || user.isLoggedIn === false) {\n \/\/ Build some sort of loading page here\n return <div>Loading...<\/div>\n }\n \n \/\/ Once the user request finishes, show the user\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nimport withSession from '..\/lib\/session'\n \nexport const getServerSideProps = withSession(async function ({ req, res }) {\n const { user } = req.session\n \n if (!user) {\n return {\n redirect: {\n destination: '\/login',\n permanent: false,\n },\n }\n }\n \n return {\n props: { user },\n }\n})\n \nconst Profile = ({ user }) => {\n \/\/ Show the user. No loading state is required\n return (\n <div>\n <h1>Your Account<\/h1>\n <p>Username: {JSON.stringify(user.username,null)}<\/p>\n <p>Email: {JSON.stringify(user.email,null)}<\/p>\n <p>Address: {JSON.stringify(user.address,null)}<\/p>\n <\/div>\n )\n}\n \nexport default Profile<\/code><\/pre>\nR\u00e9sum\u00e9<\/h2>\n