Arrêtez de Construire l'Authentification par Mot de Passe par Défaut_

La plupart des équipes sous-estiment ce que signifie "posséder l'authentification".

Ce n'est pas simplement un formulaire de connexion et une colonne de mot de passe haché. Il s'agit de la récupération de compte, de la protection contre les bots, de l'enrôlement MFA, de la vérification des e-mails, de la gestion des mots de passe compromis, de la confiance des appareils, de la détection des connexions suspectes, de la politique de verrouillage, de la gestion des sessions et de la réponse aux incidents lorsque quelque chose tourne mal.

Si l'authentification n'est pas votre produit, vous devriez être méfiant envers tout plan qui commence par "nous allons simplement stocker nous-mêmes des hachages bcrypt."

Le Problème N'est Pas le Hachage

Le hachage des mots de passe est nécessaire. Ce n'est pas le problème entier.

Un système d'authentification sérieux a également besoin de :

• un flux de réinitialisation sécurisé
• une résistance au credential stuffing
• une protection contre le phishing et la fixation de session
• une auditabilité autour des événements de connexion
• un support pour MFA ou des clés d'accès
• des processus opérationnels pour le support et la récupération

Les équipes mettent souvent en œuvre les 20 % initiaux et héritent de la responsabilité des 80 % restants sans s'en apercevoir.

Ce Que L'OIDC Vous Donne Réellement

OpenID Connect ajoute une couche d'identité au-dessus d'OAuth 2.0. En pratique, cela permet à votre application de s'appuyer sur un fournisseur d'identité tel que Google, Microsoft Entra ID, Okta, Auth0, WorkOS ou Clerk pour authentifier l'utilisateur et émettre des tokens standardisés.

Cela modifie votre application de :

• collecter des mots de passe directement
• valider des identifiants
• exécuter des flux de récupération

à :

• rediriger l'utilisateur vers un fournisseur d'identité
• valider les tokens retournés
• créer une session d'application

C'est une bien meilleure position pour la plupart des équipes SaaS.

Le Flux Que Vous Voulez Habituellement

Pour les applications web, le comportement par défaut devrait généralement être le Flux de Code d'Autorisation. Si le client est une application basée sur le navigateur, utilisez également PKCE.

À un niveau élevé :

1. L'utilisateur clique sur "Se connecter".
2. Votre application le redirige vers le fournisseur d'identité.
3. Le fournisseur d'identité authentifie l'utilisateur.
4. Votre backend échange le code d'autorisation contre des tokens.
5. Votre application valide les revendications du token et crée sa propre session.

Le détail important est que votre produit n'a pas besoin de gérer directement le mot de passe.

Ce Que Vous Devez Encore Mettre en Œuvre

Déléguer l'authentification n'élimine pas toute responsabilité. Cela la réduit.

Vous devez toujours :

• valider correctement l'émetteur, le public, la date d'expiration et la signature
• utiliser state et nonce lorsque cela est nécessaire
• créer et faire tourner votre propre session d'application en toute sécurité
• séparer l'authentification de l'autorisation
• modéliser les utilisateurs dans votre base de données avec des identifiants stables

Une erreur courante consiste à ne stocker que l'adresse e-mail comme identité. Cela n'est pas suffisamment stable en soi. Dans les systèmes OIDC, l'identifiant durable est généralement le fournisseur plus la revendication sub.

type Identity = {
  provider: "google" | "microsoft" | "okta";
  subject: string;
  email: string;
  emailVerified: boolean;
};

function getIdentityKey(identity: Identity) {
  return `${identity.provider}:${identity.subject}`;
}

Cela évite des bugs subtils de liaison de compte par la suite.

Un Meilleur Modèle Mental

Ne considérez pas OIDC comme un "login social".

Considérez-le comme le transfert d'une capacité à haut risque vers un logiciel qui est construit, audité et doté de personnel spécifiquement pour l'identité.

Cela ne signifie pas que chaque fournisseur est automatiquement configuré correctement. Cela signifie que les éléments de construction par défaut sont matériellement plus solides que ce que la plupart des équipes produit créent sous pression temporelle.

Quand Construire Vous-Même A Du Sens

Il existe des cas où posséder l'authentification est justifié :

• vous construisez un produit d'identité
• vous avez des contraintes réglementaires strictes qui excluent les fournisseurs externes
• vous avez besoin de modèles d'authentification hors ligne ou isolés
• vous avez la maturité en matière de sécurité en interne pour l'exploiter correctement

Ces cas existent. Ils sont simplement moins courants que ce que les ingénieurs aiment penser.

Pour un produit SaaS typique, la véritable question n'est pas "pouvons-nous construire l'authentification nous-mêmes ?" mais "pourquoi choisirions-nous de posséder cette responsabilité ?"

Lectures Complémentaires

• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients