Skip to main content
Social login lets users sign in to Pria with an account they already have — Google, Microsoft, Apple, GitHub or Facebook. Pria runs the OAuth 2.0 Authorization Code flow on the server: the user is redirected to the provider, signs in there, and comes back with a one-time code that Pria exchanges for an access token server-to-server. The provider’s client secret never reaches the browser. On first sign-in, Pria creates a new account from the provider’s profile (email, first name, last name, profile picture). On later sign-ins, the existing account is reused.
There is nothing to set up: the sign-in buttons are configured for Pria’s own site by the Praxis AI team. If your organization needs social sign-in on its own domain, contact humans@praxis-ai.com.

​
Providers

Google is the most-used social login on Pria. Besides the Sign in with Google button, the login page supports Google One Tap — people already signed in to Google in their browser can sign in to Pria with a single click.Scopes requested at sign-in: openid profile email, with offline access so Pria can later reach the optional Google services (Gmail, Drive, Calendar, Sheets, Docs) that the user grants from their profile page.Signing in and using Google Workspace services are separate. Services can be authorized at two levels:
  • Personal (default) — each user authorizes the Google services they want from their own profile page.
  • Shared by the Digital Twin (optional) — a Digital Twin admin connects one shared Google authorization, and every member of that twin gets the connected services without authorizing individually. When both exist, the twin’s shared authorization is used for the services enabled for users. See Google Workspace in the Admin Guide.

​
Signing in

From the Pria login page, select the provider’s button. You are sent to the provider, then back to Pria’s /oauth/success page, then into the app. If something goes wrong, /oauth/success shows an error code in the address — oauth_failure, no_code, invalid_state, state_mismatch, state_expired, no_token, invalid_account, or registration_failed — that helps the Praxis AI team diagnose the failure.

​
Account merging

Pria identifies users by email address. If a user signs in with Google using alice@example.com and an account with that email already exists (whether it was created by email + password, another provider, or SSO), the same Pria account is reused. The new provider becomes an additional way to sign in. This means:
  • A user can sign up with email + password, later sign in with Google using the same email, and land in the same account.
  • A user can switch freely between providers as long as the email matches.
  • Two providers returning different emails for the same person produce two separate Pria accounts. There is no automatic cross-provider linking.
The most common cause of “I have two accounts” support tickets is a user signing up first with alice@gmail.com (Google) and later with alice@example.com (work email). The fix is to merge or change one of the emails.

​
Re-authentication and token refresh

For sign-in, Pria only needs the user to authenticate once — the resulting JWT keeps them signed in. The provider’s access token is not used to authorize later Pria API calls. For Google services (Gmail, Drive, Calendar, etc.) Pria stores the access and refresh tokens so it can call Google on the user’s behalf later, and refreshes expired tokens automatically. If the user revokes access at Google (for example from Google Account → Security → Third-party apps), Pria detects the next failed call and clears the stored token — the user is asked to authorize again from their Google Services profile page.

​
Security considerations

  • CSRF protection — Pria generates a random state value on every authorize redirect, keeps it in the user’s session for 5 minutes, and checks it on the callback. A mismatch or expiry produces an invalid_state / state_mismatch / state_expired error.
  • One-time state — The state value is deleted as soon as the callback reads it, preventing replay attacks.
  • No client secret in the browser — Token exchange (code → access_token) is always server-to-server.
  • One-time login codes — After a successful social sign-in, the user briefly lands on /oauth/success, which completes the hand-over with a short-lived, single-use code that is never written to server logs and is removed from browser history.
  • Mobile flow — Mobile apps complete the same hand-over through a signed deep-link redirect, so sign-in works without relying on browser cookies surviving the switch between apps.
  • Two-step verification — If the account has two-step verification turned on, Pria asks for the code after the provider sign-in as well.