Un fournisseur d'identité écrit à la main

Le problème

Configurer un fournisseur d'identité sans savoir ce qu'il doit refuser, c'est le régler à l'aveugle. Je voulais savoir exactement quelles attaques chaque règle arrête.

Ce que j'ai construit

• Flux authorization code avec PKCE obligatoire ; jetons JWT signés en RS256, clés de vérification réservées aux applications du lab et rotation sans coupure ; refresh tokens à rotation.
• Double authentification TOTP, compatible Google Authenticator.
• Une session SSO partagée par quatre applications : un client confidentiel, une application monopage (PKCE seul), Grafana et GitLab.

Choix et raisons

• Un compte SSO n'est jamais rattaché à un compte existant de Grafana ou GitLab, ni par son nom ni par son e-mail : il est reconnu par un identifiant tiré au hasard.
• Aucune adresse e-mail collectée : le serveur fournit une adresse technique en .invalid (RFC 6761) qui ne peut correspondre à aucun compte.
• Les noms comme admin ou root sont refusés à l'inscription ; Grafana ne donne que le rôle Viewer, GitLab un compte externe ; les comptes de démonstration sont supprimés après 24 h.

Vérifié

• 33 tests, rejoués à chaque pipeline, vérifient chacune des attaques que le serveur doit refuser.
• Avec un navigateur piloté, en ligne : une seule saisie du mot de passe et du code TOTP, puis Grafana et GitLab ne demandent que le consentement. Un compte nommé « admin » a obtenu un compte Grafana distinct, en lecture seule.

Limites et suite

Écrit pour apprendre, pas pour remplacer un produit éprouvé. Le code est dans un dépôt privé.