SSO Group Mapping Not Working (Microsoft Entra ID)

If users don’t receive the expected permissions or group memberships in vScope after signing in with SSO, the issue is usually that vScope isn’t getting the right group claims from your identity provider (Microsoft Entra ID). Common causes include nested groups and group overage (users belonging to many groups).

Quick checks

1. Group overage limit
   Verify that the number of groups a user belongs to doesn’t exceed the limit that Microsoft Entra ID includes directly in tokens. When overage occurs, Entra ID omits full group lists and uses a placeholder mechanism instead. See Microsoft’s guidance: Configure group claims for applications by using Microsoft Entra ID.

2. Include group claims in the application’s tokens
   Configure group claims for your application (gallery or non-gallery). You can scope claims to Security groups and/or Groups assigned to the application to keep tokens small. See Microsoft’s guide: Add group claims to tokens for applications using SSO configuration.

Tip

Scoping group claims to “Groups assigned to the application” is often enough and helps avoid group overage.

Troubleshooting

To confirm what group information Entra ID is sending to vScope, inspect the authentication token from the sign-in flow.

1. Open Developer Tools

• In your browser (e.g., Chrome), press F12 or right-click → Inspect.
• Go to the Network tab.

2. Sign in with Microsoft Entra ID (SSO)

• Perform a normal vScope login via SSO.
• In Network, look for the request that returns the token (often a token endpoint response in OIDC flows).

3. Locate and decode the token

• OIDC (JWT/ID token): Copy the id_token (a long JWT string) from the token response and decode it with a JWT tool (e.g., jwt.ms).
• SAML: Export the SAML response (Base64 XML) using a SAML tracing extension and inspect the assertion for group attributes.

4. Check for the group claim

• OIDC: In the decoded token, look for the groups claim (it should list group object IDs).
  If you don’t see groups or you see a placeholder/source reference (e.g., a _claim_names/_claim_sources pattern such as src1), continue with the steps below.
• SAML: Look for group attributes (often http://schemas.microsoft.com/ws/2008/06/identity/claims/groups or similar). If missing, continue below.

5. Assign groups to the Enterprise application

1. Go to Azure Portal → Enterprise applications.
2. Select your vScope application.
3. Open Users and groups and assign the relevant group(s) to the app.

6. Configure group claims on the app registration

1. Go to Azure Portal → App registrations → your vScope SSO app.
2. Open Token configuration → Add groups claim.
3. Choose:
   • Security groups
   • Groups assigned to the application (recommended to reduce token size)

7. Confirm the group IDs appear in the token

• Repeat steps 1–4 to verify that:
  • OIDC: The decoded token now includes a groups claim with the expected group object IDs.
  • SAML: The assertion includes the expected group attributes/IDs.

Note

If you still hit group overage, reduce group scope (prefer Groups assigned to the application), flatten deeply nested groups, or move nonessential groups out of the assignment scope.