--- title: "Configure a generic OIDC application" description: "Connectez à UserLock Single Sign-On toute application prenant en charge un fournisseur OIDC générique." locale: "fr" updated_at: "2026-10-29T12:39:51.303Z" canonical: "https://www.isdecisions.com/fr/userlock/docs/guides/sso/configurer-applications/configure-generic-oidc-application" --- # Configurer une application OIDC générique Configuration OIDC générique : identifiants client, endpoints, scopes et correspondance des utilisateurs. ## Introduction Ce guide explique comment connecter une application à **UserLock Single Sign-On (SSO)** en utilisant **OpenID Connect (OIDC)**, une couche d’authentification bâtie sur OAuth 2.0. UserLock SSO joue le rôle de fournisseur OpenID, et l’application celui de partie de confiance. Utilisez ce guide lorsque l’application prend en charge un fournisseur OIDC générique ou personnalisé. Si l’application figure déjà dans la liste des applications UserLock, utilisez son guide dédié. Si elle prend en charge SAML 2.0 plutôt que OIDC, consultez [Configurer une application SAML générique](/userlock/docs/guides/sso/configure-the-applications/configure-non-supported-saas-application). Lorsqu’un utilisateur se connecte, l’application le redirige vers la page de connexion UserLock SSO. UserLock l’authentifie via Active Directory et le renvoie vers l’application, connecté. Les administrateurs peuvent alors appliquer les [stratégies d'accés](/userlock/docs/reference/core-concepts/access-policies) UserLock (MFA, restrictions temporelles, machines, ou localisation) à ces sessions. > **🚩️ Avant de commencer :** > > - Le SSO UserLock doit déjà être [installé et configuré](/userlock/docs/guides/sso/install-configure-sso), et joignable publiquement en HTTPS avec un certificat SSL valide. > - Vous devez disposer d’un accès administrateur aux paramètres d’authentification de l’application. > - Chaque compte Active Directory qui se connectera doit avoir son attribut `mail` renseigné. UserLock envoie cette adresse dans la claim `email`. ## Étape 1. Créer le profil OIDC dans UserLock SSO 1. Dans la **console UserLock**, accédez à ⚙ **Paramètres du serveur ▸ Authentification unique (SSO)**. 2. Dans la liste des applications disponibles, cliquez sur **CustomOidc**. 3. Ajoutez un nouveau profil et renseignez les champs suivants : | Paramètre | Valeur | | --- | --- | | Client ID | Un identifiant de votre choix pour le client OIDC, par exemple `myapp-oidc`. Toute valeur acceptée comme identifiant client standard convient | | ACS URL | La Redirect URI de l’application, aussi appelée callback URL ou redirect URL. Copiez-la exactement telle que l’application l’affiche : une redirection qui ne correspond pas est rejetée | | Client secret | Un secret sécurisé est généré automatiquement. Conservez la valeur proposée | 4. Enregistrez le profil. Gardez le **Client ID** et le **Client secret** à portée de main. Vous les saisirez tous les deux dans l’application à l’étape suivante. > **Remarque** > > UserLock accepte plusieurs profils OIDC, un par application. Le **Client secret** ne peut pas être régénéré depuis la console, mais vous pouvez modifier sa valeur manuellement. Si vous la changez, mettez l’application à jour en même temps : la connexion échoue tant que les deux valeurs ne correspondent pas. ## Étape 2. Configurer l’application L’URL de votre SSO UserLock est affichée dans ⚙ **Paramètres du serveur ▸ Authentification unique (SSO)**. Dans ce guide, `` désigne cette URL sans le protocole. Pour `https://sso.contoso.com`, l’adresse SSO est `sso.contoso.com`. Si l’URL utilise un port personnalisé, incluez-le dans tous les endpoints : `https://sso.contoso.com:450` donne `sso.contoso.com:450`. Dans les paramètres d’authentification de l’application, ouvrez le fournisseur OIDC générique ou personnalisé et renseignez les valeurs suivantes : | Paramètre OIDC | Valeur | | --- | --- | | Client ID | Le **Client ID** du profil UserLock | | Client secret | Le **Client secret** du profil UserLock | | Scopes | openid profile email | | Authorization endpoint | https:///connect/authorize | | Token endpoint | https:///connect/token | | UserInfo endpoint | https:///connect/userinfo | | Issuer | https:// | Les applications nomment ces champs différemment. Un authorization endpoint peut apparaître sous le nom **Auth URL** ou **Authorization URL**, et un userinfo endpoint sous le nom **API URL** ou **User info URL**. Certaines applications ne demandent que l’issuer ou une URL de découverte, et récupèrent elles-mêmes tous les endpoints. Enregistrez la configuration, et activez le fournisseur si l’application l’indique comme désactivé. > **⚠️ Important** > > Ne conservez que `openid profile email` dans la liste des scopes. Certaines applications ajoutent un scope par défaut que UserLock SSO n’autorise pas, ce qui fait échouer la connexion. Les scopes acceptés par UserLock sont listés dans `scopes_supported` du document de découverte. > **Remarque** > > UserLock SSO publie un document de découverte OIDC sur `https:///.well-known/openid-configuration`. Il liste tous les endpoints, les scopes et claims pris en charge ainsi que la clé de signature, et fait foi si une application attend une valeur que ce guide ne couvre pas. ## Étape 3. Tester la connexion OIDC 1. Ouvrez la page de connexion de l’application dans une fenêtre de navigation privée. 2. Sélectionnez l’option de connexion UserLock. Son libellé correspond au nom d’affichage configuré dans l’application. 3. Vérifiez que vous êtes redirigé vers la page de connexion UserLock SSO. 4. Connectez-vous avec les identifiants de domaine d’un compte Active Directory de test dont l’attribut `mail` est renseigné. 5. Vérifiez que vous êtes redirigé vers l’application, connecté, et que le compte affiche l’adresse e-mail attendue. ## Dépannage Pour les problèmes courants, consultez la page [Dépannage du SSO](/userlock/docs/support/troubleshooting/sso-issues). Si le problème persiste, contactez le [support IS Decisions](/userlock/docs/support/need-assistance). ### L’application refuse la connexion après une authentification UserLock réussie Les journaux UserLock SSO indiquent une authentification réussie, mais l’application refuse l’utilisateur. Deux causes sont fréquentes : - La claim `email` est vide, car le compte Active Directory n’a pas d’attribut `mail` renseigné. Renseignez-le, puis reconnectez-vous. - L’adresse e-mail appartient déjà à un autre compte dans l’application, qui refuse de les associer. Utilisez une autre adresse, ou supprimez ou renommez le compte en conflit. ### L’application ne parvient pas à joindre les endpoints UserLock Ouvrez `https:///.well-known/openid-configuration` depuis un navigateur situé hors de votre réseau d’entreprise. L’URL doit être joignable en HTTPS et renvoyer le document de découverte. Si ce n’est pas le cas, vérifiez l’enregistrement DNS public, la liaison HTTPS et le certificat SSL, ainsi que toute règle réseau bloquant l’accès externe. Une connexion qui atteint la page de connexion UserLock mais échoue au retour signifie que UserLock SSO est joignable depuis les navigateurs de vos utilisateurs, mais pas depuis les serveurs de l’application. ### La redirection est rejetée L’**ACS URL** du profil UserLock ne correspond pas à la Redirect URI envoyée par l’application. Comparez les deux valeurs caractère par caractère, y compris le protocole, le port éventuel, le chemin final et la présence ou non d’une barre oblique finale. ## Étapes suivantes Vous pouvez étendre la sécurité des sessions SaaS en appliquant les stratégies d’accès UserLock, en complément de l’authentification. - [Appliquer la MFA sur les sessions SaaS](/userlock/docs/guides/implementation-mfa/mfa-sso) : exiger une authentification renforcée. - [Restrictions horaires](/userlock/docs/reference/strategies-acces/restrictions-de-temps) : définir quand les utilisateurs sont autorisés à se connecter. - [Règles de géolocalisation](/userlock/docs/reference/strategies-acces/geolocalisation) : appliquer des politiques en fonction de l’emplacement de l’utilisateur. - [Limites de sessions](/userlock/docs/reference/strategies-acces/limites-de-sessions) : autoriser ou interdire totalement l’ouverture de sessions SaaS pour certains utilisateurs.