feat: Expand SSOProviderType to all supported enterprise SSO types

[devin-ai-integration]

Description

Expands SSOProviderType from only 'GoogleSAML' to all 33 enterprise SSO provider types (SAML + OIDC) that the API now accepts for intentOptions.sso.providerType when generating Admin Portal links.

-providerType?: 'GoogleSAML';
+providerType?: SSOProviderType; // 33 SAML/OIDC types

New SSOProviderType union type is exported from the package. Companion to workos/workos#62957 which removed the GoogleSAML-only server-side restriction.

Documentation

[ ] Yes

The API reference docs are updated in the companion PR (workos/workos#62957).

Link to Devin session: https://app.devin.ai/sessions/be0ac27c0b6f4967b67645d6001810ce

[devin-ai-integration]

Original prompt from heather

SYSTEM:
=== BEGIN THREAD HISTORY (in #team-enterprise) ===
Heather Faerber (U08CUNLUBT9): @Adam Jenkins
Can you confirm that the only supported option for intent_options.sso.provider_type is GoogleSAML? Is there some combination of feature flags that supports passing other providers like Okta as values there?

Everything I'm finding indicates only GoogleSAML is supported except this <https://app.notion.com/p/workos/Admin-Portal-link-provider-config-33ad458aea8b81fc8a82d69da901ab31?source=copy_link`#`33ad458aea8b819b883adb46761b8495|one tiny note in a notion about it> so I wanted to be sure.

[Slack unfurl — this is an automatic link preview, not a user message]
Quote of conversation (https://work-os.slack.com/archives/C04D4SM4AKZ/p1754325878447149):
> From Adam Jenkins
> From Friday's AH demo

> The ability to limit SSO providers in admin portal to a single provider via custom params when generating the portal link (currrently behind a feature flag). Surfacing this ship in case anybody sees a customer request where this might be relevant!

> Feel free to reach out in <#C097UD2KJKS|>

> ATTACHMENT:"https://app.devin.ai/attachments/c6b3b754-6123-4f06-9713-58c76e5429e7/image.png"
> Posted on August 04, 2025 at 04:44 PM

Adam Jenkins (U07ULEA5SN8): This sounds right, but it's been a minute. Have you already Devin'd this @Heather Faerber? I don't want to Devin you without asking if you've already Devin'd it?

Adam Jenkins (U07ULEA5SN8): Devin's a verb now

<most_recent_message>
Heather Faerber (U08CUNLUBT9): I've Cursord and Notiond it - both confirm its only GoogleSAML. But I haven't Devin'd it. Lets do it

@Devin Can you confirm if the only supported option for intent_options.sso.provider_type when generating an SSO admin portal link via API is "GoogleSAML"? Is there some combination of feature flags that supports passing other providers like Okta as values there?
</most_... (390 chars truncated...)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Greptile Summary

• Expands Admin Portal SSO provider typing from GoogleSAML to a broader exported SSOProviderType union.
• Updates SSO intent request and response types to use the new enterprise SSO provider union.
• Keeps Admin Portal link generation serialization behavior unchanged while allowing all supported provider types at the type level.

Confidence Score: 5/5

The change is merge-safe: it broadens TypeScript typing for an existing serialized field without altering runtime request construction.

Only two Admin Portal interface/type files are touched, the behavior remains unchanged, and no code paths introduce new execution or persistence risks.

T-Rex Logs

What T-Rex did

• Executed the T-Rex harness to build the PR head and capture the initial, baseline state.
• Inspected the pre-change log artifact to confirm the baseline failures caused by the missing public/direct SSOProviderType export and related TypeScript issues.
• Re-ran the harness to verify the post-change results after the changes in the PR.
• Inspected the post-change log artifact to confirm the harness now compiles with exit code 0 and validates the exported union, literals, interface fields, and provider typings.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "Expand SSOProviderType to all supported ..." | Re-trigger Greptile}