Connecter un fournisseur OpenID Connect

Utilisez ce guide lorsque votre fournisseur d’identité parle OpenID Connect plutôt que SAML. Tout émetteur certifié OIDC convient — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace et bien d’autres suivent tous les mêmes étapes ; seul l’endroit où votre fournisseur affiche les valeurs diffère.

Prérequis

• un fournisseur OIDC où vous pouvez créer un client — notez son ID client et son URL de l’émetteur (la base sous laquelle vit le document .well-known/openid-configuration), plus son secret client lorsque le client est de type confidentiel (les clients publics PKCE n’en ont pas),
• un serveur Control Center que vous administrez (le propriétaire du serveur).

Étapes

1. Ouvrez Paramètres → Serveur → Authentification unique et basculez sur OpenID Connect.
2. Renseignez l’URL de l’émetteur, l’ID client et le Secret client (facultatif) lorsque le fournisseur en a émis un. Control Center découvre les points de terminaison à partir du document de découverte standard de l’émetteur — aucune configuration propre à un fournisseur.
3. Chez le fournisseur, enregistrez la redirection https://<your-server>/oidc/callback sur ce client.
4. Si vos groupes se trouvent sous un claim autre que groups, définissez le nom du Claim des groupes ; faites correspondre les groupes à des rôles si vous le souhaitez (le SSO ne peut jamais accorder le rôle de propriétaire).
5. Choisissez la politique d’adhésion (ajout automatique à chaque espace de travail, ou invitation obligatoire par espace de travail), activez Utiliser OpenID Connect pour la connexion et cliquez sur Enregistrer la connexion.
6. Cliquez sur Tester la connexion — le serveur récupère le document de découverte de l’émetteur et confirme ses points de terminaison ; une notification verte signifie donc que tout fonctionne, hormis l’aller-retour dans le navigateur. Pour vérifier aussi l’enregistrement du client, utilisez le vérificateur ci-dessous.
7. Effectuez une connexion : l’écran de connexion web affiche Se connecter avec OpenID Connect, ou ouvrez directement https://<your-server>/oidc/login.

Les claims (adresse e-mail, nom, groupes) sont lus sur le point de terminaison de jeton de l’émetteur via TLS par votre serveur — le navigateur ne les fournit jamais, si bien qu’aucune vérification locale de signature JWT n’entre en jeu. Le client doit être autorisé à demander le scope openid profile email, ce qui correspond exactement à ce que demande Control Center.

Comme ce canal TLS est le seul élément qui authentifie les claims, l’URL de l’émetteur doit être en https — un émetteur en clair permettrait à n’importe quel attaquant en position intermédiaire de forger des identités en masse. http n’est accepté que pour les émetteurs en bouclage (localhost, 127.0.0.1, ::1), et uniquement pour le développement local.

Client public ou client confidentiel ?

La forme par défaut — et recommandée — est un client public utilisant le flux de code d’autorisation avec PKCE (RFC 7636) : le vérificateur de code à usage unique que détient le serveur remplace le secret, et l’échange de jetons est lié à la demande d’autorisation qui l’a lancé. Aucun secret ne peut fuiter, et un code d’autorisation volé est inutile sans le vérificateur. Certains fournisseurs parlent de type de client « SPA » ou « native » au moment de le créer.

Si votre fournisseur a plutôt émis un client confidentiel, marquez le client comme public chez le fournisseur (PKCE reste actif dans les deux cas), ou collez le secret client dans le champ Secret client (facultatif) de la connexion. Le secret est stocké dans le fichier de secrets 0600 du serveur (jamais dans la base de données), envoyé au point de terminaison de jeton sous la forme client_secret_post et jamais renvoyé via RPC ; laisser le champ vide lors de l’enregistrement conserve le secret stocké. Lorsqu’une connexion échoue lors de l’échange de jetons, le journal du serveur indique l’erreur propre au fournisseur (invalid_client signifie presque toujours que le secret est absent ou erroné).

Joignabilité

La connexion elle-même passe par le navigateur : l’émetteur ne fait que rediriger le navigateur de l’utilisateur vers /oidc/callback, et votre serveur effectue un appel HTTPS sortant vers le point de terminaison de jeton — aucune connexion entrante depuis l’émetteur n’est nécessaire ; un serveur derrière un NAT fonctionne donc tant que les navigateurs des utilisateurs peuvent l’atteindre (réseau local, VPN, Tailscale ou tunnel). Le provisionnement SCIM fait exception : l’IdP appelle votre serveur directement, ce qui exige un tunnel ou une URL publique — voir provisionner des utilisateurs avec SCIM.

Vérifier votre configuration depuis cette page

Le vérificateur ci-dessous s’exécute dans votre navigateur. Il récupère directement le document de découverte de votre émetteur, que ce site ne voit donc jamais, et applique les règles du serveur : un émetteur https qui correspond au document, des points de terminaison sur l’origine propre de l’émetteur, PKCE S256 et la méthode d’authentification de jeton requise par votre type de client. Avec un ID client et l’adresse du serveur, il peut ouvrir une connexion de test qui indique si le client et son URI de redirection sont enregistrés. Il ne demande jamais le secret client.

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer