Où nous en sommes
Votre forge tourne avec un unique compte : celui d’administration locale créé en 2.4. Il est temps d’ouvrir la porte à vos collègues.
Le réflexe le plus répandu consiste à brancher l’application sur l’Active Directory et à passer à autre chose. C’est ce que font 90 % des tutoriels, et c’est ce que je vais vous déconseiller.
Cette leçon ne configure rien. Elle sert à choisir, parce que c’est une décision qu’on prend une fois et qu’on traîne ensuite pendant des années — sur cette application comme sur les vingt suivantes.
Les modes disponibles
Forgejo sait s’authentifier de plusieurs manières. Vous les retrouverez dans Administration du site → Sources d’authentification.
| Mode | Principe | Cas d’usage |
|---|---|---|
| Local | Comptes créés dans Forgejo | Compte d’administration de secours |
| LDAP (BindDN) | Forgejo interroge l’annuaire avec un compte de service | Annuaire sans IdP devant |
| LDAP (simple auth) | Forgejo se connecte directement avec les identifiants saisis | Rare, peu recommandé |
| OAuth2 / OpenID Connect | Forgejo délègue à un fournisseur d’identité | Le mode à privilégier |
| Authentification par en-tête | Le reverse proxy authentifie et transmet l’identité | Architectures particulières |
| PAM, FreeIPA | Cas spécifiques | Environnements Unix dédiés |
Une remarque au passage : la documentation officielle de Forgejo consacre une page entière à LDAP, PAM et FreeIPA — et n’y documente pas OAuth2, qui se configure entièrement depuis l’interface d’administration. Ne concluez pas de ce déséquilibre que le LDAP est la voie recommandée. C’est un héritage de documentation, pas une préconisation.
Ma position : OIDC d’abord
Je vais être direct, parce que c’est une position tranchée : je ne recommande pas de brancher vos applications directement sur vos contrôleurs de domaine. Chaque fois que c’est possible, préférez un fournisseur d’identité — Authentik, Keycloak, ADFS, Entra ID — et l’OpenID Connect.
Cinq raisons, par ordre d’importance.
1. Forgejo ne voit jamais le mot de passe
C’est l’argument de fond, et il suffirait à lui seul.
En LDAP, l’utilisateur saisit son mot de passe de domaine dans le formulaire de Forgejo. L’application le reçoit, le manipule, puis le transmet à l’annuaire pour vérification. Votre mot de passe Active Directory — celui qui ouvre les sessions, les partages, la messagerie — transite par une application web.
En OIDC, l’utilisateur est redirigé vers le fournisseur d’identité, s’authentifie chez lui, et revient avec un jeton signé. Forgejo reçoit une preuve d’identité, jamais le secret. Compromettre l’application ne compromet plus les identifiants du domaine.