Enterprise · FluxGate with Okta
Troubleshooting Okta
You know where to look when a sync or a sign-in fails, and how to fix the usual causes.
Before you start
Sign in to FluxGate as admin System admin and to the Okta Admin Console.
Where to look
| Place | What it shows |
|---|---|
| FluxGate, Single Sign-On, Provisioning icon of the provider | Last request from Okta, Last error returned by FluxGate, and when each token was last used |
| Okta, Dashboard, Tasks | Provisioning calls that failed, with the error, and a way to retry them |
| Okta, Reports, System Log | Every provisioning call and sign-in, with FluxGate's response |
FluxGate, Audit Log (/dashboard/audit-log) | Every change Okta made (scim_* types) and every SSO event (sso_* types) |
Fix a revoked or wrong token
A common failure: the token Okta uses is revoked, expired, or was rotated in FluxGate and not in Okta. Okta's provisioning calls then fail with 401, and Okta lists them under Tasks.
- In FluxGate, open the Provisioning dialog of the provider, click Create token, name it, and click Create. Click Copy token, then Done.
- In Okta, open
FluxGate provisioning, Provisioning, Integration, Edit. Paste the token, click Test Connector Configuration, then Save. - In Dashboard, Tasks, retry the failed tasks. Okta sends the changes again.
- In FluxGate, revoke the old token if it is still active.
Common problems
"No FluxGate account exists for you. Ask an administrator."
The person signed in, but FluxGate has no account to link. Either Okta has not provisioned the person, because they are not in a group assigned to FluxGate provisioning, or the link pair does not match. Use sub to externalId, and check that Create accounts on first sign-in is off on purpose.
Okta shows a redirect URI error at sign-in
The URI in the sign-in app must equal <public_base_url>/api/v1/auth/sso/<slug>/callback exactly. Check public_base_url and the slug.
A banner says SCIM could not deactivate a user
FluxGate never deactivates the last enabled admin, even when Okta asks. Make another person an admin, then retry the task in Okta.
Roles do not change when groups change
Check that role sync mode is SCIM, that the groups are pushed from FluxGate provisioning, and that each mapping value matches the pushed group name exactly.
Okta's connector test passes but nothing arrives
Check that To App has Create Users, Update User Attributes and Deactivate Users enabled, and that groups, not only single people, are assigned to FluxGate provisioning.
Okta waits and retries
Over the SCIM rate limit, FluxGate answers 429 with Retry-After, and Okta retries. A first sync of many users can take a while. Raise the limit in the backend configuration if needed.
Next
That completes FluxGate with Okta. For every SCIM setting, see Single sign-on and the backend configuration reference.