Developer forum

Hi Andreas

Can you share a bit of more information? Which version of Dynamicweb - and is it a custom provider?

From my chat with my good friend, miss GPT:

Here are several angles I’d explore—any one of these (or a combination) could lead to that “mystery logout” behavior:

Cookie‐middleware ordering & types

• External vs. application cookie
  You’re registering only an ExternalCookie (used to hold the incoming identity from Azure AD), but you never issue a long-lived “application” cookie. Normally you do:

  // 1) holds your own app’s login session
  app.UseCookieAuthentication(new CookieAuthenticationOptions {
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath        = new PathString("/Account/Login"),
    // …
  });
  // 2) holds the transient AzureAD token during the handshake
  app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
  // 3) then the OpenID/WS-Fed handler
  app.UseOpenIdConnectAuthentication(…);
  

  If you skip (1) you’re relying on the external cookie alone, which is removed immediately after sign-in and can slip away on the next redirect.

Cookie scope, domain & SameSite

• Domain/subdomain mismatch
  If the authenticated app runs on app.example.com but your cookie domain is defaulting to the bare hostname, it won’t be sent on refresh to another host.

• SameSite defaults
  Modern browsers default SameSite to “Lax,” so POST-backs or 3rd-party redirects may drop the cookie. Try:

  CookieSameSite = SameSiteMode.None,
  CookieSecure   = CookieSecureOption.Always
  

  to ensure it survives the OIDC roundtrip.

Expiration & sliding-expiration

• You’ve set ExpireTimeSpan = 60 minutes, but if you haven’t enabled sliding expiration, the cookie will die exactly on that mark—even if the user is active.

  SlidingExpiration = true,
  

•  

Size limits & cookie truncation

• If your external identity carries a lot of claims, you can blow past the 4 KB per-cookie limit. The runtime will silently truncate, and on the next request you’ll get an invalid ticket.
  Check:

  • How big is the .AspNet.ExternalCookie payload?

  • Can you prune unnecessary claims in your TokenValidationParameters or via a ClaimsTransformation step?

Debugging tips

1. Capture the cookie lifecycle with your browser’s dev-tools (check when it’s set, when it’s deleted, and which request “loses” it).

2. Enable verbose OWIN logging:

   <appSettings>
     <add key="owin:Logging" value="Microsoft.Owin" />
   </appSettings>
   

3. Hook the OWIN events in your OpenID/WS-Fed config:

   Notifications = new OpenIdConnectAuthenticationNotifications {
     MessageReceived          = ctx => { /*…*/ },
     RedirectToIdentityProvider = ctx => { /*…*/ },
     AuthenticationFailed     = ctx => { /*…*/ },
     SecurityTokenValidated   = ctx => { /*…*/ },
     /* log each ctx.Properties … */
   }
   

In short: double-check that you’re issuing a proper application cookie (not just the external one), that your cookie settings line up with your domain/SameSite needs, and that in a multi-server scenario your data-protection keys (or machineKey) are shared. From there, inspect the actual cookie on each redirect (size, presence/absence, expiry) and correlate with your OWIN logs to see exactly where it’s getting dropped or rejected.

Hi,

Thanks, i will try to set some of those propertys and see if it gets better.

Version 9.16.5.

No custom provider, we use DW's AzureADLoginProvider external authentication.
The only thing custom we have for the login is a loginsubscriber that set a fieldvalue on the user and then save the user.

I tried like this now, but i can not see the cookie in the cookie list:

If the user change tab in browser and then after 30 minutes go into the site again he gets logged out when trying to do something.

That is probably Dynamicweb login timeout that triggers. Set it to 60 like your cookie auth.