Skip to main content
SSO Providers let your organisation’s people sign in to Pria with the account they already have — through an external identity provider such as QuickLaunch, Okta or Azure AD, using the OAuth 2.0 Authorization Code flow. Once configured, users visit a dedicated URL (/sso/{slug}) and are logged into Pria automatically. Pria’s SSO uses OAuth 2.0 / OpenID Connect; SAML 2.0 is an enterprise arrangement — contact humans@praxis-ai.com.
SSO Providers require the SSO admin entitlements (sso.list, sso.add, sso.edit, sso.delete). See Entitlements for details.

​
How SSO Works

When a user visits the SSO login URL, Pria redirects them to the identity provider for authentication. After the user authenticates, the identity provider sends an authorization code back to Pria, which exchanges it for user information server-side.
The authorization code is one-time use and can only be exchanged for a token using the client secret, which only the backend has. The client secret never reaches the browser.

​
Managing SSO Providers

Open Admin → SSO (the SSO Providers List) to manage your Digital Twin’s SSO configuration. You need an admin account type as well as the SSO entitlements.

​
Creating a Provider

1

Open SSO Providers

Open Admin → SSO and select Add; the New SSO Provider dialog opens.
2

Select the Digital Twin

Choose it in Instance and give the provider a Label. Each Digital Twin can have one SSO provider, and it needs at least one Public Authorized URL (SSO sign-ins land on the first one).
3

Choose a short name for the web address (the Slug)

Use lowercase letters, numbers and hyphens only — for example my-university. Your people will sign in at https://your-domain.com/sso/my-university.
4

Configure OAuth Endpoints

Enter the identity provider’s OAuth 2.0 endpoints (Client ID, Client Secret, Token Host and User Info URL are required):
5

Configure Field Mapping

Map identity provider user fields to Pria user fields. These defaults match most OpenID Connect providers:
If your identity provider uses different field names (e.g., mail instead of email), update the mapping accordingly. Incorrect mapping will prevent user accounts from being created.
6

Enable and Save

Toggle Enabled to activate the provider, then save. The SSO login URL is immediately active.

​
Testing Connectivity

After saving, use Test Connection (Connection Test in the Studio UI) to check that Pria can reach the identity provider’s token endpoint. The SSO Login URL shown on the provider is the address to give your people.

​
Callback URL Registration

You must register the callback URL with your identity provider. The callback URL follows this pattern:
For example, if your domain is pria.praxislxp.com and the slug is my-university:
The callback URL must match exactly what is registered with the identity provider. A mismatch will cause an invalid_callback error.

​
User Experience

​
SSO Login Flow

When a user visits /sso/{slug}:
  1. If the provider is enabled, the user is redirected to the identity provider’s login page
  2. After authenticating, a new address gets a Pria account and a membership of the Digital Twin. Someone who already has a Pria account must already be a member of that Digital Twin (having joined it themselves); otherwise they are asked to sign in with their email and password instead. Admin accounts are asked for an emailed code
  3. If the user already has an active session, they see options to Logout or Continue

​
Error Handling

​
Required Entitlements

SSO Provider management requires the following admin entitlements:
These entitlements are managed on the Entitlements page. An admin must have the appropriate SSO entitlements assigned on their Digital Twin membership.

​
Security

  • Client secrets are stored in the database and masked in API responses and the admin UI
  • The authorization code exchange happens server-to-server; the client secret never reaches the browser
  • New SSO users are enrolled in the Digital Twin associated with the provider; existing accounts must already be members
  • Changes to Enabled, the scope and the field mapping apply at the next sign-in; a changed client ID, secret or host can take a short while to apply everywhere