The Case for One Platform: An Engineer's View on Unifying Verify, Fraud, and Auth

Engineering Blog Series · The first in a new series featuring Prelude engineers on how the product actually gets built

In an interview with Loïc Madiès, Senior Backend Engineer at Prelude.

Before Prelude, I was on the authentication team at an e-commerce site in France. Fraud was still very much part of the job.

The stack was reasonable on paper. Email and password, OTP for multi-factor, a handful of social login providers. Underneath it: DataDome for bot traffic, Vonage handling OTP delivery, and authentication built in-house. Three tools, one purpose, allowing a user to access the platform, and none of them talked to each other. Fraudulent accounts got flagged eventually, by models analyzing patterns after the fact, but by then the account was already in. 

I had no real visibility into what was actually happening in the moment. That gap, and the fact that a platform built to share signals between those pieces sounded genuinely interesting to me, is part of why I joined Prelude.

Three Tools, One Purpose, no Shared Context

That's the part worth naming precisely: each of those three tools was doing its own job correctly, and still missing the thing that mattered.

Authentication on its own is already a lot of surface area, but it's not really built for fraud detection; it's mostly "is the password right, how many attempts, that kind of rate limiting." And an antibot tool without users’ data such as their phone number without the phone number, the piece that comes from verification, can see that attempt volume from a specific IP or country looks a little elevated, but it can't tell if that's actually suspicious or just normal traffic, because it doesn't have that additional context.

Without shared context, a system can tell something looks like a bot and still let it through as a normal, unflagged login. 

Once you can feed information from the anti-bot or verification side into the authentication flow, you can distinguish patterns that neither side would catch alone. A dangerous password, a strange email, an unusually high number of attempts from one country in a short window, none of those are damning on their own.

Together, with phone number and device history in the mix, they're a much clearer signal. And if the refresh pattern on a session shows a different IP on every attempt, that's a strong indicator of a residential proxy, again, something that only shows up once you're looking at authentication and fraud signals together.

Sharing that context is good for security and, just as directly, good for the user: it's what lets someone skip a redundant re-authentication because the system already knows what's already been verified.

This Wasn't Bolted on Later. It was the Plan From Day One

People sometimes assume unification like this gets bolted on after the fact, three products that started separate and got wired together later. 

That's not how it went. 

Sharing signals across these products was the company's vision from the beginning: delegate onboarding and trust to one actor rather than several, specifically so information could move between them.

The goal was letting customers focus on their own business instead of managing malicious users themselves, and one actor handling all of it is positioned to catch more, with fewer false positives, than three disconnected ones ever could.

I started on authentication specifically, without much focus on fraud, simply because there was a lot to build.

Once the core features were in place, I moved into the anti-fraud and verification side too, and that's where the cross-pollination happened for me: patterns I learned on the fraud side (blocking SMS pumping, then bots, then account hijacking) fed directly back into how authentication behaves, because by then the same person, and the same signal, informed both.

The Clearest Concrete Example: Refresh Tokens

If I had to point to one technical detail that makes the case better than any argument about philosophy, it's this one.

In a typical in-house setup, if someone steals a token, say, by listening on a public network, and you make a token refresh at that moment, you could reuse that stolen refresh token, and that was totally possible at my previous companies. 

From that experience, we chose to make it not possible, using private keys on the user's device, so we can tell if a refresh token is being reused by a different device, thanks to a solution we call DPoP. That's additional security, and we also have fingerprinting history that helps us know it's a different device reusing the same session.

It's a concrete issue, because when you build in-house, you're mainly focused on login, and you forget what comes after; users refresh a session far more often than they perform an actual login. 

This process becomes more secure specifically because it's sharing signals with the fraud side: on the front end we're already gathering a lot of information from the device, which makes it easier to detect these patterns.

The Honest Tradeoff: Outage Risk

The one real downside, and I don't think it's honest to pretend otherwise: centralizing means an outage can take down all three services at once, since they're all on the same critical path.

I won't pretend our way is a clean win here, because it isn't. Run three separate providers instead, and each one is still its own critical path for whatever it does, so losing any single one of them still means a user can't log in, the same outcome as losing our one integrated system. 

The real difference is the number of places that can fail: one outage surface that takes everything down together, versus three separate surfaces, each capable of causing that same failure on its own. It's closer to a wash than a clear win either way, and I'd rather say that plainly than oversell it as something it isn't.

Where it Actually Gets Hard: Migration

If there's a real, honest blocker for prospective customers, it's migration, and it's worth being specific about why.

Switching a verification-only provider is close to trivial: swap an API call, maybe two, and you're done. 

Authentication is a different problem entirely, because it needs data: who's already registered, how, including things like existing Google logins that have to move over. That's still technically one action, but it's an action that takes several weeks, and because it doesn't look like a new feature, the way enabling a new payment method would, it's often not prioritized by product teams.

Every authentication provider runs into this exact pain point, not just Prelude.

The part that takes real care is not losing users in the process. There's a real fear, on both sides, that a migration mistake logs people out, that a changed password or phone number leaves someone locked out of their own account, and neither users nor the company migrating them wants that. So the migration to Prelude covers existing sessions too, not just login credentials, specifically so people already logged in stay logged in through the switch.

Simplicity as the Actual Differentiator

The real differentiator against competitors who've also started talking about unifying these pieces comes down to two things: being genuinely ahead on the fraud side (SMS verification specifically), and a deliberate choice about how much control the platform takes away from the customer.  

Most login providers hand you a page to redirect through and back, which is a rough experience on mobile specifically, a web page opening inside a mobile app rarely feels native. 

Prelude Auth's choice was not to build that UI at all: handle the security and the backend logic, expose login as a method the customer calls directly, and let them build their own interface on top of it. That's a real tradeoff against a more turnkey, page-based competitor, and it's a deliberate one.

The same philosophy shows up in pricing and in scope. The stated goal is no per-feature pricing, so new capability doesn't quietly raise a customer's bill the way it does with providers who bundle in features nobody asked for. 

The vision is to make the features that 90% of people need, even if that means losing 10% of potential clients. The most important part isn't how many login methods you offer, there are enough documented standards, and enough of that documentation can feed an AI to build it for you.

The main point of authentication is fraud. That's where we can be very powerful.

Two Specific Fraud Patterns This Catches

Two concrete examples are worth naming directly, because they're specific enough to be checked rather than just asserted.

Dictionary attacks built from leaked data. A meaningful share of credential attacks aren't random. They're built from information that's already leaked: an address, a family member's name, a child's name. An attacker can build a short list of probable passwords from that and make a handful of attempts, spaced out, staying under standard rate-limiting thresholds the whole time, a handful of attempts every ten minutes for a few days, say, rather than a burst that would trip an obvious alarm. I've known this pattern from experience before Prelude too; it's one of the things Watch is specifically built to catch, using shared signal rather than raw attempt-counting.

Residential proxies at scale. Bots try to hide, and one way they do it is by rotating through residential IP addresses rather than obviously suspicious ones. Network analysis can identify that pattern, but only if it's looking for it across enough volume: a single slow, careful login attempt every twenty minutes doesn't look like anything unusual on its own. It's the pattern across scale, and across what happens on the site afterward, that gives it away. A system only watching authentication, in isolation, won't see it.

What it Actually Comes Down to

Our bet is that verification, authentication, and fraud protection sharing signal, as a package rather than three connected purchases, is a structurally different, more powerful thing than the same three pieces built apart and wired together after the fact.

What I've taken from working on this, after building authentication in-house for a single company earlier in my career, versus building it as a shared platform for many: the two are genuinely different disciplines. 

Access to data across many customers, rather than just one product's slice of it, is the real unlock, a pattern that's worldwide shows up across a shared platform's whole customer base before it ever reaches any single one of them. 

Building in-house, you only ever see your own slice, and that's exactly the gap I started this piece describing from the other side, years earlier, without a name for it yet.

Want to See How This Works for Your Stack?

If any of this, the refresh-token detail especially, sounds like a problem you're currently solving with three separate vendors, talk to the Auth team about your specific setup.

Loïc Madiès is an engineer at Prelude, working on Auth. He joined Prelude from Leboncoin, where he worked on session management and anti-fraud systems, bringing that experience directly into how Prelude's Auth product shares signals across sessions today. He studied engineering at Polytech Lyon.