Le projet
Tous les produits sur lesquels j'ai travaillé reconstruisaient la même chose : inscription, connexion, tokens, OAuth2. À chaque fois un peu différemment, à chaque fois avec la même famille de bugs.
Ce service est ma réponse. Tu le déploies une fois, tu l'héberges toi-même en un docker run, et tu lui parles en gRPC depuis n'importe quel backend — les services métier ne touchent plus jamais aux credentials.
Ce que j'ai construit
- Émission et validation de tokens exposées en gRPC : les backends consommateurs compilent contre un contrat protobuf typé au lieu de réécrire un client fragile à chaque fois.
- Flux OAuth2 pour l'authentification tierce.
- Store de comptes sur PostgreSQL — schéma normalisé, contraintes portées par la base et pas seulement par le code applicatif, migrations versionnées dans le repo.
- Packagé en une seule image Docker et entièrement configurable par variables d'environnement : l'auto-hébergement est une contrainte de conception, pas un détail de déploiement.
- Une surface HTTP publiée en ligne pour l'exploration et les tests d'intégration, le fichier proto restant le vrai contrat.
En détail
3 min de lectureChaque 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