Farside ResearchStart researching

Docs / SCIM / Okta

Set up SCIM provisioning with Okta

Push your Okta users and groups into Farside, and let Okta deactivate them when someone leaves. Plan on about fifteen minutes. Available on the Enterprise plan.

Before you start

  • You are an owner or admin of the Farside workspace.
  • You can administer applications in Okta.
  • You have the Farside SCIM base URL: https://api.farsideresearch.com/scim/v2

Create a provisioning token

An owner or admin creates the token in Farside under Settings, then Security, then Provisioning. Give it a name you will recognize later, such as the identity provider it belongs to.

Farside shows the token once. Copy it somewhere safe before you close the dialog, because it cannot be shown again. If you lose it, rotate the token and paste the new one into your identity provider. You can revoke a token at any time, and a workspace can have up to 5 active tokens.

Add the Farside app in Okta

  1. In the Okta Admin Console, go to Applications and choose Create App Integration. Pick SAML 2.0 and finish the wizard if you do not have a Farside app yet. If you already sign in to Farside through a SAML app in Okta, open that app instead.
  2. On the app's General tab, find App Settings and choose Edit. Set Provisioning to SCIM and save. A Provisioning tab appears next to Sign On.
  3. No SAML app yet and you only want provisioning? Add SCIM 2.0 Test App (Header Auth) from the Okta Integration Network instead. It comes with the SCIM connector and header authentication already set up.
  4. Okta's wording shifts a little between versions. What you need is an app with a SCIM connector, so look for that option if the labels differ.

Configure the SCIM connector

Open the Provisioning tab, choose Integration, then Edit, and fill in the connector settings as below.

Okta fieldValue
SCIM connector base URLhttps://api.farsideresearch.com/scim/v2
Unique identifier field for usersuserName
Supported provisioning actionsPush New Users, Push Profile Updates, Push Groups
Authentication ModeHTTP Header
AuthorizationBearer, a space, then your fss_ token (for example Bearer fss_...)
  1. Select Test Connector Configuration. Okta should report that the connector works. A 401 here means the token is wrong or revoked.
  2. Save the integration.

Turn on provisioning actions

Still on the Provisioning tab, open To App and choose Edit.

  1. Enable Create Users, Update User Attributes and Deactivate Users.
  2. Save. Keep userName mapped to the person's email address (Okta's default for most orgs). Farside refuses a userName that is not an email. Leave the other default mappings alone unless you have a reason to change them.

Assign people and push groups

  1. On the Assignments tab, assign the people or groups who should have Farside access. Okta sends each assigned person to Farside, which adds them right away or emails them an invitation if their domain is not verified.
  2. Open the Push Groups tab. Choose Push Groups, then Find groups by name or by rule, pick the groups you want, and save. Okta creates them in Farside and keeps their members in sync.
  3. In Farside, an admin maps each pushed group to a role: Admin, Member or Read only.

What to expect once it is running

Groups pushed from your identity provider show up in Farside, where an admin can map each one to a Farside role: Admin, Member or Read only. The mapping lives in Farside, so changing a role never means editing the connector.

SCIM never changes an owner, and the last owner of a workspace cannot be removed this way.

Deactivating or deleting a user removes their membership in this workspace, revokes the API keys they created in it and signs out connected apps for it. Their Farside account and any other workspaces they belong to are untouched.

If a user's email domain is not verified by the workspace, Farside sends them an email invitation instead of creating an instant account. They join once they accept it.

Every SCIM change is written to the audit log.

Troubleshooting

SymptomLikely causeWhat to do
401 UnauthorizedThe token was revoked, rotated, or pasted incorrectly.Create or rotate a token in Settings, Security, Provisioning, then paste the new value. If your provider wants the whole header value, send it as Bearer followed by the token.
400 with scimType invalidValue on a new userThe userName is not an email address.Map userName to the person's email in your provider. Farside uses it as their sign-in address.
400 with scimType mutability on deactivate or a role changeThe person is a workspace owner. Owners are managed in Farside, never by SCIM, and the last owner can never be removed.Change or remove the owner in Farside under Settings, Members. Unassign them in your provider afterwards if you like.
403 seat limit reachedThe workspace has no free seats for another active member.Add seats on the billing page or deactivate someone, then retry the push.
403 on every request with a valid tokenThe workspace IP allowlist blocks your provider's servers. SCIM calls follow the same allowlist as people.Add your provider's published egress IP ranges to the allowlist under Settings, Security.
409 ConflictA user with that userName or email already exists in the workspace.Match the existing person instead of creating a duplicate. Check the userName and email values your provider sends, then retry.
429 Too Many RequestsThe token went over 600 requests per minute.Wait a minute and let the provider retry. For a very large first sync, assign people in batches.
A user got an email invitationTheir email domain is not verified by the workspace.Verify the domain in Farside if you want instant accounts, or have the person accept the invitation.

Last updated November 11, 2026. More on how we protect access is on the security page.