Is it normal to share a client secret with support for SSO setup?

The application may need the client secret to authenticate itself when exchanging an authorization code for tokens. The client ID identifies the app, while the secret is a credential. A client secret ID is not the same thing as the secret value, so clarify which one support actually needs.

Giving the service a secret is not automatically wrong, but sending it to a person adds questions about transfer, storage, access and rotation. Ask for a secure delivery method rather than sending it in ordinary email, and ask how the secret will be stored and replaced when it expires.

Check the app registration and enterprise application carefully. Grant only the API permissions the integration needs, review any admin consent, and restrict assignment to the users who should have access where the setup supports it.

The secret doesn't automatically give the vendor access to the whole tenant. What it can do depends on the app's configuration and permissions. Treat it as sensitive even with a restricted app, and have a plan to rotate or revoke it if it's exposed.

Manual setup through support does happen, although some admins would expect a customer-facing SSO configuration page. A portal doesn't mean the vendor never receives the secret, but it can avoid handing it directly to a support person.

I'd ask who can see the value, whether it goes into a ticket, and how you rotate it without another support request. Their answers may matter more than the lack of a portal by itself.

I'd also ask whether they support certificate-based credentials or SAML instead. Those might change the credential setup, but don't assume either is available or automatically safer without reviewing how the vendor implements it.