How to test behind your login
The interesting part of your product is behind the login. The dashboard, the settings, the checkout, the place where a real user actually does work — none of it is on the marketing page. So a testing tool that can only see the logged-out surface is checking the least important 10% of your app and calling it coverage.
QuantumVerifi crawls, generates, and runs tests behind your sign-in. The only question is how it gets in. There are four ways, and they trade off along one axis: how much of a secret you have to share with us. We built the default so the answer is none.
Here's how to pick.
The short version#
| If your app… | Use | You share | We ever see your secret? |
|---|---|---|---|
| runs any auth provider, and you can deploy a small route | Private Auth Bridge | nothing | No |
| is on Clerk | Clerk test credentials | a throwaway test key | No production secret |
| has a plain username/password login | Form login | app test creds | Encrypted, only to sign in |
| is none of the above | Session upload | one captured session | No — you paste it |
Recommended default: the Private Auth Bridge. It's the one where your identity provider's signing secret never leaves your infrastructure. If you can spare fifteen minutes to deploy a route, start there and stop reading.
1. The Private Auth Bridge — secret-free, recommended#
This is the one we're proud of, so it goes first.
Most "test behind the login" features work by asking you to hand over your identity provider's secret key — the thing that can mint a session for any of your users. You paste sk_live_… into a form on someone else's SaaS and hope their storage is as careful as yours. We didn't want to be the company holding that key.
So the Bridge inverts it. You deploy a tiny signed route inside your environment — where your provider secret already lives. When a QuantumVerifi run needs to sign in, it sends your route a signed request (HMAC, single-use, no secret in it). Your route mints a fresh session for a test user you designate, and hands back only that session.
The signing secret stays in your environment the entire time. We hold a public verification key and a session that expires. There is no field, anywhere, where you type your provider's real secret into our product — because there's nothing for us to store.
When to use it: any auth provider (Clerk, Auth0, Cognito, your own), and you can deploy one route. This is the right answer for production apps and anyone whose security review would (rightly) flag "paste your prod secret here."
What you do: Settings → Authenticated Access → connect the Bridge, deploy the route we generate, designate a test user. After that, every run is unattended — no pause, no secrets, no ceremony.
2. Clerk test credentials — fastest, no deploy#
If you're on Clerk, there's a shortcut that needs no route at all — and, done right, no production secret either.
Clerk has a first-class testing mode. You can create test users with +clerk_test email addresses (like [email protected]), test phone numbers in the +1 (XXX) 555-01xx range, and a fixed verification code — 424242. Sign-ins for these users skip bot detection, CAPTCHA, and MFA, which are exactly the things that make automated login flaky. Clerk's Testing Tokens handle the bot/CAPTCHA bypass; the fixed OTP handles the second factor.
You give us a throwaway test key and one of these test users. Because it's a test-mode credential for a synthetic user, it can't do anything interesting to your real tenant — and you rotate it whenever you like.
When to use it: you're on Clerk, you want to be running in five minutes, and you're comfortable issuing a dedicated test key. It's the fastest path to a green authenticated run.
One honest caveat: this lane does involve a Clerk secret (a test one). If your policy is "no provider secret leaves our walls, test or not," use the Bridge instead — that's exactly the line it's designed for.
3. Form login — the universal option#
Not every app is on a managed identity provider. Plenty of them have a plain <form> with a username field, a password field, and a submit button. For those, you give us test-account credentials and we sign in the way a person would: fill the fields, submit, follow the redirect.
The credentials are used only to drive the login, and they're entered per run — QuantumVerifi doesn't keep a copy of your app password sitting at rest. Still — use a dedicated test account, not a real user's, and definitely not an admin. Same hygiene you'd apply to any CI secret.
When to use it: custom or legacy login, no standard IdP. It's the universal fallback that works when nothing fancier applies.
The honest tradeoff: form login is the most fragile lane. Modern login widgets — rotating field names, "are you a robot?" checks, magic links, step-up MFA — are hostile to automation by design. When a form login flakes, it's usually one of those. If your login has any of that, lanes 1 or 2 will be far steadier.
4. Session upload — the manual escape hatch#
Sometimes you just want it to work right now and you don't want to wire anything. Sign in to your app in your own browser, export the session (a Playwright storageState, or the cookies), and paste it in. We inject it directly and crawl as that user.
No secret changes hands — you captured the session yourself. The only downside is it's manual and the session eventually expires, so it's better for a one-off deep look than for a scheduled, always-on check.
When to use it: a quick investigation, an app that fits none of the above, or when you want a human in the loop for one run.
So which one?#
Walk down this list and stop at the first yes:
- Can you deploy a small route? → Private Auth Bridge. Secret-free, unattended, works with any provider. This is the destination for anything long-lived.
- Are you on Clerk and fine with a throwaway test key? → Clerk test credentials. Running in minutes.
- Plain username/password login? → Form login with a dedicated test account.
- None of the above, or just this once? → Session upload.
You set the saved lanes up in one place — Settings → Authenticated Access — and every saved connection shows up in the analyze form's sign-in picker, so choosing a lane for a run is one click. Form login and session upload are entered per run, right on the New Analysis form.
The principle underneath#
We think a testing tool should be able to see your whole product without becoming a place where your most dangerous secret sits at rest. That belief is why the recommended path is the one where we never hold your provider's key — and why every other lane is honest about exactly what it does and doesn't share.
Test the 90% of your app that's behind the login. Just don't hand your master key to a SaaS to do it.
Ready? Open Settings → Authenticated Access and connect your first lane.