STACKIT IdP troubleshooting

STACKIT IdP troubleshooting is mainly about integration flows, provisioning clients, and support handover during onboarding. If you are troubleshooting a user sign-in flow, start with the relevant federation guide first, then use this page for provisioning and token-related checks.

Start here

Before changing anything, confirm these basics:

• You are using the correct integration guide for your protocol or client.
• The support ticket contains the right federation type, domains, and client details.
• If users are provisioned automatically, the SCIM client and the login federation are aligned on the same user life cycle.

Provisioning versus login

Login and provisioning solve different parts of the integration:

• Login is the federation flow that authenticates the user and gives them access to STACKIT.
• Provisioning is the SCIM flow that creates and updates user accounts and group membership before or alongside login.

If provisioning works but sign-in fails, the issue is usually in the federation setup rather than SCIM.

• For SAML, verify whether the flow is SP-initiated and whether the user already exists if auto creation is disabled.
• For OIDC, verify the issuer, claims mapping, and whether user auto creation is enabled.
• For Microsoft Entra ID, check whether the Enterprise App is configured for SAML, SCIM, or both.

Common SCIM errors

401 unauthorized

A 401 Unauthorized response usually means the request did not include a valid authentication token.

Check the following:

• The Authorization header is present.
• The bearer token was copied correctly and has not expired.

Note: Refresh tokens are not returned for the client credentials grant type, as described in RFC 6749, Section 4.4.3. If your integration relies on refresh tokens to work, take this into account and adapt it accordingly.

If you are still onboarding or debugging a workflow, STACKIT Support can provide a longer-lived token temporarily so you can validate the provisioning flow without frequent token rotation.

403 forbidden

A 403 Forbidden response usually means the token is valid, but it does not have enough permissions for the requested action.

Check the following:

• The token includes the required scim.read or scim.write scope.
• The client is calling the correct endpoint for the operation.
• The integration is allowed to manage the target domain or resource.

400 bad request

A 400 Bad request response usually means the request body does not match the expected SCIM schema or the request parameters are inconsistent.

Common causes include:

• Missing required fields.
• Invalid attribute values.
• A blocked email domain.
• A filter expression that is too complex.

Review the request body and compare it with the SCIM endpoint reference.