Présentation

go-dev-auth est présenté sur GitHub comme « The comprehensive authentication library for Go ». Le projet se distingue par son principe « zero‑dependency », c’est‑à‑dire qu’il n’utilise aucune bibliothèque tierce au moment de la compilation. L’ensemble de la logique repose sur le standard library de Go, ce qui simplifie l’audit de sécurité et la gestion des versions. Le dépôt expose une architecture modulaire : un seul struct Config centralise la configuration, tandis que les fonctionnalités sont découpées en sous‑packages (crypto, oauth2, plugins, providers, ratelimit, storage).

Architecture et composants

Le répertoire crypto regroupe les primitives de chiffrement utilisées pour signer les jetons d’accès. Le package oauth2 implémente les flux d’autorisation standard (Authorization Code, Implicit, PKCE) et expose des handlers dédiés (handler_oauth.go) qui interagissent avec les fournisseurs définis dans providers. La couche storage propose une abstraction générique : chaque backend (mémoire, base de données, cache) doit implémenter l’interface Store, ce qui permet d’injecter la persistance au moment de l’initialisation du serveur.

Le système de plugins, situé dans le répertoire plugins, offre un point d’extension pour ajouter des mécanismes d’authentification personnalisés (ex. : MFA, SSO). Chaque plugin doit satisfaire l’interface Plugin et est chargé dynamiquement par le routeur (router.go). Le module ratelimit applique une limitation de débit au niveau des endpoints d’authentification, protégeant ainsi contre les attaques par force brute.

Performances et sécurité

Le dépôt inclut plusieurs suites de tests de performance (benchmark_test.go) et de robustesse (concurrency_test.go, security_test.go, resilience_test.go). Les benchmarks mesurent le temps moyen de génération et de validation d’un JWT, ainsi que le coût d’une requête d’authentification complète (handler + stockage). Les tests de concurrence simulent des milliers de requêtes simultanées afin de détecter les conditions de course dans la gestion des sessions (session.go) et des rafraîchissements de jetons (session_refresh_test.go). Les tests de sécurité valident la résistance aux attaques de relecture, aux injections de cookies et aux mauvaises configurations de CORS.

Le code source utilise le package crypto/hmac du standard library pour signer les tokens, évitant ainsi les dépendances externes susceptibles d’introduire des vulnérabilités. Le fichier hardening_test.go vérifie que les paramètres de chiffrement respectent les recommandations actuelles (algorithme SHA‑256, clé d’au moins 256 bits).

Limites et perspectives

Bien que la promesse de zéro dépendance simplifie l’intégration, elle implique également que certaines fonctionnalités avancées (ex. : gestion de clés asymétriques, support natif de OpenID Connect) ne sont pas fournies out‑of‑the‑box et nécessitent la création de plugins ou l’ajout de code personnalisé. Le projet ne publie pas de version sémantique explicite dans le README, ce qui complique la gestion des mises à jour pour les équipes de production. Enfin, l’absence de documentation détaillée sur les stratégies de rotation de clés (répertoire rotation_test.go) laisse une marge d’interprétation quant aux meilleures pratiques d’exploitation en environnement à forte contrainte de conformité.