Skip to main content
SSO Providers allow your institution to authenticate users through an external identity provider (e.g., QuickLaunch, Okta, 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.
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

Navigate to Admin > SSO Providers (/admin/sso) to manage your institution’s SSO configuration.

Creating a Provider

1

Open SSO Providers

Navigate to Admin > SSO Providers and click Add SSO Provider.
2

Select Institution

Choose the institution this SSO provider belongs to. Each institution can have one SSO provider.
3

Set the Slug

Enter a URL-friendly identifier (lowercase letters, numbers, and hyphens only). This becomes the login URL: https://your-domain.com/sso/{slug}.
4

Configure OAuth Endpoints

Enter the identity provider’s OAuth 2.0 endpoints:
FieldDescriptionExample
Client IDOAuth application client IDilHYXUujI_z1BfNKHpSQ84kDffwa
Client SecretOAuth application client secretStored encrypted, masked in UI
Token HostBase URL for OAuth endpointshttps://id.quicklaunch.io:443
Token PathPath for token exchange/oauth2/token (default)
Authorize PathPath for authorization/oauth2/authorize (default)
User Info URLFull URL for user info endpointhttps://id.quicklaunch.io:443/oauth2/userinfo
ScopeOAuth scopeopenid (default)
5

Configure Field Mapping

Map identity provider user fields to Pria user fields. These defaults match most OpenID Connect providers:
Pria FieldDefault IdP FieldDescription
EmailemailUser’s email address
First Namegiven_nameUser’s first name
Last Namefamily_nameUser’s last name
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 the Test button to verify the backend can reach the identity provider’s token endpoint. This confirms the Token Host URL is correct and accessible.

Callback URL Registration

You must register the callback URL with your identity provider. The callback URL follows this pattern:
https://your-domain.com/sso/{slug}
For example, if your domain is pria.praxislxp.com and the slug is my-university:
https://pria.praxislxp.com/sso/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, the user is automatically logged into Pria and enrolled in the associated institution
  3. If the user already has an active session, they see options to Logout or Continue

Error Handling

ScenarioUser Sees
Provider is disabledRed error banner: “SSO provider '' is currently disabled”
Provider not foundRed error banner: “SSO provider '' not found”
Missing slug (/sso/)Fallback card with links to Login and Sign Up
Identity provider errorError message from the identity provider

Required Entitlements

SSO Provider management requires the following admin entitlements:
EntitlementAllows
sso.listView the list of SSO providers
sso.addCreate new SSO providers
sso.editModify existing SSO providers
sso.deleteDelete SSO providers
These entitlements are managed on the Entitlements page. An admin must have the appropriate SSO entitlements assigned to their institution 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
  • SSO users are automatically enrolled in the institution associated with the provider
  • Provider configuration changes take effect immediately (the OAuth client cache is invalidated on save)