Great question—let’s break this down clearly since nonce is one of those easy-to-overlook parameters that adds meaningful security to your auth flow, especially with Azure AD (which implements OIDC on top of OAuth2).

What’s the core purpose of a nonce in OAuth2/OIDC? #

A nonce is a cryptographically random, unique value that your app generates before sending an authentication request to Azure AD. You include it in the request, and Azure AD will embed this exact value in the ID Token it sends back after a successful login.

Your app’s job is to store the nonce securely—like in an HttpOnly, secure cookie for web apps—before making the auth request, then verify that the nonce in the returned ID Token matches the one you sent.

Its primary job is to prevent replay attacks: this is when an attacker intercepts a valid ID Token and tries to reuse it to impersonate the user and gain access to your app. Since each nonce is unique to a single auth request, a reused token will have a nonce that doesn’t match what your app expects, so you can reject it immediately.

Will skipping nonce reduce your authentication security? #

Yes, it does—even with 1-hour short-lived tokens. Here’s why:

• A 1-hour window is still enough time for an attacker to intercept a token (e.g., via a man-in-the-middle attack, or if the token is stored insecurely in client-side storage like localStorage) and reuse it to access your app.
• Without nonce validation, you can’t confirm that the ID Token was generated specifically for the current user’s auth attempt—it could be a token from a previous, legitimate login that was stolen.

That said, if your app uses a server-side flow where tokens are never exposed to the client (e.g., authorization code flow with PKCE, where only the code is sent to the client), the risk is lower—but it’s still not zero.

What benefits do you get from adding nonce? #

• Blocks replay attacks entirely: As mentioned, each auth request gets a unique nonce, so stolen tokens can’t be reused to bypass your auth checks.
• Adds an extra layer of ID Token validation: Alongside verifying the token’s signature, issuer, expiration, and audience, nonce validation ensures the token is tied to the exact request your app initiated.
• Aligns with Azure AD and OIDC best practices: Microsoft explicitly recommends using nonce in their docs, especially for single-page apps (SPAs), mobile apps, or any scenario where tokens might be exposed to the client side.
• Future-proofs your flow: If you ever expand your app to support more scenarios (like adding a SPA frontend), nonce will already be part of your security setup, so you won’t have to retroactively add it.

Quick note for Azure AD specifically #

If you’re using Microsoft’s official MSAL libraries (MSAL.js, MSAL.NET, etc.), the library automatically handles nonce generation, storage, and validation for you—you don’t have to do anything manually. But if you’re building a custom auth flow without these libraries, you’ll need to:

1. Generate a cryptographically random nonce (use something like System.Security.Cryptography.RandomNumberGenerator in .NET, or crypto.randomUUID() in JavaScript).
2. Include it in the nonce parameter of your auth request to Azure AD.
3. Store the nonce securely (e.g., HttpOnly cookie) before redirecting the user to Azure AD.
4. After receiving the ID Token, extract the nonce claim and compare it to the stored value—reject the token if they don’t match.

Bottom line: Even with short-lived tokens, adding nonce is a low-effort, high-impact security win that closes a critical attack vector. It’s well worth implementing.

内容的提问来源于stack exchange，提问作者Ranieri Mazili