AADSTS76026: The request has expired

Symptoms

You usually see this pattern:

Scenario: User clicks the enterprise app tile in My Apps or the Microsoft 365 app launcher.
Result: Entra rejects sign-in and the user lands on an error page that includes: AADSTS76026: The request has expired. Try to submit new request.

If the same user signs in by going directly to the application URL first (the app’s own login button), it often works. That difference matters because it changes which side initiates the SAML flow.

How SAML SSO should work (what “good” looks like)

Microsoft Entra ID supports SAML by acting as the Identity Provider (IdP). The application is the Service Provider (SP). The SP is responsible for generating an AuthnRequest and sending it to Entra, and Entra responds with a SAML assertion to the SP’s ACS URL. :contentReference[oaicite:2]{index=2}

SP-initiated flow (preferred for predictability)

In an SP-initiated flow, the user starts at the application, the SP generates a fresh SAML AuthnRequest with current timestamps, and then Entra validates and completes the flow. This tends to be stable because the request lifecycle is owned by the SP.

IdP-initiated / launcher flow (common, but easier to misconfigure)

When the user launches from My Apps, the user is effectively starting at the IdP side. Depending on configuration, Entra may attempt to redirect the user to a URL that triggers the SP to generate a new request, or it may attempt to complete a flow using incomplete or stale context.

Root cause (what Entra is actually rejecting)

AADSTS76026 shows up when Entra receives an authentication request it considers expired, invalid for the current state, or outside the acceptable time window. Practically, this happens when the SAML request lifecycle does not line up with the way the user launched the application.

The most common real-world cause in enterprise apps is: the app is being launched from My Apps, but the enterprise app’s “Sign-on URL” is empty or incorrect. In that situation, Entra cannot reliably trigger a fresh SP-initiated AuthnRequest, and the request Entra is processing ends up stale. Setting the Sign-on URL gives Entra a stable entry point that causes the SP to generate a new request. :contentReference[oaicite:3]{index=3}

Fix: set the Sign-on URL (Basic SAML Configuration)

In the Microsoft Entra admin center:

Enterprise applications → select the app → Single sign-on → SAML → under Basic SAML Configuration, set:

Sign-on URL: the application’s SP-initiated login URL (the URL a user can visit to start sign-in at the app). :contentReference[oaicite:4]{index=4}

This is explicitly documented in Microsoft’s SAML setup guidance: Sign-on URL corresponds to the SP-initiated login URL. :contentReference[oaicite:5]{index=5}

Verify the fix (what to check, not what to hope)

1) Entra sign-in logs

Use the sign-in logs to confirm the failure stops occurring after the change and that the authentication flow is now consistent. For SAML app troubleshooting, Microsoft’s guidance on SAML sign-in troubleshooting and debugging is the right reference. :contentReference[oaicite:6]{index=6}

2) Capture SAML request/response (trace)

If you need proof of the request lifecycle, capture the SAML request/response using the recommended methods in Microsoft’s SAML debugging guidance. You’re looking for whether the AuthnRequest includes current timestamps and whether the request is being minted at the right moment. :contentReference[oaicite:7]{index=7}

Edge cases that can mimic “expired request”

Clock skew

If the user device, a proxy, or the SP infrastructure has time drift, the request may appear expired. This is less common in modern environments, but it still happens in locked-down VDI or segmented networks.

ACS/Reply URL mismatch or multiple endpoints

If the Reply URL (ACS) configured in Entra doesn’t match what the app expects, retries can lead to odd “expired request” behavior because the SP never successfully consumes the assertion. Validate your Basic SAML Configuration against the app’s documentation. :contentReference[oaicite:8]{index=8}

SAML request signing requirements

Some apps require signed AuthnRequests, and certain IdP-initiated patterns are sensitive to that setup. If you’re enforcing signed requests, validate your flow with a SAML trace and align with vendor guidance.

Microsoft references

Use these as your baseline, not random blog comments:

Enable SAML single sign-on for an enterprise application :contentReference[oaicite:9]{index=9}
SAML protocol details supported by Microsoft Entra ID :contentReference[oaicite:10]{index=10}
Troubleshoot sign-in to SAML-based apps :contentReference[oaicite:11]{index=11}
Debug SAML-based single sign-on to applications :contentReference[oaicite:12]{index=12}
Microsoft Entra authentication and authorization error codes :contentReference[oaicite:13]{index=13}