Skip to content

Users

The Accounts page (/admin) is the landing page of the admin UI. It lists every PiaUser in the database with filters by email, name, OAuth provider, and role.

Pia has two effective roles:

  • User — the default. Can sign in, sync, and use the AI proxy.
  • Admin — additionally has access to /admin/*.

There is no built-in “viewer” or “support” role; the admin UI is all-or-nothing. Promote a user by selecting them on the Accounts page and assigning the Admin role. Demote the same way.

A user’s authentication provider is recorded as one of:

  • Local — email + password registered through /auth/register.
  • Google — OAuth via Google.
  • Microsoft / EntraID — OAuth via Microsoft Entra (see Entra OAuth).

A given email belongs to exactly one provider; the OAuth callback returns 409 email_exists if the same address shows up under a second provider. This avoids account-confusion attacks where a victim’s local-password account could be silently linked to an attacker-controlled OAuth identity.

The Accounts UI offers Deactivate, not delete. A deactivated user:

  • Can no longer sign in (the auth endpoints return 401).
  • Keeps their data in the database (sync rows, devices, settings).
  • Can be reactivated at any time.

True deletion is intentionally not exposed in the UI. If you need to remove a user permanently — for example to satisfy a GDPR request — do it directly against the database during a maintenance window, after backing up.

If a user has lost access to all their devices:

  • No E2EE: an admin can issue a password reset (for local accounts) or the user can re-sign-in via OAuth on a new device.
  • E2EE enabled: the user must use their recovery code. Without it, encrypted records (memory, sessions, providers, todos) cannot be decrypted by anyone — including admins.