Skip to main content
Enterprise single sign-on lets your organization’s users sign in to Pria with the same credentials they already use for email, payroll, and every other internal app. Pria delegates authentication to your identity provider (IdP); the IdP enforces password policy, MFA, conditional access, and account lifecycle, and tells Pria who the user is. You connect one identity provider per Digital Twin. Each gets its own sign-in address on your Pria site — https://your-domain.com/sso/<slug>, where <slug> is a short name you choose in step 3 — and from there users are redirected straight to the IdP.

​
What enterprise SSO does for you

  • Single sign-on across your organization. If the user is already signed in at the IdP, they reach Pria without seeing a Pria login form.
  • Centralized account lifecycle. Disable the user at the IdP and they can no longer reach Pria. No Pria-side password to rotate.
  • IdP-enforced security. MFA, conditional access, IP allowlists, and device posture are all evaluated at the IdP. Pria inherits whatever the IdP says.
  • Just-in-time user provisioning. The first time a new person signs in with SSO, Pria automatically creates their account and adds them to the linked Digital Twin. No bulk import step required.

​
Supported protocols

For OAuth2/OIDC, Pria runs the Authorization Code flow: the user is redirected to the IdP, signs in, and is redirected back with a one-time code. Pria exchanges the code for an access token server-to-server and reads the user profile from the IdP’s userinfo endpoint.

​
Setting up an OAuth2 / OIDC provider

1

Register Pria as an application in your IdP

In your IdP’s admin console, create a new OIDC web application (sometimes called Web App, Regular Web Application, or Confidential Client). You’ll get back a Client ID and Client Secret.Register Pria’s callback URL with the IdP:
Where <slug> is the short identifier you’ll choose in step 2 (e.g. acme-okta, myuniversity). The callback URL must match exactly what you’ll register on the Pria side, including capitalization and trailing characters.
2

Create the provider in Pria

In Pria, go to Admin → SSO Providers and add a provider — the New SSO Provider dialog opens. (You need the sso.add admin entitlement — see SSO Providers.)Pick the Digital Twin this provider belongs to (the picker calls it an institution — same thing). Each Digital Twin can have one SSO provider.
3

Set the slug and label

The slug is the public route: users will sign in at https://your-domain.com/sso/acme-okta.
4

Configure the OAuth2 endpoints

5

Configure field mapping

Pria reads three fields from the IdP’s userinfo response: email, first name, last name. (A claim is one named field in the user profile your identity provider returns — email, given_name, and so on.) Defaults match standard OIDC claims:Override these only if your IdP uses non-standard claim names (e.g. mail instead of email, firstName instead of given_name).
An incorrect email mapping is the #1 SSO setup failure. If the IdP returns null for whatever Pria thinks is the email claim, account creation fails with a confusing “invalid account” error.
6

Enable and test

Toggle Enabled on, save, and visit https://your-domain.com/sso/<slug> in an incognito window. You should be redirected to the IdP, sign in, and land back in Pria.Once the provider is saved, use Test Connection in its editor to check that Pria can reach the Token Host before doing the round-trip test.

​
Who can sign in through SSO

Just-in-time provisioning only creates the user record. It does not assign admin entitlements. New users are normal members of the Digital Twin; an existing admin must promote them if needed.
If you import people who already have Pria accounts, ask them to sign in once with their email and password and open your Digital Twin; from then on the SSO address signs them in.

​
Disabling a provider without deleting it

You can flip the Enabled toggle off at any time. The provider configuration is preserved (client ID, secret, endpoint URLs, field mapping) but the SSO URL stops working: visitors see a red banner reading SSO provider '<slug>' is currently disabled. This is the right move for an emergency shutoff, a maintenance window, or while you migrate the IdP-side configuration. To re-enable, just flip the toggle back on. Deleting the provider entirely removes the configuration. Existing SSO-provisioned users keep their Pria accounts — they just can’t sign in via this provider anymore. They can still sign in by any other method tied to their email (e.g. a password they set, social login).

​
Multiple SSO providers

Each Digital Twin can have one identity provider connected at a time. If you need two — say Okta for staff and a separate Auth0 tenant for contractors — the standard pattern is to:
  1. Set up two Digital Twins, one per identity provider.
  2. Connect a different SSO provider to each.
  3. Give people membership of whichever twin they need (or both), depending on access requirements.
For more complex multi-IdP setups, contact the Praxis AI team at humans@praxis-ai.com.

​
Sample IdP setups

  1. In the Okta admin console, Applications → Create App Integration → OIDC - OpenID Connect → Web Application.
  2. Sign-in redirect URIs: https://your-domain.com/sso/<slug>.
  3. Grant type: Authorization Code (enabled by default).
  4. Copy the Client ID and Client Secret from the app’s General tab.
Pria settings:Default field mapping (email, given_name, family_name) works as-is with Okta.
  1. In the Entra admin center, App registrations → New registration. Set Redirect URI (Web) to https://your-domain.com/sso/<slug>.
  2. Under Certificates & secrets, create a new client secret. Copy the value immediately — it isn’t shown again.
  3. Under API permissions, add Microsoft Graph delegated permissions: openid, profile, email.
  4. Note the Application (client) ID and the Directory (tenant) ID.
Pria settings:Default field mapping works for Entra ID’s OIDC userinfo response.
  1. In the Auth0 dashboard, Applications → Create Application → Regular Web Applications.
  2. Allowed Callback URLs: https://your-domain.com/sso/<slug>.
  3. Copy the Client ID and Client Secret from the application’s Settings tab.
Pria settings:Default field mapping works with Auth0.
  1. In Google Cloud Console → APIs & Services → Credentials, create an OAuth 2.0 Client ID of type Web application.
  2. Authorized redirect URIs: https://your-domain.com/sso/<slug>.
  3. Copy the Client ID and Client Secret.
Pria settings:For a simpler integration that also lets users authorize Gmail/Drive/Calendar, prefer the Google Workspace connection — it covers more ground than a vanilla OIDC SSO setup.

​
Common errors

For other failures, look at the IdP-side log first — it will tell you whether the token request even reached the IdP and what was wrong with it.