OIDC avec Entra
OpenID Connect OIDC est un protocole d’identité basé sur OAuth 2.0 qui permet une authentification et une autorisation sécurisées pour les applications web et mobiles. Il permet aux utilisateurs de se connecter en toute sécurité à divers services, tandis que les fournisseurs de services peuvent simultanément accéder à des informations d’identité vérifiées. Cet article explique, étape par étape, comment configurer OIDC dans Relution à l’aide de Microsoft Azure.
Paramètres dans Relution
OpenID Connect OIDC peut être configuré dans le portail Relution sous Paramètres → OpenID Connect.
Les captures d’écran suivantes montrent une configuration fonctionnelle avec Microsoft Azure.

Détails de la configuration
Nom du fournisseur : Sera affiché sur le bouton de connexion dans le portail Relution. Créer des utilisateurs inconnus dans Relution : Active la création automatique de nouveaux utilisateurs inconnus lors de leur première connexion à Relution.
Si une connexion est effectuée avec un utilisateur inconnu sur l’organisation du magasin avec la configuration OIDC activée, celui-ci est automatiquement créé dans l’organisation du magasin. En cas de plusieurs mandants avec configuration OIDC, la connexion doit se faire via l’URL de l’organisation afin que l’utilisateur inconnu soit créé dans l’organisation correspondante. Cette URL est affichée dans le portail au niveau des connexions OIDC.
Détails du client
ClientID Correspond dans Azure à l’ID de l’application Client Secret Correspond dans Azure à la clé secrète client de l’ID de l’application.
URI du serveur
Utiliser le point de terminaison de découverte Si le fournisseur le prend en charge, une configuration automatique des URI nécessaires est effectuée Configuration manuelle des points de terminaison Nécessaire dès que la découverte automatique ne fonctionne pas.
Avec Microsoft Azure, les points de terminaison doivent être saisis manuellement.

Authorization URI
https://login.microsoftonline.com/$-votre-ID-de-mandant/oauth2/v2.0/authorizeJWK Set URI
https://login.microsoftonline.com/$-votre-ID-de-mandant/discovery/v2.0/keysToken URI
https://login.microsoftonline.com/$-votre-ID-de-mandant/oauth2/v2.0/tokenUser Info URI
https://graph.microsoft.com/oidc/userinfo
Configuration avancée
Username attribute from OIDC Provider L’attribut de nom d’utilisateur du fournisseur OIDC contient le nom d’utilisateur unique de l’utilisateur authentifié.
Username attribute from Relution L’attribut de nom d’utilisateur dans Relution contient le nom d’utilisateur unique de l’utilisateur authentifié.
Authorization Grant Type : Définit par quel mécanisme OAuth l’application obtient l’accès.
Scope : Détermine quelles informations ou ressources peuvent être demandées par Relution via OIDC.
Paramètres dans Azure
Créer une nouvelle inscription d’application
- Connexion au portail Azure, puis accès à Microsoft Entra ID

- Créer une nouvelle
Inscription d'application→Nouvelle inscriptionpour OIDC
- Nommer l’application, sélectionner le type de compte Comptes dans cet annuaire d’organisation uniquement et l’enregistrer

Ajouter une clé secrète client (Client Secret) sous Certificats et secrets
- La clé secrète client requise est créée sous Ajouter un certificat ou un secret

- Via Nouvelle clé secrète client, la Description et la durée de validité Valide jusqu’au peuvent être définies

- La clé client peut être copiée directement

Configurer les autorisations API
Cliquer sous
Autorisations API→Autorisations configuréessur Ajouter une autorisationSous API Microsoft, sélectionner Microsoft Graph dans la fenêtre de dialogue Demander des autorisations API

Sélectionner Autorisations d’application
Activer l’autorisation
User.Read.Allpour User

Pour les autorisations API nouvellement ajoutées, un point d’exclamation est initialement affiché comme statut. Les administrateurs doivent donner leur accord une fois pour que Microsoft Graph reçoive les autorisations. Le statut est ensuite affiché avec une coche verte pour Accordé et les autorisations sont accordées.

Ajouter l’URI de redirection
L’URI de redirection sera affiché dans le portail Relution une fois la connexion configurée et enregistrée.


Où les trouver : les URI de redirection exactes pour l’instance concernée sont affichées dans le portail Relution sous Paramètres → OpenID Connect dès que la connexion a été enregistrée. Les copier depuis cet endroit plutôt que de les reconstituer manuellement.
Avant 26.4 (héritée — une seule URI de redirection) :
https://<host>/login/oauth2/code/<registrationId>
À partir de 26.4 (avec portée — enregistrer toutes celles qui s’appliquent) :
https://<host>/api/management/login/oauth2/code/<registrationId>
https://<host>/api/device/login/oauth2/code/<registrationId>
https://<host>/api/teacher/login/oauth2/code/<registrationId> # licence Education uniquement
https://<host>/api/management/logout/connect/back-channel/<registrationId> # déconnexion back-channel
Lors de la mise à jour, ajouter les URI scopées à l’inscription d’application Entra existante. L’URI héritée continue de fonctionner, mais elle est obsolète et sera supprimée dans une future version. <registrationId> est l’UUID de configuration OIDC affiché dans Relution.
Remarques
Backchannel Logout
Relution prend en charge le Backchannel Logout à partir de la version serveur 5.32.0
Scénario d’exemple : Un utilisateur est connecté simultanément à un service SSO central et à plusieurs applications. Lors de la déconnexion du service SSO, le Backchannel Logout garantit que les sessions dans toutes les autres applications sont également terminées, même si elles fonctionnent en arrière-plan.
Prérequis pour les utilisateurs Entra pour OIDC

Vérification de la déconnexion
Vérifier les deux voies de déconnexion avant la mise en service :
- Déconnexion front-channel : L’utilisateur clique sur Se déconnecter dans Relution — la session est révoquée et le navigateur est redirigé vers le point de terminaison de déconnexion de l’IdP.
- Déconnexion back-channel : L’IdP envoie une notification de déconnexion à Relution — la session est révoquée sans intervention de l’utilisateur.
Tester les deux voies pour s’assurer qu’une fin de session initiée par l’IdP (par ex. via la console d’administration de l’IdP) est correctement transmise à Relution.