Skip to content
identvia Developers

Reference

Security notes

What Identvia does for you, and the few things your app still has to get right.

What Identvia handles

  • Passkeys, authenticator apps and recovery codes; phishing-resistant sign-in when users enable passkeys.
  • Exact redirect URI matching, mandatory PKCE, single-use short-lived codes, refresh-token rotation with reuse detection.
  • Pairwise user IDs, so your app can’t be used to track users elsewhere, and neither can anyone else’s.
  • A consent screen showing your app’s name, logo, redirect domain and verification status.

Your checklist

  1. Keep the client secret on the server. Never in JavaScript, mobile apps or git. Browser and mobile apps should be public clients (no secret, PKCE only).
  2. Check state, nonce and the ID token. The PHP SDK does this. If you use another library, make sure it does too.
  3. Identify users by sub, not by email. Don’t link an Identvia sign-in to an existing account just because the email matches unless email_verified is true, and ideally only after the user confirms.
  4. Regenerate your session ID after sign-in, and use HttpOnly, Secure, SameSite=Lax cookies.
  5. Validate return_to so sign-in can’t become an open redirect (the SDK accepts same-site paths only).
  6. Store refresh tokens like passwords: encrypted at rest, never logged, deleted on sign-out (and revoke them).
  7. Ask for less. Request only the scopes you need; users are more likely to approve.

Rotating secrets

In the console, open the environment and press Rotate secret. The new secret is shown once. The old one keeps working for 24 hours so you can deploy without downtime, or you can revoke it immediately if it leaked. Rotation and other sensitive actions ask you to confirm it’s you.

Environments

Use separate environments for development, staging and production. Each has its own client ID, secret and redirect URIs, so a leaked development secret can’t touch production users. Development environments accept http://localhost; others require HTTPS. User IDs are tied to the redirect host, so every redirect URI in an environment must use the same host.

Verification

Unverified apps show an “Unverified app” warning on the consent screen. To get the Verified badge, request verification in the console: put your live redirect URIs on your domain, add a DNS TXT record to prove you control it, and describe what your app does. An Identvia reviewer approves or explains what to fix. Renaming the app or adding a redirect host outside the verified domain removes the badge until it is reviewed again.

Reporting a vulnerability

See security.txt. Please don’t test against other people’s accounts.