afterbuild/ops
§ EX-05/auth-specialist
AI app auth specialist

AI app auth specialist — Supabase Auth fix, Clerk setup for AI apps, OAuth callback fix and session management when authentication works in preview and nowhere else.

By Hyder Shah12 min readLast updated 2026-04-15
Quick verdict

An AI app auth specialist is the person you hire when login works in preview and nowhere else. The widely-reported February 2026 Lovable/Supabase RLS disclosure (see our 2026 research) wasn't a Supabase bug — it was auth logic inverted and missing session management. We ship Supabase Auth fixes, Clerk setup for AI apps, OAuth callback fixes and session refresh wiring — at fixed prices, covering Supabase Auth, Clerk, NextAuth, Firebase, and Auth0. As of April 2026, Supabase Auth v2 (released Q1 2026) changed the session token format and many AI-generated apps are still emitting v1 patterns — Clerk also launched organization-level auth in March 2026 that AI tools haven't caught up with.

Why AI builders ship broken authentication

Authentication is five flows pretending to be one. Sign-up, sign-in, session refresh, password reset, and OAuth redirect each have their own edge cases — expiring tokens, one-time links, state parameters, cookie domains. AI builders reliably get sign-up and sign-in working in preview. They reliably forget the other three.

The most dangerous auth failure is logic inversion. The widely-reported February 2026 Lovable/Supabase RLS disclosure — summarized in our 2026 research — captured the exact failure: policies had the role check inverted, so authenticated users were denied and unauthenticated requests were allowed through. That's not a missing policy — that's generated code that runs and silently does the opposite of what the developer intended. Industry benchmarks put AI-code vulnerability rates close to half; auth logic inversion is one of the categories.

The second failure mode is environment coupling. OAuth redirect URIs hard-coded to localhost. Session cookies set on the preview subdomain but not the production domain. JWT secrets inconsistent between build and runtime. Clerk webhooks pointed at the preview URL forever. Every AI builder produces at least one of these. An authentication specialist enumerates every flow, tests every edge, and patches the cookies, redirects, and role checks before a single real user logs in.

Source: The Register, Feb 2026 — Lovable/Supabase auth-inversion disclosure

§ MATRIX/ai-builder / failure-mode

Which AI builder shipped your broken authentication?

The authentication failure mode usually depends on the tool that shipped the code. Find your builder below, then read the matching problem page.

AI builderWhat breaks in authenticationGo to
LovableSupabase Auth wired in; password reset emails never arrive. OAuth redirect URL stuck on preview. Role checks inverted on RLS policies.Lovable auth fix
Bolt.newAuth scaffolding present, session refresh missing. JWT secret regenerated per deploy, invalidating all sessions.Bolt.new auth fix
v0Frontend-only. Beautiful sign-in form; no backend validates it. You pick Clerk or Supabase and wire it yourself.v0 auth fix
CursorRegression loop — fixes password reset, breaks OAuth callback two prompts later. Forgets session hydration on SSR.Cursor regression fix
Replit AgentPicks Replit DB auth for prototypes, swaps to Supabase or Clerk late. Cookies set on wrong domain.Replit rescue
Claude CodeWrites correct auth when told to. Silently assumes sessions are server-only and misses the browser-side refresh path.Claude Code architecture fix
WindsurfEnterprise auth patterns but no specific flow testing. Role propagation across features is inconsistent.Windsurf rescue
Base44Opaque auth wrapper. Export lands with raw Supabase Auth and no policies.Base44 backend fix
§ ANATOMY/authentication / failure

Anatomy of the auth-inversion failure behind the 2026 Lovable disclosure

February 2026: the widely-reported Lovable/Supabase RLS disclosure captured the largest AI-built-app breach on record. Our 2026 research summarizes the incident. The root cause wasn't missing security — it was inverted security. Quote from the disclosure: 'authenticated users were blocked; unauthenticated visitors had full access to all data.' That single sentence captures a failure mode that doesn't exist in human-written auth code, because humans ask 'why would I write this?' AI agents don't.

The mechanism is boring in isolation. An AI builder is prompted: 'users should only see their own orders.' It writes a Supabase RLS policy: `USING (auth.uid() = user_id)`. Later, the same or a different prompt asks for a public-facing orders summary. The AI adjusts the policy — and adjusts it wrong. The condition becomes `auth.uid() != user_id OR auth.uid() IS NULL`, which reads as 'allow if the viewer isn't the owner, or if there's no viewer at all.' The anon key, embedded in every client bundle, is exactly the 'no viewer' case. Every anonymous visitor now has full read access to every user's orders. Authenticated users, who are the owners, are blocked by the != check.

Compounding: auth in a real app isn't one check.
Hyder Shah· authentication rescue engineer

Compounding: auth in a real app isn't one check. It's five distinct flows — sign-up, sign-in, session refresh, password reset, OAuth — each with its own edge cases. The AI almost always ships sign-up and sign-in working. Password reset emails go to the AI builder's preview subdomain because SMTP was never reconfigured for production. Session refresh quietly drops users after an hour because `onAuthStateChange` is never wired. OAuth callback hard-codes the Lovable preview URL into Supabase's redirect allowlist. Each of these individually is a support ticket. Together they are a broken product.

The 5-day, $799 integration fix enumerates all five flows, tests each on production URLs with a real email address and a real OAuth provider, writes the missing handlers, and leaves a Playwright suite that fails if any flow regresses. We've shipped many of these; the $499 security audit catches the inverted policies specifically, scripted against every role and route. The difference between the breach apps and the non-breach apps is not talent — it's whether someone ran this specific check before going live.

§ RESCUE/authentication / engagement

What a authentication rescue engagement ships

From first diagnostic to production handoff — the explicit steps on every authentication engagement.

  1. 01

    Free rescue diagnostic

    Send us your repo and the symptom. In 24 hours we return a written list of which auth flows are broken, which are missing, and the fixed price to complete them.

  2. 02

    Five-flow audit

    We test sign-up, sign-in, session refresh, password reset, and OAuth redirect on production URLs. For each we check cookies, redirects, email delivery, token expiry, and role propagation. Delivered as a written report.

  3. 03

    Integration fix

    We fix one auth provider end to end — Supabase Auth, Clerk, NextAuth/Auth.js, Firebase, or Auth0 — including the half-wired flows. $799, fixed price, 5-day delivery.

  4. 04

    Production deploy pass

    Correct OAuth redirect URLs in provider consoles. Cookie domain configured for production. Session secrets wired consistently between build and runtime. Test every flow on the real domain before cutover.

  5. 05

    Handoff

    Delivery doc, Loom walkthrough of every auth flow, runbook for common auth incidents (locked-out admin, expired OAuth app, email deliverability). Optional retainer for ongoing auth work.

§ AUDIT/authentication / first-pass

Every authentication rescue audit checks

The diagnostic pass on every authentication rescue. Each item takes under 10 minutes; together they cover the patterns that cause 90% of AI-built-app failures.

  1. 01
    Every RLS policy tested from each role

    Scripted queries as anonymous, as non-owner authenticated, and as owner authenticated. Unexpected success or failure is flagged.

  2. 02
    Session cookie settings

    HttpOnly, Secure, SameSite=Lax (or Strict for admin). Domain scoped to production, not .vercel.app or similar.

  3. 03
    OAuth redirect URI match

    Provider console and app must agree exactly. Trailing slash, subdomain, protocol all matter. Mismatches cause 400s in production.

  4. 04
    Password reset link points at production domain

    Supabase default sends to the project URL. Production apps must override the redirect to the real domain.

  5. 05
    SMTP configured for custom domain

    Default Supabase email deliverability is low, and the default inbox is capped at three emails per hour; in Q1 2026 roughly 60% of apps we audit still rely on it. We wire Resend or SES with SPF/DKIM on the custom domain.

  6. 06
    Session refresh on the client

    `supabase.auth.onAuthStateChange` wired in the layout to hydrate and refresh. Missing = silent logouts at access token expiry.

  7. 07
    Role propagation across RLS, API routes, and UI

    A user's role is checked consistently in all three layers. Divergence is a privilege escalation vector.

  8. 08
    Rate limits on auth endpoints

    Sign-up, sign-in, password reset capped per-IP and per-identifier. Missing = credential stuffing and enumeration.

  9. 09
    Email verification enforcement

    Unverified users shouldn't be able to sign in to anything sensitive. We check enforcement in the auth middleware.

  10. 10
    MFA or 2FA for admin roles

    Especially for apps handling money, health data, or other regulated domains. We enable via the provider.

§ DIFF/authentication / before-after

Common authentication patterns we fix

These are the shapes AI-generated code arrives in — and the shape we leave behind.

The inverted RLS policy
✕ before · ai-shipped
tsx
01`USING (auth.uid() != user_id OR auth.uid() IS NULL)` — allows anonymous and non-owner, blocks owner. 170-Lovable-apps pattern.
The inverted RLS policy
✓ after · afterbuild
tsx
01`USING (auth.uid() = user_id)` with tests against anonymous, non-owner, and owner confirming the expected access.
The inverted RLS policy
The preview-URL password reset
✕ before · ai-shipped
tsx
01Password reset email links to `https://preview.lovable.app/auth/callback?...`. Production users can't reset.
The preview-URL password reset
✓ after · afterbuild
tsx
01Reset redirect set to production URL in Supabase allowlist. Tested end-to-end with a real inbox.
The preview-URL password reset
The missing session refresh
✕ before · ai-shipped
tsx
01No `onAuthStateChange` listener. Access token expires at 1 hour; user drops out mid-session with no indication.
The missing session refresh
✓ after · afterbuild
tsx
01Listener wired in the root layout. Refresh token automatically exchanges new access tokens. Session persists per Supabase's configured TTL.
The missing session refresh
The OAuth redirect_uri_mismatch
✕ before · ai-shipped
tsx
01Google OAuth console has `localhost:3000/callback`. Production request arrives from `app.example.com/callback`. Google returns 400.
The OAuth redirect_uri_mismatch
✓ after · afterbuild
tsx
01Production callback URL added to Google OAuth console and to Supabase allowlist. Tested from every environment.
The OAuth redirect_uri_mismatch
The role in the client
✕ before · ai-shipped
tsx
01User's role stored only in React state after login. A client-side edit flips 'user' to 'admin' and bypasses UI gating.
The role in the client
✓ after · afterbuild
tsx
01Role stored server-side, checked in RLS and API middleware on every request. Client state is display-only; server enforces.
The role in the client
The unverified-email login
✕ before · ai-shipped
tsx
01User signs up, immediately logs in, uses the app. Email verification never required. Spam accounts and takeovers follow.
The unverified-email login
✓ after · afterbuild
tsx
01Unverified users can't log in to protected routes. Verification email sent via configured SMTP; TTL and resend flow wired.
The unverified-email login
The JWT secret regenerated per deploy
✕ before · ai-shipped
tsx
01Secret is read from a random generator in build; every deploy invalidates every session. Users report 'I'm logged out again.'
The JWT secret regenerated per deploy
✓ after · afterbuild
tsx
01Secret fixed in Vercel env, consistent across deploys. Rotation is a planned event with a key-rollover window.
The JWT secret regenerated per deploy
§ FLAGS/authentication / red-signals

authentication red flags in AI-built code

If any of these are true in your repo, the rescue is probably worth more than the rewrite.

flag
signal
why it matters
An RLS policy contains `!=` or `IS NULL` on auth.uid() without a clear comment explaining the intent
Candidate for inverted access. The 170-Lovable-apps breach pattern.
Production password reset emails arrive with links to a preview or localhost URL
Supabase redirect allowlist never updated. Users locked out of recovery.
Users report being silently logged out after roughly an hour
Access token expiring, refresh flow not wired. Classic missing `onAuthStateChange` listener.
Admin actions exposed via a client-side 'if (role === admin)' check with no server-side enforcement
Trivial bypass by editing JS in DevTools. Privilege escalation.
Sign-up accepts any email without verification
Spam signups, account takeover via squatted emails, OAuth collision attacks.
Google OAuth console's authorized redirect URIs only include localhost or the preview subdomain
Production sign-in with Google will fail with redirect_uri_mismatch until the production URL is added.
No rate limit on /auth/sign-in or /auth/signup routes
Credential stuffing and enumeration attacks run uncontested.
§ PRICING/authentication / fixed-price

Fixed-price authentication engagements

No hourly meter. Scope agreed up front, written fix plan, delivered on date.

price
$0
turnaround
Free rescue diagnostic
scope
Written auth audit and fix plan in 24 hours.
View scope
featured
price
$499
turnaround
Security audit
scope
RLS, auth logic, session, and OAuth review. 48-hour turnaround.
View scope
price
$799
turnaround
Integration fix
scope
One auth provider — Supabase, Clerk, NextAuth, Firebase, Auth0 — done right.
View scope
price
$1,999
turnaround
Deploy to production
scope
Env vars, redirect URLs, cookie domains, monitoring. Safe for real users.
View scope
§ EXAMPLES/authentication / real-scopes

What authentication rescues actually cost

Anonymized, representative scopes from recent authentication rescues. Every price is the one we actually quoted.

Small rescue
$499

A founder on Lovable whose Google OAuth breaks in production. Preview works. Users see redirect_uri_mismatch.

Scope
OAuth allowlist update across Google console and Supabase, production callback tested, one-flow integration fix.
Duration
2 days
Medium rescue
$799

A seed-stage SaaS whose five auth flows are half-wired. Sign-up works; password reset silent; session drops after an hour; roles inconsistent.

Scope
Full auth pass — all 5 flows wired, tested on production domain, SMTP configured, session refresh, role propagation, Playwright tests.
Duration
5 days
Large rescue
$7,499+

A growth-stage B2B SaaS migrating from Supabase Auth to Clerk with preserved user IDs, SSO for enterprise customers, SCIM provisioning.

Scope
User migration via Clerk import API, SSO config for 3 enterprise customers, SCIM endpoint, audit log, 40-PR rollout.
Duration
4-5 weeks
§ RUNBOOK/authentication / references

authentication runbook and reference material

The documentation, CLIs, and specs we rely on for every authenticationengagement. We cite, we don't improvise.

§ FAQ/authentication / founders-ask

authentication questions founders ask

FAQ
What's the OAuth callback fix for Google OAuth failing in a Lovable production deploy?
Google requires the exact production URL in its OAuth consent screen's authorized redirect URIs. Lovable's preview uses a subdomain like yourapp.lovable.app that Google already has on file; your production domain (yourapp.com) isn't registered. The OAuth callback fix: add the production callback URL — including the Supabase auth callback path — to both the Google Cloud console and your Supabase project's redirect URL allowlist.
Should an AI app auth specialist use Supabase Auth, Clerk setup for AI apps, NextAuth, Firebase, or Auth0?
Supabase Auth fix if you're already on Supabase and want one bill — we fix its password reset and session quirks. Clerk setup for AI apps if you want the best UX out of the box with organizations, invitations, and MFA. NextAuth/Auth.js if you're on Next.js and want full control. Firebase Auth if you're already on Google Cloud. Auth0 if enterprise compliance is the top requirement. We support all five; the right choice depends on where you are.
Why do my users get logged out after 30 minutes — is this a session management bug?
Yes — your session management is broken. Supabase sessions default to 1-hour access tokens with 1-week refresh tokens; if the refresh token isn't exchanged automatically in the browser, users drop out when the access token expires. AI builders often forget to call supabase.auth.onAuthStateChange and swap the refreshed session in. A 20-line session management fix, but invisible until real users complain.
How much does an AI app auth specialist cost?
A security audit covering every auth flow is $499 with a 48-hour turnaround. An integration fix wiring one provider end to end — Supabase Auth fix, Clerk setup for AI apps, NextAuth, Firebase, or Auth0 — is $799, delivered in 5 days. A full deploy-to-production pass including auth, env vars, and monitoring is $1,999. No hourly billing.
My AI builder left auth logic inverted — how does an AI app auth specialist find it?
Manually. Open your RLS policies and role checks; confirm that policies named like 'users can read own data' actually filter by auth.uid() = user_id, not the opposite. Then log in as a non-admin and try to access admin routes. The widely-reported February 2026 Lovable/Supabase RLS disclosure documented exactly this inversion pattern at scale — our 2026 research summarizes it. Our Supabase Auth fix audit runs a scripted test suite against every role and route as part of the $499 security audit.
Can I add Clerk setup for AI apps to a v0 project without rebuilding it?
Yes. v0 produces a Next.js frontend; Clerk setup for AI apps drops in as a provider at the root layout and wraps protected routes with a server-side session check. We do this as an $799 integration fix, including session hydration on SSR, middleware route protection, sign-out handling and an OAuth callback fix for production.
How do I test session management and OAuth before launch?
At minimum, test on the production domain (not preview) with: a brand new email address signing up, signing out, signing back in, resetting the password via the emailed link, OAuth through Google or GitHub, and access from a private browsing window. Then log in as each role and try to access routes you shouldn't. Our $499 audit runs this checklist scripted against your live URLs and flags any OAuth callback fix or session management gap.
What's the fastest way to hire an AI app auth specialist before launch?
Book the $0 diagnostic. We'll triage which of the five flows are broken, which are missing, and give you a written fixed-price quote in 24 hours. For most AI-built apps the full Supabase Auth fix or Clerk setup for AI apps ships in 5 days for $799; urgent cases ship in 72 hours on the $2,999 emergency queue.
Next step

Your AI builder shipped broken authentication. We ship the fix.

Send the repo. We'll tell you exactly what's wrong in your authentication layer — and the fixed price to ship it — in 48 hours.

Book free diagnostic →