Une leçon volontairement générique
Chaque organisation a son fournisseur d’identité : Authentik, Keycloak, ADFS, Entra ID, Okta, Zitadel. Les écrans diffèrent, le vocabulaire aussi — mais le protocole est le même, et la moitié Forgejo est strictement identique.
Cette leçon est donc construite en deux temps : d’abord ce qu’il faut créer côté IdP, décrit en termes de protocole plutôt que de captures d’écran, puis la configuration côté Forgejo, détaillée champ par champ.
Un tableau de correspondance vous aidera à traduire dans le vocabulaire de votre produit.
Le principe, en six étapes
Avant de configurer quoi que ce soit, visualisez ce qui va se passer quand un utilisateur cliquera sur « Se connecter avec… ».
1. L'utilisateur clique sur le bouton dans Forgejo
│
2. Forgejo le redirige vers l'IdP ──────────────▶ IdP
│
3. L'utilisateur s'authentifie CHEZ L'IdP ◀─────────┤
(mot de passe, MFA, politiques…) │
│
4. L'IdP le renvoie vers l'URI de redirection ◀─────┘
avec un code à usage unique
│
5. Forgejo échange ce code contre un jeton
(côté serveur, avec son secret client) ────────▶ IdP
│
6. Forgejo lit l'identité dans le jeton
et crée ou retrouve le compte
Deux points à retenir de ce schéma.
Le mot de passe n’apparaît qu’à l’étape 3, chez l’IdP. Forgejo ne le voit jamais. C’est tout l’argument de la leçon précédente.
L’étape 5 se fait de serveur à serveur. Votre forge doit donc pouvoir joindre l’IdP par le réseau — évident, mais c’est la cause d’un certain nombre d’échecs en environnement cloisonné.
Côté fournisseur d’identité
Quel que soit votre produit, vous devez y créer une déclaration d’application et en ressortir avec trois informations.
Ce qu’il faut créer
| Paramètre | Valeur |
|---|---|
| Type de client | Confidentiel (l’application peut garder un secret) |
| Flux d’autorisation | Code d’autorisation (authorization code) |
| URI de redirection | https://forge.nordika.local/user/oauth2/<NomDeLaSource>/callback |
| Scopes | openid, profile, email — et groups si votre IdP le propose |
| Signature des jetons | RS256 (valeur usuelle) |
Ce qu’il faut en ressortir
- L’identifiant client (Client ID)
- Le secret client (Client Secret) — à traiter comme un mot de passe
- L’URL de découverte, de la forme
https://idp.nordika.local/.../.well-known/openid-configuration
Cette dernière est précieuse : elle décrit automatiquement tous les points d’accès de l’IdP. Forgejo sait la consommer, ce qui vous évite de saisir quatre ou cinq URL à la main.
Le vocabulaire selon les produits
| Notion | Authentik | Keycloak | Entra ID | ADFS |
|---|---|---|---|---|
| La déclaration | Provider + Application | Client | App registration | Application group |
| Identifiant | Client ID | Client ID | Application (client) ID | Client Identifier |
| Secret | Client Secret | Client secret (onglet Credentials) | Certificates & secrets | Secret |
| Découverte | Sous l’URL du provider | .../realms/<realm>/.well-known/... |
.../v2.0/.well-known/... |
.../adfs/.well-known/... |
| Groupes | Scope groups à ajouter |
Mapper de type Group Membership | Claim groups à configurer |
Claim rule |
Le cas des groupes mérite votre attention : dans la plupart des IdP, l’appartenance aux groupes n’est pas transmise par défaut. Il faut l’activer explicitement — un scope supplémentaire, un mapper, une règle de revendication selon les produits. Si vous voulez la mise en correspondance automatique avec les équipes Forgejo en 2.9, faites-le maintenant.
L’URI de redirection : le piège n°1
C’est de très loin la première cause d’échec, et elle mérite qu’on s’y arrête.