Skip to main content
Pria supports several ways for users to sign in, from a familiar email + password flow with optional two-step verification, all the way to enterprise single sign-on against your organization’s identity provider. Each method ends the same way: an authenticated session bound to a user account and (optionally) an institution. This page is the orientation map. Follow the links into each method for setup, configuration, and troubleshooting.

​
Authentication options at a glance

MethodWho configures itBest forMulti-factor
Email + passwordEvery user (self-serve)Individuals, small teams, fallback pathYes — via Two-Step Verification
Google / GitHub / FacebookPer provider in environmentQuick sign-up, consumer-style flowsInherited from the social provider
Enterprise SSO (OAuth2 / OIDC)Admin, per institutionUniversities, companies with an IdPEnforced at the IdP (Okta, Entra ID, etc.)
Personal API keyAdmin user (self-serve)Scripts, integrations, the Pria SDKN/A — keys grant the holder’s permissions
LMS launch (LTI 1.3)Admin in the LMS + PriaEmbedding Pria inside Canvas, D2L, BrightspaceInherited from the LMS
SDK launch (HMAC)Developer + AdminEmbedding Pria in your own web appServer-signed launch tokens

​
Email + password

The default path. Users sign up with an email address, verify it, and pick a password. From the Two-Step Verification page they can enable an email-based second factor — a 6-digit code sent to their inbox at sign-in, with a “trust this device” option so verified devices aren’t re-prompted for a configurable period. Admins get a post-login enrollment nudge, and can rescue locked-out users (disable a user’s two-step verification and revoke their trusted devices) from the admin Users page — see MFA (admin guide).

Two-step verification (user guide)

Add an email-based second factor to your own account and manage trusted devices.

​
Social login

Users can sign in with an existing account at Google, GitHub, or Facebook. Pria runs the OAuth 2.0 Authorization Code flow server-to-server — no client secret ever reaches the browser — then either signs the user in or creates a new account on first use (just-in-time provisioning).

Social Login (Google, GitHub, Facebook)

Provider-by-provider setup, scopes, redirect URLs, and account-merging behaviour.
For Google specifically, an institution admin can configure a shared institution OAuth client so every member of the institution authenticates against the institution’s Google app rather than the platform default. See Google Workspace integration.

​
Enterprise SSO

For organizations that already run an identity provider (Okta, Entra ID, Auth0, Google Workspace, QuickLaunch, etc.), Pria supports OAuth 2.0 / OpenID Connect out of the box. Each provider is configured per institution with its own slug-based login URL: https://your-domain.com/sso/<slug>.

Enterprise SSO

Configure OAuth2/OIDC SSO end-to-end — IdP setup, field mapping, JIT provisioning, sample setups for major IdPs.
SAML 2.0 and SCIM are enterprise features. Contact the Praxis AI team at humans@praxis-ai.com to discuss SAML or SCIM requirements.

​
API keys (programmatic access)

Admin users can mint a single personal API key from their profile page. The key acts as a long-lived credential for SDKs, scripts, and CI integrations. The exchange is two-step:
  1. Send the raw pria_… key as the x-api-key header to POST /api/auth/api-key-signin.
  2. Use the returned JWT as Authorization: Bearer <token> for subsequent API calls.
APIKEY=pria_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
JWT=$(curl -sS -X POST "https://pria.praxislxp.com/api/auth/api-key-signin" \
       -H "x-api-key: $APIKEY" \
       | python -c "import json,sys; print(json.load(sys.stdin)['token'])")
curl -s -H "Authorization: Bearer $JWT" https://pria.praxislxp.com/api/user/profile
Sending the raw pria_… value as a bearer token returns Invalid access token jwt malformed. Always exchange it for a JWT first.

Personal API keys

Generate, rotate, and revoke your personal API key.

​
LMS launches (LTI 1.3)

When Pria is embedded inside Canvas, D2L (Brightspace), or any LTI 1.3-compliant LMS, the launch itself authenticates the user. The LMS signs a launch token; Pria verifies it, creates or maps a Pria user to the LMS user, and drops them straight into the embedded experience — no second sign-in.

Canvas (LTI)

Embed Pria in Canvas courses, assignments, and theme.

D2L / Brightspace (LTI)

Add Pria as an LTI tool in D2L Brightspace.

​
SDK launches (HMAC-signed tokens)

The Pria Web SDK lets you embed a Digital Twin in your own web or mobile app. Your backend signs a short-lived launch token with a shared secret; Pria verifies the signature and either signs an existing user in or creates one on the fly.

Pria Web SDK

Embed a Digital Twin in your own application with signed launch tokens.

​
Choosing the right method

I'm an individual

Email + password, optionally with two-step verification. Use social login if you’d rather not manage another password.

My team uses an IdP

Set up Enterprise SSO. Users keep their existing IdP credentials and you get central account control.

I'm embedding Pria in our LMS

Use the LTI 1.3 integration for your LMS. Authentication happens at launch.

I'm embedding Pria in our app

Use the Web SDK with HMAC-signed launch tokens from your backend.

I'm scripting against the API

Mint a personal API key, exchange it for a JWT, call any documented API.

I want consumer-style sign-up

Enable social login (Google, GitHub, Facebook) for the lowest-friction sign-up flow.