Integration Soup can use Microsoft Entra ID for single sign-on. Entra proves the user's identity. Integration Soup stores the local access grants that decide whether that user, or one of their groups, can administer the server or access particular workflows.

Before you start

• You need permission in Microsoft Entra to create or edit an app registration.
• You need administrator access in Integration Soup so you can save SSO settings.
• For production, use the real HTTPS host name in the redirect URI. Local testing can use http://localhost.
• Keep Integration Soup's System Settings page open. It shows the redirect URI and warns about common Entra copy/paste mistakes.

Set up Microsoft Entra SSO

1. Create the Entra app registration
   Open the Microsoft Entra admin center, then go to Identity, Applications, App registrations, and choose New registration. Give the app a clear name, such as Integration Soup. For most installations, choose Accounts in this organizational directory only.
2. Register the Integration Soup redirect URI
   In Integration Soup, open System Settings, expand Authentication, then expand SSO / Active Directory. Copy the redirect URI shown on the page and add it to the Entra app registration as a Web redirect URI.
   The redirect URI must match exactly, including scheme, host, port, and path. A local test URI commonly looks like http://localhost:22009/AdminAccess/Oidc/Callback.
3. Create a client secret
   In the app registration, open Certificates & secrets, then create a new client secret. Copy the secret Value immediately. Entra only shows the value once.
   Paste the secret Value, not the Secret ID. If the value you copied looks exactly like a GUID, it is probably the Secret ID and the Integration Soup test sign-in will fail with AADSTS7000215.
4. Enter the Entra details in Integration Soup
   Turn on SSO sign-in, then enter the Entra values below.
   • Provider Authority
     https://login.microsoftonline.com/<directory-tenant-id>/v2.0
     Use the Directory tenant ID from Entra. Do not use the app client ID here.
   • Client ID
     <application-client-id>
     Use the Application (client) ID from the app registration overview.
   • Client Secret
     <client-secret-value>
     Use the secret Value copied when the secret was created.
   Leave the advanced defaults alone for Entra unless you deliberately changed token claim names: scopes should be openid profile email and the groups claim should be groups. Only the client secret is sensitive; user and group grants are normal Integration Soup security configuration.
5. Save and test sign-in
   Click Save and Test Sign-In. If sign-in succeeds, Integration Soup records the signed-in user and any groups that Entra returned in the token.
   If no groups are available yet, you can temporarily select the signed-in user as the administrator grant, save the SSO settings, then come back after group claims are configured.
6. Add group claims in Entra
   In the app registration, open Token configuration, choose Add groups claim, then select the group types that Entra should include in tokens.
   • Security groups works well for dedicated access groups such as Integration Soup Administrators.
   • All groups is needed if your access group is a Microsoft 365 group or distribution group.
   • Groups assigned to the application is useful in larger tenants to avoid returning too many groups, but it requires assigning groups to the Enterprise Application.
   Keep Group ID selected for the ID token. Do not tick Emit groups as role claims unless you also change Integration Soup's advanced groups claim setting from groups to roles.
7. Test again and choose the administrator grant
   Return to Integration Soup and run Save and Test Sign-In again. The administrator picker should now include the signed-in user and any groups returned by Entra.
   Entra usually returns group object IDs, so groups may display as GUIDs. To identify a group, open that group in Entra, go to Properties, and match its Object ID to the GUID shown in Integration Soup.
   Select the administrator user or group, then click Save SSO Settings. A dedicated admin security group is cleaner than granting admin access to an individual user, but either works.
8. Grant workflow access
   Non-admin users can sign in after SSO is enabled, but they will see a no-access page until an administrator grants them access to a workflow. The picker can only show users and groups that Integration Soup has already seen through a login or test sign-in.
   Workflow access allows the user or group to view the workflow, start and stop it, view logs, clear or reprocess logs, and use the workflow according to the global workflow-editing setting.