Troubleshooting authentication

#401 "Invalid email or password"

• Cause: The password is wrong, the email has no account in this project (app users belong to one project, so an account made in another project or in staging doesn't exist here), or the app points at a different project's URL.
• Check: Authentication › Users: search for the email. Compare the URL your app uses with Connect for this project and environment.
• Fix: Send a password reset (Email and password), or create the user in this project. Make the app's URL and anon key come from the same project.
• Verify: Sign in again; the Users page shows the new last sign-in.

#403 SIGNUP_DISABLED

• Cause: The project only lets in invited users.
• Check: Authentication › Sign in / Providers: Allow new users to sign up.
• Fix: Turn sign-ups on, or invite users from the Users page (Users and app roles).
• Verify: A new sign-up returns a session (or "check your inbox" when confirmation is required).

#Confirmation, magic-link or reset emails don't arrive

• Cause: The mail went to spam; the sender limit of Sovaria's shared sender was reached; or, with your own SMTP, the domain isn't verified (no SPF/DKIM) or the SMTP credentials are wrong.
• Check: The spam folder; Project settings › Emails for SMTP status and the sending limits; your SMTP provider's activity log.
• Fix: Send through your own SMTP with a verified domain (Emails: SMTP, templates and limits). Links expire — magic links after 15 minutes, confirmations after 24 hours — so ask for a new one rather than reusing an old link.
• Verify: Send yourself a password reset; it arrives in the inbox, not spam.

#An email or social sign-in link opens the Site URL instead of my page

• Cause: redirectTo isn't on the redirect list and isn't under the Site URL. Sovaria then sends people to the Site URL instead of an unknown address.
• Check: Authentication › URL configuration: the Site URL and the redirect URLs. * matches one label or path segment, ** any path.
• Fix: Add the exact URL (or a pattern such as https://*.example.com/**). For apps, register the app's scheme or app link (Sign-in for mobile apps).
• Verify: Request a new link — old links keep the address they were made with.

#400 PKCE_REQUIRED or PKCE_VERIFIER_MISMATCH

• Cause: PKCE_REQUIRED: a link or sign-in redirects into an app (a custom scheme) without a code challenge. PKCE_VERIFIER_MISMATCH: the code was exchanged with a different verifier — usually on another device or browser, or after the app's storage was cleared.
• Check: Whether you call the HTTP API directly (the SDKs add PKCE for app redirects themselves) and where the link was opened.
• Fix: Use the SDK's sign-in methods, or send code_challenge (S256) and keep the verifier until the exchange. Open the link on the device that asked for it.
• Verify: The exchange returns a session.

#429 AUTH_RATE_LIMITED, SMS_COOLDOWN or SMS_DAILY_LIMIT

• Cause: Too many sign-in, sign-up, email or SMS requests from one address, phone number or network. The message says how long to wait.
• Check: The bucket in the error body names the limit; Authentication › Rate limits shows the values (Authentication settings reference).
• Fix: Wait and retry; don't retry automatically in a loop. Raise the limits if real users hit them (for example many users behind one office network).
• Verify: The request succeeds after the wait.

#423 after MFA codes, 401 CODE_ALREADY_USED, or 403 MFA_REQUIRED

• Cause: 423: five wrong codes within five minutes locked MFA for a while. CODE_ALREADY_USED: a code is accepted once. MFA_REQUIRED: the action needs a session that completed MFA (aal2).
• Check: The device clock (TOTP codes depend on it) and whether the session was upgraded after the MFA challenge.
• Fix: Wait for the lockout to end, then use a fresh code or a backup code; send the user through the MFA challenge before sensitive actions (Multi-factor authentication).
• Verify: The verify call returns an aal2 session.

#Users are signed out unexpectedly

• Cause: Session settings end sessions (inactivity timeout, time-box, or single session per user, where a new sign-in ends the older ones); a refresh token was reused after it was rotated; an admin signed the user out; or, on servers, the session was never stored.
• Check: Authentication › Sessions settings (Authentication settings reference); the user's recent activity on the Users page; whether two tabs or devices share one refresh token.
• Fix: Loosen the session settings if they are stricter than you meant. In browsers let the SDK keep the session (persistSession); on servers pass the user's token on every request (Sessions and tokens).
• Verify: Reload the app after a few minutes idle; the session is still there.

#409 OAUTH_EMAIL_UNVERIFIED after social sign-in

• Cause: An account with that email already exists and the provider didn't confirm that the person owns the address, so Sovaria won't link them.
• Check: Which provider was used (for example a work account whose organization sets its own emails).
• Fix: Sign in with the password, a magic link or a provider that confirms the email.
• Verify: The user reaches their existing account.

#My own backend rejects Sovaria access tokens

• Cause: The token expired (access tokens last 15 minutes by default), comes from another project (different iss), or the backend verifies with the wrong algorithm or key.
• Check: Decode the token: exp, iss (https://<project-ref>.sovarias.in/auth/v1) and the kid in the header.
• Fix: Verify ES256 signatures with the keys from /auth/v1/.well-known/jwks.json, cache them and refetch on an unknown kid; send fresh tokens from the client (the SDK refreshes them).
• Verify: A freshly signed-in user's token passes your check.

#Still stuck?

Email outreach@sovaria.in with your project URL, the time it happened (with time zone), the X-Request-ID response header or the trace_id from the error body, and the user's id (never their password). Never send keys, passwords, tokens or your users' data.