As a SOC 2 Type 2 certified platform, wxrks lets you replace individual wxrks passwords with Single Sign-On (SSO) — your team signs in using the credentials they already have with your company's identity provider, and wxrks never sees or stores those credentials. This article covers how to connect each supported provider, plus automated user provisioning via SCIM.
💡 Who is this for? This guide is for Account Admins who need to connect an identity provider for Single Sign-On and configure automated user provisioning within the wxrks platform.
How SSO works with wxrks
Once SSO is configured, a user signing in is redirected to your identity provider to authenticate. After the provider verifies the user, it sends wxrks a secure token confirming who they are, and wxrks signs them in — no wxrks password involved. Every configuration is scoped to your account: an identity provider only ever authenticates users who already exist in your wxrks account, matched by email address.
Supported identity providers
wxrks currently supports SSO with:
Okta
OneLogin
Azure AD (Microsoft Entra ID) — only when login is initiated from the wxrks login page, and only once a custom domain is configured for your account (under Settings > Account Settings > Branding). Without a custom domain, Azure AD login isn't available.
All three are configured in the same place: go to Settings > Account Settings > SSO. That page has two tabs — SSO and Provisioning — and the SSO tab itself holds three cards:
SSO Provider Configuration — the SSO URL, Client ID, and Secret your identity provider gives you. All three are required before Save Configuration becomes clickable.
Integration URLs — the redirect and initiate-login URLs wxrks generates for your account, one set per provider. These contain a key unique to your account, so treat them like a credential: only ever paste them into your identity provider's own configuration, never share them elsewhere.
Advanced Settings — appears once an SSO URL is saved. Currently this only covers Okta Authorization Server Mode (see the Okta section below); it has no equivalent for OneLogin or Azure AD.
One important difference between providers: wxrks's own login page shows a direct sign-in button only for Azure AD ("Sign in with Microsoft SSO"). Okta and OneLogin logins are identity-provider-initiated instead — your users start from the wxrks application tile in their Okta or OneLogin dashboard, not from the wxrks login page.
Setting up Azure AD (Microsoft Entra ID)
Azure AD SSO requires a custom domain on your wxrks account first (Settings > Account Settings > Branding) — without one, the redirect URL below won't resolve and the sign-in button won't appear on your login page.
In wxrks
Go to Settings > Account Settings > SSO and copy your account's Azure Redirect URI from the Integration URLs card (shown above) — it follows the pattern
https://app.wxrks.com/oauth2/azure/<account_uuid>.
In the Azure portal
Open portal.azure.com and sign in.
Go to Azure Active Directory > App Registrations and select New registration.
Give it a name (e.g. wxrks Single sign-on). Under "Who can use this application?", choose Accounts in this organizational directory only (Single tenant).
For Redirect URI, select Web and paste the URL you copied from wxrks. Click Register.
Go to Certificates & secrets and create a new Client secret. Give it a description that identifies wxrks, set an expiration, and save the secret value immediately — it's only shown once. Set a calendar reminder before it expires: once it does, wxrks can no longer sign users in until you rotate it.
Go to Enterprise Applications, select the app you just created, and under Users and groups add whoever should be able to sign in to wxrks via Azure AD.
Back in wxrks
On the SSO tab, enter the SSO URL (Azure's OAuth 2.0 v2 authorization endpoint), Client ID (the app's Application ID), and the Client Secret you saved, then click Save Configuration.
Signing in with Azure AD SSO
Once saved, a Sign in with Microsoft SSO button appears on your account's wxrks login page, below the normal email/password form.
Setting up Okta
Create the application in Okta
In your Okta admin dashboard, go to Applications > Applications and click Create App Integration. Choose OIDC - OpenID Connect as the sign-in method and Web Application as the application type.
In the New Web App Integration screen, name the app and paste your account's Okta Sign-in redirect URI (from the wxrks Integration URLs card shown earlier) into Sign-in redirect URIs.
Limit access to the right groups
Under Assignments, set Controlled access to Limit access to selected groups and choose the Okta groups that should be able to sign in to wxrks. Anyone in a selected group can log in via SSO, as long as their Okta email matches their wxrks account email exactly.
Save the application.
Set the login options
In the app's General Settings, click Edit and, under LOGIN: confirm the Sign-in redirect URI is correct, set Login initiated by to Either Okta or App, enable Application visibility for the selected groups, and paste your account's Okta Initiate Login URI (also from the wxrks Integration URLs card) into Initiate login URI.
Save.
Enter the Okta details in wxrks
Back on the wxrks SSO tab, enter the Client ID, Client Secret, and SSO URL (your Okta domain, e.g. https://your-company.okta.com) into the SSO Provider Configuration card and click Save Configuration.
If your Okta organization uses a custom authorization server (Okta API Access Management) rather than the default org authorization server, set that under the Advanced Settings card's Okta Authorization Server Mode — choose API Access Management (Custom Authorization Server) or Org Authorization Server to match how your Okta org is configured, then Save Advanced Settings. This card only appears after an SSO URL has been saved.
Signing in with Okta SSO
Once assigned, users sign in by opening the wxrks tile from their Work applications in Okta — they don't use the wxrks login page for this. Opening the tile redirects them straight into wxrks, already signed in.
Setting up OneLogin
Add and name the app
In your OneLogin administrator dashboard, go to Apps > Add App, search for OIDC, and select OpenId Connect (OIDC). Give the app a descriptive name (e.g. wxrks SSO); an icon is optional.
Enter your wxrks URLs into OneLogin
In the app's Configuration section, paste your account's OneLogin URLs from the wxrks Integration URLs card: the Provider Init URL goes into OneLogin's Login Url field, and the Sign-in redirect URL goes into Redirect URL's.
Click Save.
Copy your OneLogin credentials
In the app's own SSO tab (inside OneLogin), copy the Client ID, Client Secret, and Issuer URL.
Enter the OneLogin details in wxrks
On the wxrks SSO tab, paste the Issuer URL into SSO URL, along with the Client ID and Secret, then click Save Configuration.
One easy mistake: OneLogin's Issuer URL is often a long path (e.g. https://your-company.onelogin.com/oidc/2) — wxrks only needs the base URL up to the domain, e.g. https://your-company.onelogin.com. Trim it before pasting, or the connection will fail.
Automated user provisioning with SCIM
The Provisioning sub-tab (next to SSO on the same page) configures SCIM — a standard that lets your identity provider automatically create, update, and remove wxrks users as people join, change roles, or leave, instead of managing them by hand in wxrks.
This tab gives you everything your identity provider needs on its side:
SCIM Base URL — your account's unique SCIM endpoint, ready to copy.
Secret Token — click Generate to create one. It's shown only once, so copy it immediately; if you lose it, generate a new one and update your identity provider's configuration to match.
Role Mapping — pairs a role name from your identity provider with the matching wxrks role (e.g. Project Manager, Account Admin, Client, Vendor). Add one row per role you want auto-assigned, via Add Role Mapping.
Default Organizational Unit — the Org Unit new SCIM-provisioned users are placed into automatically.
A status line at the bottom shows the last time SCIM created a user, so you can confirm the sync is actually running.
The exact steps for connecting SCIM differ by identity provider. For a full, provider-side walkthrough (creating the enterprise application, mapping attributes, assigning users and groups), see Set Up SCIM Provisioning with Azure AD — it also covers using the same identity-provider application for both SCIM and SSO at once, which is the recommended setup.
Managing your SSO configuration
On the SSO Provider Configuration card, once a configuration exists you also get:
Rotate SSO Key — issues a new signing key for your account's Integration URLs. Every URL you copied into your identity provider changes as a result, so you'll need to update them there right after rotating, or SSO logins will start failing.
Remove SSO Configuration — clears the SSO URL, Client ID, and Secret entirely, turning SSO off for the account. Users fall back to their normal wxrks email and password.
Troubleshooting
A user gets an error signing in via SSO. The most common causes:
Their email address in the identity provider doesn't exactly match their wxrks user's email — SSO matches users by email, so any difference (typo, alias, different domain) will fail.
They aren't assigned to the wxrks application/group on the identity provider side, even though wxrks itself is configured correctly.
The account's SSO key was recently rotated, but the identity provider still has the old Integration URLs.
For Azure AD specifically: the account doesn't have a custom domain configured yet, or the Client secret in Azure has expired.
If none of these explain it, reach out to [email protected] or search the wxrks Community forum — include the approximate time of the failed attempt so support can check the account's authentication logs.
Related articles
All about Settings — where the SSO tab fits among every other Account Settings tab.
Set Up SCIM Provisioning with Azure AD — the full SCIM walkthrough on the Azure AD side.