Étude de cas
Auth SaaS with Go — étude de cas
Pourquoi j'ai construit un service d'auth auto-hébergeable en Go sur gRPC, les décisions derrière, et ce que je referais autrement.
Chaque produit sur lequel j'ai bossé reconstruisait la même chose : inscription, login, tokens, OAuth2. À chaque fois un peu différemment, à chaque fois avec la même famille de bugs. Ce projet est ma réponse — un service d'auth qu'on déploie une fois, qu'on auto-héberge en un docker run, et auquel n'importe quel backend parle en gRPC.
Le problème
L'authentification, c'est la partie d'un système où « presque correct » ne suffit pas — et aussi celle que les équipes sont le plus tentées de bâcler. Je voulais un service qui :
- émet et valide des tokens pour les autres services, pour que les backends métier ne touchent jamais aux credentials ;
- parle OAuth2 pour les flux tiers ;
- puisse être auto-hébergé par n'importe qui — pas de vendor, pas de facturation à l'usage, juste un conteneur et un Postgres.
Décision 1 — gRPC au cœur
L'auth est un sujet interne, de service à service. Les consommateurs de cette API sont d'autres backends, pas des navigateurs. gRPC me donne un contrat typé (protobuf) que les services clients compilent, au lieu d'une API REST où chaque consommateur ré-implémente le même code client fragile. La surface HTTP visible dans la doc live existe pour l'exploration et les tests d'intégration ; le contrat, c'est le fichier proto.
Décision 2 — Postgres comme store de comptes
Le store de comptes est la partie d'un système d'auth qu'on n'a pas le droit de rater. Je le garde ennuyeux exprès : un schéma Postgres normalisé, des contraintes dans la base plutôt que seulement dans le code applicatif, et des migrations versionnées dans le repo. La plupart des décisions difficiles de ce projet étaient des décisions de schéma — comme dans la plupart des systèmes backend sur lesquels j'ai travaillé.
Décision 3 — packagé pour l'auto-hébergement dès le premier jour
« Auto-hébergeable », c'est une contrainte de conception, pas un détail de déploiement. Ça force le service à être entièrement configurable par variables d'environnement, à ne pas avoir de dépendances cachées, et à démarrer depuis une seule image Docker. Cette contrainte a gardé l'architecture honnête : si ça ne tourne pas sur le laptop de quelqu'un d'autre, ce n'est pas fini.
Ce que je referais autrement
Une étude de cas sans regrets, c'est du marketing. La liste honnête est en cours d'écriture — demande-moi ce que je pense de la révocation de tokens.
Essayer
- Doc d'API live : auth-service-go.onrender.com/docs (hébergement free-tier — le premier chargement peut prendre quelques secondes)
- Source : github.com/MihajasoaAlain/auth-service-go