Overview
Velantix Axiom™ is listed in the Okta Integration Network (OIN), with single sign-on via OpenID Connect (OIDC) and automated user lifecycle management via SCIM 2.0. Adding the integration from the catalog creates one Okta application with two tabs — Sign On and Provisioning — that your team can configure, audit, or pause independently of one another. This guide covers both.
Break-glass access: the account that completes setup always keeps password-based login as a fallback, even after SSO is active — so a temporary Okta outage or misconfiguration on your side can never lock your organization out of its own Velantix Axiom™ account.
Quick Reference
Supported Features
- Single sign-on via Okta using OpenID Connect (OIDC), SP-initiated, with just-in-time (JIT) user provisioning on first login.
- Optional IdP-initiated launch from your Okta My Apps dashboard (Part 1, Step 3).
- Automated user lifecycle via SCIM 2.0: create, read, update, and deactivate/reactivate users.
SCIM provisioning actions supported:
- Create users
- Update user attributes
- Deactivate users
- Import users
Not currently supported: Import groups, Sync password, Profile sourcing, Group push. Velantix Axiom™ does not map Okta groups to roles today, and passwords are never synced or shared between Okta and Velantix Axiom™ — each account's Velantix Axiom™ password is set independently by the user.
Not currently supported: Okta group-to-role mapping, SCIM group/entitlement provisioning, and OAuth 2.0-based SCIM authentication (our SCIM app uses static Bearer token / Header Auth only — see the Okta app catalog entry named accordingly in Part 2).
Prerequisites
- Okta administrator access, able to browse the Okta Integration Network (OIN) catalog and assign applications.
- Your Velantix Axiom™ Organization ID, found under Settings → Security once you're logged in.
- For provisioning: a SCIM Bearer Token, generated by you in Velantix Axiom™ Settings (Part 2).
Configuration Steps
Full walkthrough below: add the integration from the OIN catalog, then configure Sign On (OIDC) and Provisioning (SCIM). About 10 minutes total.
Attributes and Mapping
| SCIM Attribute | Velantix Axiom™ Field |
|---|---|
userName |
Email address (unique identifier) |
name.givenName |
First name |
name.familyName |
Last name |
emails[0].value |
Email address |
emailType |
Not used by Velantix Axiom™ — present in the app's default attribute set to satisfy Okta's own provisioning schema. Safe to ignore; nothing to configure. |
Account status (active/inactive) is handled automatically through Okta's own Assign / Unassign / Deactivate actions — it isn't a mapped profile attribute, so there's nothing to configure for it.
Troubleshoot
- Your Organization ID (needed when adding the integration, and for the optional Initiate Login URI) is found under Settings → Security once you're logged in, with a copy button next to it.
- Our SCIM integration authenticates with a static Bearer token, not OAuth 2.0 — if a "Test API Credentials" attempt fails, the most common cause is the API token field missing the literal "Bearer " prefix. It must read
Bearer <token>, not just the token alone. The Base URL is fixed and identical for every customer, so there's nothing to build or double-check there. - Provisioning changes (create, update, deactivate, reactivate) typically take effect within about a minute of the change in Okta.
- Getting a 403 when testing your SSO connection? The Okta user completing setup (Step 2 below) must themselves be active in Okta and assigned to the Velantix Axiom™ integration. This comes directly from Okta's own authorization server, before the request ever reaches Velantix Axiom™ — if that user isn't assigned, Okta rejects the sign-in attempt outright.
Step 1 — Add the integration from the OIN catalog
Velantix Axiom™ is a listed Okta Integration Network (OIN) application. Adding it creates one Okta application with two tabs — Sign On and Provisioning — configured together below.
- Browse the catalog. In the Okta Admin Console go to Applications → Applications → Browse App Catalog, search for "Velantix Axiom", and click Add integration.
- Enter your Organization ID. General Settings asks for your Velantix Axiom™ Organization ID — find it under Settings → Security once you're logged in, with a copy button next to it. This one value is what personalizes the integration to your organization; you won't need to hand-build any URLs.
- Assign users. On the Assignments tab, assign the people or groups who should have Velantix Axiom™ access. This one assignment covers both sign-in and provisioning — Okta group-to-role mapping isn't used today, so any assigned user who completes login is provisioned as a standard portal user. Do this before Step 2 — whoever completes SSO setup must be an active, assigned user themselves, or the live test in the next step will fail.
Sign On (OIDC)
This lets your people sign in to Velantix Axiom™ with their existing Okta credentials. Grant type, PKCE, scopes, and redirect URIs are already configured from the catalog listing — nothing to build by hand.
Choose a setup path
Self-service (recommended). Your account owner signs in to Velantix Axiom™ and goes to Settings → Security → Okta SSO & Provisioning, then clicks Configure — this same screen opens automatically the first time you log in after creating your account (at https://portal.velantixaxiom.com/onboarding/okta-setup), and the same Configure button reopens it any time afterward if you missed it then. Enter your Issuer URL, Client ID, and Client Secret — see Step 2 below for exactly where to find each of these in Okta. Velantix Axiom™ runs a live test against your Okta tenant on the spot — SSO activates automatically the moment the test succeeds, and never activates on a failed test. No waiting on Velantix to configure anything manually.
Before you test: make sure the Okta account you're using to complete this step — not just any account in your org — is active in Okta and assigned to the Velantix Axiom™ integration (Step 1 above). If it isn't, the live test fails with a 403 from Okta directly, before Velantix Axiom™ ever sees the request.
Assisted setup (alternative). Prefer not to enter your Client Secret into a web form? Send Velantix your Issuer URL and Client ID directly — never the secret over email; see "Sharing secrets securely" near the end of this guide — and we'll configure your organization on our end.
Confirm Sign On settings
On the app's Sign On tab, confirm the values below match — they're pre-filled from the catalog listing, so this is a quick check, not manual entry.
| Field | Value |
|---|---|
| Sign-in method | OIDC – OpenID Connect |
| Application type | Web Application |
| Grant type | Authorization Code (with PKCE) |
| Sign-in redirect URI production login |
https://api.velantixaxiom.com/api/v1/auth/sso/callback |
| Sign-in redirect URI self-service activation test |
https://api.velantixaxiom.com/api/v1/auth/sso/self-service/test-callbackOnly needed if using the self-service path — register both URIs if so. This one can be removed after activation; it's only used once. |
| Scopes | openid email profile |
| Sign-out redirect URI | Not required — Velantix Axiom™ does not use Okta-initiated logout. |
Step 2 — Three values we need from you
- Issuer URL — your Okta domain, e.g.
https://yourcompany.okta.com(or your custom domain, if configured) - Client ID — generated automatically when you create the app
- Client Secret — generated automatically; treat this like a password
Both the Client ID and Client Secret can be found in the Velantix Axiom™ Okta app's Sign On tab, under the OpenID Connect section.
What Velantix Axiom™ does with these: the Client Secret is stored as a Cloudflare Workers Secret — never in our database, never in a log, never visible to any Velantix Axiom™ staff member after entry. Your Issuer URL is validated before we ever make a request to it (rejecting anything that isn't a real, public https:// address). SSO only activates for your organization after a live authentication test against your own Okta tenant succeeds.
Step 3 — SP-initiated sign-in (default, no setup needed)
Velantix Axiom™ supports SP-initiated SSO by default: your people go to https://portal.velantixaxiom.com/login, enter their work email, and are redirected to your Okta tenant to authenticate — landing back in Velantix Axiom™ once Okta confirms their identity. This works as soon as Step 2 above is complete; nothing further to configure.
Step 4 — Optional: launch from your Okta dashboard (IdP-initiated)
By default your people can only sign in by starting at the Velantix Axiom™ login page (SP-initiated, above) — the app tile in your Okta dashboard (My Apps) won't do anything until this step is done. This applies whether you used Self-Service or Assisted Setup above.
On the Okta app's General tab, find Login initiated by and change it to Either Okta or App. A new Initiate Login URI field appears — build it from the pattern below, using your own Organization ID:
https://api.velantixaxiom.com/api/v1/auth/sso/start?org=<your Org ID>
Find your Organization ID once you're logged in, under Settings → Security — it has a copy button next to it.
Provisioning (SCIM)
This automatically creates, updates, and deactivates Velantix Axiom™ accounts as people join, change roles, or leave — independent of the Sign On tab above. The Base URL is fixed and identical for every Velantix Axiom™ customer — nothing to build or personalize — and you generate your own Bearer Token directly from your account, with no wait on Velantix.
Step 5 — Generate your SCIM Bearer Token
Log into Velantix Axiom™, go to Settings → Security → Okta SSO & Provisioning, and click Generate / Rotate Token. The token is shown exactly once — copy it immediately. It can't be retrieved again; if you lose it, generate a new one (this immediately invalidates the old one, so you'll need to update it in Okta too).
Step 6 — Configure the Provisioning tab
- Open Provisioning. On the Velantix Axiom™ integration you added in Step 1, go to the Provisioning tab and choose Configure API Integration.
- Base URL is pre-filled. Because Velantix Axiom™ is a published OIN catalog integration, this field is already set for you — no personalization, no Organization ID, nothing to enter:
Just confirm it matches the value above, then continue.
https://api.velantixaxiom.com/api/v1/scim/v2 - Enable it and enter your Bearer Token. Check Enable API integration, then enter the token from Step 5 into the API token / Authorization header field exactly as
Bearer <your token>— the wordBearerand a space must be typed in front of the token itself; the field does not add this for you. Click Test API Credentials to confirm the connection. - Enable provisioning actions. Under To App settings, enable Create Users, Update User Attributes, and Deactivate Users.
SCIM configuration values
| Field | Value |
|---|---|
| Base URL | https://api.velantixaxiom.com/api/v1/scim/v2 — pre-filled automatically, nothing to enter |
| API Token / Authorization header | Bearer <token you generated> — the word "Bearer " must be typed in front of the token |
| Unique identifier field for users | userName |
| Supported provisioning actions | Create Users, Update User Attributes, Deactivate Users |
| Group push | Not used — Velantix Axiom™ does not map Okta groups to roles today |
You're done
- Nothing further to assign. The Step 1 assignment already covers provisioning — the same people or groups get both sign-in and lifecycle management, since this is one integration.
- Nothing to send back for this part. Provisioning goes live as soon as the credential test passes. Adding, updating, or unassigning someone in Okta takes effect automatically.
- Try it. Unassign a test user to confirm they're deactivated in Velantix Axiom™, then reassign them to confirm they come back — both typically take effect within a minute.
Complete checklist
- Velantix Axiom™ added from the Okta app catalog
- Organization ID entered in General Settings
- People assigned to the integration
- Issuer URL / Client ID / Client Secret sent (or entered via self-service)
- SP-initiated sign-in confirmed working (default, no setup needed)
- (Optional) Login initiated by: Either Okta or App, with your own Initiate Login URI built from your Organization ID
- SCIM token generated in Settings → Security → Okta SSO & Provisioning, copied immediately
- Provisioning tab: API integration enabled, Base URL entered (fixed value, same for every customer)
- API token entered with the literal "Bearer " prefix in front of the token value
- Test API Credentials passed
- Create / Update / Deactivate Users enabled
- Test unassign/reassign confirmed working
Good to know
Why two tabs instead of one setting?
Sign On and Provisioning are independent concerns within the integration, so you can audit, pause, or reassign either one without touching the other — even though it's a single application to add and assign.
Managing your team directly in Velantix Axiom™
Once you're set up, your organization's owner can view and manage everyone in your organization directly from the Velantix Axiom™ portal — no need to wait on Okta or contact Velantix support for routine changes. From Settings → Team (visible only to organization owners), an owner can rename teammates, activate or deactivate accounts, invite new teammates directly, and grant org-owner status to others. This works for both SCIM-provisioned and directly-invited users — though a SCIM-managed teammate's name may be overwritten the next time Okta syncs, since Okta remains the ongoing source of truth for anyone provisioned that way.
Sharing secrets securely
If using Assisted Setup, do not send your Client Secret by email. Use a password manager's secure share link, or let us know and we'll set up a one-time secure transfer method. Your SCIM Bearer Token never needs to be sent anywhere — you generate it directly in Settings and paste it straight into Okta.
Questions during setup?
Reach out any time — we're glad to join a call and walk through the integration together if useful.
Contact Us →