Cyber Storm 2020 After-Action Report

Understanding the Replay Attack in B2C

Ever wonder how a hacker can walk through your front door without even knowing your password? It happens more than you'd think, especially in b2c apps where we're all rushing to give users a smooth experience.

At its core, a replay attack is just someone "recording" a successful login and playing it back later to trick the system. Imagine a user logs into their favorite retail site or a healthcare portal to check some labs. During that process, an attacker sniffs the network or grabs a token from a browser's local storage.

Even if that token was meant for a one-time thing, the server might see it again and say, "Yep, looks good to me," letting the bad actor right in.

• Interception in the wild: Attackers use tools on public Wi-Fi or malware on a phone to grab the id token before it even reaches the user.
• Token Reuse: Since the token is technically valid and signed, the backend doesn't realize it's being used by a different person in a totally different session.
• B2C Risk Factors: Consumer apps are huge targets because they often have millions of users on unmanaged devices—think of a person checking their bank balance at a coffee shop.

According to the 2024 Verizon Data Breach Investigations Report, stolen credentials and session abuse remain a top way for attackers to get in, which makes sense since it's easier than cracking a wall.

In a retail setting, this could mean someone drains a gift card balance. In finance, they might initiate a transfer. It's a mess because the system thinks the user is legit. To stop this "broken record" loop, we use a little thing called a nonce.

The Role of OIDC Nonce in Security

The secret sauce for stopping these replay attacks is the nonce—which is really just a fancy way of saying a "number used once."

Think of it like a one-time-use ticket for a concert. Even if someone photocopies your ticket, the guy at the door only lets in the first person who shows up with that specific code. In the world of oidc, the client (your app) creates this unique string before sending the user off to login.

The process is actually pretty straightforward, but you'd be surprised how many devs forget the last step. Here is the basic flow:

• Generating the string: Your app creates a random, cryptographically strong string. You should store this in a secure, session-bound cookie or local state.
• The Handshake: When you redirect the user to the identity provider (like azure ad b2c or okta), you stick that string in the nonce parameter of the api request.
• The Return Trip: After the user logs in, the provider sends back an id token. Inside that token (which is just a jwt), there’s a nonce claim.

If the nonce in the token doesn't perfectly match the one you generated at the start, you kick the request to the curb. It's that simple.

You might think, "Hey, I'm using https, so the token is encrypted in transit—I'm safe, right?" Not exactly. Metadata or tokens can still be leaked through browser logs or malicious extensions. As noted in the OpenID Connect Core specification, validating the nonce is a required step for the implicit flow and highly recommended for others to prevent injection.

Implementation Guide for B2C Platforms

Look, we’ve talked a lot about the theory, but at some point, you just gotta open your editor and write the code. If you're building a b2c app, the nonce is your best friend for keeping sessions tied to the right human.

First, you need a way to make a string that isn't easy to guess. Don't just use Math.random()—that’s a rookie move. You want something with high entropy. Here is how you handle the full loop in a node environment:

const crypto = require('crypto');
const jwt = require('jsonwebtoken');

// 1. THE OUTBOUND TRIP
app.get('/login', (req, res) => {
  const nonce = crypto.randomBytes(16).toString('base64');
  // Stick it in a secure, httpOnly cookie
  res.cookie('oidc_nonce', nonce, { 
    httpOnly: true, 
    secure: true, 
    sameSite: 'Strict' 
  });
  const authUrl = https://auth.provider.com/authorize?nonce=<span class="hljs-subst">${nonce}</span>&amp;client_id=...;
  res.redirect(authUrl);
});
// 2. THE RETURN TRIP (Callback)
app.post('/callback', (req, res) => {
  const { id_token } = req.body;
  const sessionNonce = req.cookies.oidc_nonce;
  const decoded = jwt.decode(id_token);
  // The actual comparison
  if (!sessionNonce || decoded.nonce !== sessionNonce) {
    console.error("Potential replay attack detected!");
    return res.status(403).send("Security mismatch");
  }
  // IMPORTANT: One-and-done. Clear it immediately!
  res.clearCookie('oidc_nonce');
  res.send("Welcome back!");
});

I've seen plenty of devs get this 90% right and then trip at the finish line. One big mistake is reusing nonces. If you let the same nonce hang around for multiple logins, you’re basically leaving the door unlocked again.

• One-and-done: Once you verify a nonce, delete that cookie or session entry immediately as shown above.
• Clock drift: Sometimes servers have slightly different times. While nonces don't usually expire based on time alone, your tokens do. Keep an eye on those iat (issued at) claims.
• Mobile vs Web: On a mobile app, you might not have cookies. You'll need to store the nonce in secure enclave or a private app state that doesn't persist forever.

A recent report by IBM Security (2023) highlighted that the average cost of a data breach reached $4.45 million, often driven by compromised credentials.

Best Practices for CIAM and Revocation

Implementing the oidc nonce is a great start, but let's be real—manually managing cryptographical strings and session cookies for every single login flow is a massive headache. Honestly, I’ve seen more than one project where security was "simplified" (read: broken) just because the boilerplate code got too messy.

This is where moving toward a more modern ciam approach makes life easier. Platforms like MojoAuth handle the heavy lifting of secure session binding automatically.

• Automatic Session Integrity: You don't have to manually generate and verify nonces; the platform ensures the token is bound to the hardware.
• Passkeys over Passwords: By moving to passkeys, you're replacing "something you know" with "something you have." Since passkeys use public-key cryptography, there is no shared secret for an attacker to "replay."
• Shrinking the Attack Surface: When you eliminate passwords, you also eliminate credential stuffing.

But what about those tricky edge cases? Sometimes a session is technically valid—the nonce matched, the token hasn't expired—but you still need to kill it. For example, if a user changes their password on another device or if your system detects a weird IP change mid-session.

You should implement a "Global Logout" or a revocation check. This means your backend checks a "blacklist" of revoked session IDs on every request, even if the jwt looks fine. It adds a bit of latency, but it's the only way to handle a stolen device.

It's a lot easier to sleep at night when you know the "nonce" logic isn't tucked away in a buggy middleware file you wrote three years ago. Security is never "finished," it's just about making it too expensive for the bad guys to bother with you. Stay safe out there and keep your tokens fresh.