WorkOS alternatives for enterprise SSO and agent keys

A customer turns on Okta through WorkOS. Their employees can open your app. Your agent still cannot call that customer's Salesforce, because Okta did not hand you the Salesforce token. The SSO connection and the API credential are different objects. Buying more SSO connections does not create the second one.

This post draws that line, and shows what to use for the credential the agent actually needs.

What WorkOS sells

The pricing page prices AuthKit at $0 for the first 1 million monthly active users, then $2,500 a month per extra million. SSO is per connection: $125 each for 1 to 15 connections, then $100, $80, and $65 at higher bands. Directory Sync uses the same bands, and it is a separate connection. A customer on both is two connections, $250 a month at the first tier. Staging is not billed. Production enterprise connections are.

AuthKit includes passwords, social login, passkeys, MFA, organizations, and SSO. The docs also list Vault for encrypting and storing sensitive objects, including bring-your-own-key. Vault is encrypted storage. It is not described as the component that injects a provider credential into a live API call and keeps it out of the model.

A WorkOS connection is a relationship with an identity provider such as Okta or Entra. It answers "who is this employee." It does not answer "which Salesforce refresh token should this agent use for this tenant."

Where enterprise SSO wins

Use WorkOS when you sell to companies that demand SAML or OIDC, SCIM, and an admin portal their IT team can configure. Authentication platforms for agents is the broader list. Per-connection pricing matches a sales motion that counts enterprise accounts, not API calls.

You want SSO before the human opens the product. You still need a second system after an agent must act on a third-party API as that tenant.

The credential the agent needs

Per-tenant API credentials are the tokens your customer's admin grants for Gmail, Slack, Salesforce, or a custom API. They are stored per customer, refreshed, and attached to one call. Multi-tenant OAuth is that problem. Credential brokering is why the token should not enter the model context.

Swytchcode connects the provider with swy auth connect and injects the credential when the call runs. The model sees the method you enabled, not the secret. A policy can still deny the call. On the October 2026 pricing page, connected end users are 10 on Free, 1,000 on Pro, and 10,000 on Business. One end user counts once per workspace however many providers they connect. That meter is closer to "tenants who linked an API" than to "SSO connections."

Keep WorkOS for the employee login. Add a per-tenant provider credential before the agent calls that tenant's API.

A company with 20 enterprise customers shows the gap in the bill. The published table prices SSO at $125 a connection for 1 to 15, and $100 a connection for 16 to 30. Directory Sync is a second connection on the same bands. AuthKit stays free if you are under 1 million monthly active users. Those employees can sign in. If 20 of them also connect Salesforce so an agent can file notes, that is 20 provider credentials, not 20 more SSO connections. WorkOS will not issue the Salesforce tokens because the customer finished Okta setup in the Admin Portal. Someone still has to complete the Salesforce consent screen. Vault can hold a secret you place in it. You still need a runtime that picks the secret up and attaches it to the call without putting it in the prompt. Budget the SSO line and the credential line as separate items, or you will launch login and discover the agent cannot act.

Connect the provider, not only the IdP

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry for the third-party API and add methods from the local list. Run the connect once per tenant if each customer has their own account, so a tenant token cannot be used for a method you did not review.

swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs.

swy auth connect <provider>
swy policy validate

Let employees sign in with WorkOS. Let the agent call a provider only after that provider's credential is connected and the method is on the allowlist. An Okta connection does not create the Salesforce token the agent will send on the call. Budget the SSO line and the provider credential as two items. Treat sign-in and the API connection as separate setup steps.

Related reading

• A credential per customer. SSO does not create these tokens.
• Credential brokering. Keep the provider secret out of the model.
• Managed OAuth providers. How hosted OAuth differs from an IdP connection.
• Policy as code. The employee can be allowed in, and the write still denied.

FAQ

Is a WorkOS SSO connection the same as a linked API account?

No. An SSO connection bills the relationship with an identity provider. A linked API account is a token for a product API. A customer can have Okta turned on and still have zero Salesforce tokens.

What does WorkOS Vault store?

The docs describe encrypted objects, with optional customer-managed keys. That is storage and access control for secrets you put there. It does not, on those pages, select a method and attach the secret as the call leaves.

How much is SSO plus Directory Sync for one customer?

At the 1 to 15 band, each product is $125 a connection. Both products are two connections, $250 a month. AuthKit MAUs are a separate line and are free until 1 million.

Do I still need SSO if the agent has API credentials?

Yes, if humans from that company log in to your app. The agent credential does not replace SAML for those people. The SAML login does not replace the agent credential for the provider call.