Skip to main content
This guide connects Okta to Paxos SCIM. Read How It Works first — the behaviors it describes apply here, and the setting names below are Okta’s. Okta owns these screens and may change them; for their latest steps, see Okta’s Build a SCIM provisioning integration documentation.
Before you begin, complete Set Up in the Dashboard — you’ll need the Client ID and Client Secret from the API credential you created. SSO with Okta must already be working.

​
➊ Create the app with the OIN Wizard

Build the integration with Okta’s OIN Integration Wizard:
  1. In your Okta org, open the OIN Integration Wizard and start a new integration.
  2. For provisioning, choose SCIM 2.0 with OAuth 2.0 authentication (not the bearer-token option) — OAuth is required for the authorization-code + refresh-token flow.
  3. The wizard asks for a lot of submission and test details (test accounts, descriptions, and similar). You are not submitting this integration to Okta, so enter placeholder values wherever a field doesn’t apply to your setup.
  4. Continue only until Okta creates the application in your org. You don’t need to finish or submit the integration for review.
The integration needs these provisioning capabilities — Users: import, profile updates, deactivation, and PATCH support; Groups: create, read, update, and delete. Leave password sync and user-schema import off. Set these in the wizard, or on the app’s Provisioning tab after it’s created.
Don’t use a custom Create App Integration → SCIM 2.0 app — it only supports a static bearer token, not the OAuth 2.0 flow this integration requires.

​
➋ Configure OAuth and authenticate

On the app’s Provisioning tab, configure the API integration with your OAuth details:
  • The Client ID and Client Secret from your API credential.
  • The Authorization and Token endpoints for your environment:
Okta uses a redirect URI of the form:
unique to your Okta org and app instance. This is the value you enter under Redirect URIs when you create your API credential — it must match exactly, or authentication fails with a redirect_uri does not match error. Click Authenticate. Okta redirects you to the Paxos Dashboard to authorize the credential for the scim:read and scim:write scopes. Sign in and approve.

​
➌ Enter the SCIM base URL

In the next step, set the SCIM base URL for your environment:
  • Sandbox: https://api.sandbox.paxos.com/v2/scim
  • Production: https://api.paxos.com/v2/scim
Then enable Users and Groups as supported objects, and configure the settings below.

​
➍ Push to the Dashboard (“To App”)

These control what Okta pushes to the Dashboard: Leave the default attribute mappings. The Dashboard reads only userName, email, and the name attributes (displayName, givenName, familyName) and ignores anything else, so there’s no need to trim them.

​
➎ Import from the Dashboard (“To Okta”)

Importing lets Okta discover and match users who already have Dashboard access — useful when enabling SCIM for an existing Organization.
  • Import Users on; match by email, exact match, with partial-name matching off.
  • Okta username format: Email — set the username to the appuser.email expression so imported users match the Dashboard by email.
  • Auto-confirm exact matches off while testing, on for production.
  • Import Groups off — group membership already flows from Okta at sign-in.
Okta imports on a schedule and on demand (Import Now). Only users who have already signed in appear in an import — a user who hasn’t been JIT-created won’t show up yet.

​
➏ Push groups and map roles

  • On the Push Groups tab, push a group by name. Choose Create Group if none exists, or Link to an existing one — pushing never creates duplicates.
  • Map the group to one or more Roles at Admin > Team Management > Mapping. Membership grants no access until it’s mapped. See SSO Access for how to create mappings.

​
Okta-Specific Notes

  • Suspend ≠ Deactivate. Suspending a user in Okta sends no SCIM signal and has no effect. Use Deactivate or Unassign to remove Dashboard access.
Deprovisioning removes a user’s Dashboard account, not just their access. See Removing and Limiting Access before you deactivate or unassign production users.

​
Verify

Test in a non-production environment first:
  1. Sign a test user in via SSO — confirm they appear Active in Admin > Team Management > Users with the expected Roles.
  2. Run Import Now — confirm the user is matched by email.
  3. Deactivate the user — confirm their Dashboard access is removed.
Once verified, enable auto-confirm exact matches and roll out to your production users.
Questions? Contact Support.