Connecter un fournisseur OpenID Connect

Utilisez ce guide lorsque votre fournisseur d’identité parle OpenID Connect plutôt que SAML. Tout émetteur certifié OIDC fait l’affaire — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace et les 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 se trouve le document .well-known/openid-configuration), ainsi que 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 vers OpenID Connect.
2. Remplissez 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 par 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 ; associez des groupes à des rôles si vous le souhaitez (l’authentification unique ne peut jamais accorder le rôle propriétaire).
5. Choisissez la politique d’adhésion (ajout automatique à tous les espaces de travail, ou invitation requise pour chaque espace de travail), activez Utiliser OpenID Connect pour la connexion et appuyez sur Enregistrer la connexion.
6. Appuyez sur Tester la connexion — le serveur récupère le document de découverte de l’émetteur et confirme ses points de terminaison, de sorte qu’un bandeau vert signifie que tout fonctionne, sauf l’aller-retour dans le navigateur. Pour vérifier aussi l’enregistrement du client, utilisez le vérificateur ci-dessous.
7. Tentez une connexion : l’écran de connexion web affiche Se connecter avec OpenID Connect, ou ouvrez https://<your-server>/oidc/login directement.

Les claims (courriel, nom, groupes) sont lus par votre serveur auprès du point de terminaison de jetons de l’émetteur, au moyen de TLS — le navigateur ne les fournit jamais, donc aucune vérification locale de signature JWT n’entre en jeu. Le client doit être autorisé à demander la portée openid profile email, soit exactement ce que Control Center demande.

Comme ce canal TLS est la seule chose qui authentifie les claims, l’URL de l’émetteur doit être en https — un émetteur en clair permettrait à n’importe quel attaquant placé sur le chemin de fabriquer des identités en masse. http n’est accepté que pour les émetteurs de bouclage (localhost, 127.0.0.1, ::1), pour le développement local.

Client public ou client confidentiel ?

La forme par défaut — et recommandée — est un client public qui utilise 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 amorcé. Il n’y a aucun secret à laisser fuir, et un code d’autorisation volé est inutile sans le vérificateur. Certains fournisseurs appellent ce 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 conservé dans le fichier de secrets en 0600 du serveur (jamais dans la base de données), transmis au point de terminaison de jetons en tant que client_secret_post et jamais renvoyé par RPC ; laisser le champ vide à l’enregistrement conserve le secret déjà stocké. Quand une connexion échoue à l’échange de jetons, le journal du serveur nomme l’erreur du fournisseur (invalid_client signifie presque toujours que le secret est manquant 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 jetons — aucune connexion entrante de l’émetteur n’est nécessaire, donc un serveur derrière un NAT fonctionne tant que les navigateurs des utilisateurs peuvent l’atteindre (LAN, VPN, Tailscale ou un 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 à partir de 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, de sorte que ce site ne le voit jamais, et applique les règles du serveur : un émetteur en https qui correspond au document, des points de terminaison sur l’origine propre de l’émetteur, PKCE S256 et la méthode d’authentification des jetons qu’exige votre type de client. Avec un ID client et l’adresse du serveur, il peut ouvrir une connexion d’essai qui montre 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