Login session duration can be extended from 8 hours

[shibayan]

Is your feature request related to a problem? Please describe.

When using Static Web App custom authentication, the login session (actually a cookie) expires in 8 hours and cannot be extended using /.auth/refresh like the App Service, so I would like to extend the expiration time from 8 hours.

Once issued, the StaticWebAppsAuthCookie cookie expiration date is not extended and API calls will not work properly once it expires.

In particular, using responseOverrides to convert HTTP 401 to HTTP 302 redirects, as described in the following document, leads to CORS errors and makes error handling in the application difficult.

https://docs.microsoft.com/en-us/azure/static-web-apps/configuration#response-overrides

Since SPAs often do not reload entire pages for long periods of time, expiring login sessions in the middle of a page can cause unexpected behavior.

Describe the solution you'd like

I would like to be able to change the cookie validity time for custom authentication using staticwebapp.config.json. Or, allow session extension using /.auth/refresh.

Ideally, the login session would be automatically extended on a sliding when the time remaining in the session becomes too short.

Describe alternatives you've considered

None

Additional context

In the case of SPA, only the API response status code can determine cookie expiration, so if you are using responseOverrides to redirect HTTP 401 to HTTP 302 as in the sample in the official documentation, error handling becomes very difficult.

• Related Issue

  • 762

[shibayan]

@mkarmark Does a solution exist to solve this problem? If a support request needs to be created for resolution, we will create one. Thanks.

[shibayan]

Hi @miwebst @anthonychu. Is there a way forward to successfully resolve this issue? For our customers, authentication behavior is a blocking issue😥

[mhoffner]

Hey @shibayan. I resorted to adding a blank page to my SWA that's behind an 'authenticated' role and loading that page in an invisible iframe to refresh the cookie without any user interaction. I added a BroadcastChannel exchange between the app and blank page so that the app knows when the cookie has been refreshed and can attempt to call the api again.

Definitely not ideal, but its working for now.

[shibayan]

Hi @mhoffner. Thanks for the info. It's a fascinating approach, but seems difficult to do for OpenID Connect providers. Most of them should have measures in place to prevent iframes from being displayed.

Ideally, a refresh token would be issued and the login session could be refreshed silently, which is possible with Easy Auth's Token Store, which I hope will be added.

It is also very demanding as a UX to have a login session unintentionally expire while the app is being used in SPA, requiring a redirect to the IdP for renewal, discarding all work.

[mathiasi]

We are also experiencing this. Either after some time or if the Static Web App has been redeployed, the session is no longer valid and needs a page refresh in order for our SPA (Angular) to work again.

[scottkuhl]

Can we get a response from Microsoft if there is any movement on this? Having users login everyday is a showstopper for a lot of applications.

[TroyWitthoeft]

Checking in here too. Would like an option to make this configurable. Or a clean example of how to keep the token alive beyond eight hours. Right now, in a typical "nine to five" shop anyone showing up a bit early, or staying a bit late with an app is going to get a very disruptive kick out. Even a bump to twelve would cover most corporate "swa for internal tooling" use cases.
Help us @anthonychu you're our only hope! 😄

[richardrobberse]

Did anyone find an okay-ish workaround? Having the exact same issue here with with a React app (PWA). Removed the 401 from responseOverrides to avoid the CORS error, tried to catch the 401 error (API call) and somehow trigger a redirect to the login page but I can't get it to work.

Seriously thinking of ditching SWA auth and go with msal-react instead.

@mathiasi You mentioned refreshing the page makes it work again but in my case it doesn't, what did you do to achieve this? Maybe you could share your staticwebapp.config.json?

@shibayan @mhoffner Tagging you guys because you might've found a workaround in the meantime.

[phranger]

Hi team, is there likely to be any update on this?

I am using custom authentication via OIDC, where the provider can support up to 180 days for expiry. Would really like an option to make use of this, such as mentioned above with a '/.auth/refresh' endpoint or an option to make it configurable.

I have a PWA and you completely lose the 'app' experience for users if you have to log in after 8 hours.

[savcic-milorad]

Also an issue for my use case, the authentication provider can have a longer lasting session but the cookie expiry is very limiting.

[seidnerj]

This the fact that this is not configureable is outrageous, it doesn't seem to even extend the expiration time during a visit so users are forced to re-login every 8 hours. How can a production system exist with such a limitation?!

[alex-ht-work]

Bump.

Any attention to this problem will be much appreciated.

[savcic-milorad]

Anyone to respond to this.

This is still an issue, I am using the Authentication feature of Azure Container Apps, although the session can be extended by setting EasyAuthConfig/login/cookieExpiration/timeToExpiration the user is forced to reauthenticate on every browser close.

I have posted on Microsoft Q&A this question as well

[seidnerj]

I am contemplating simply resetting this cookie myself as a non session cookie with a long expiration time

[alex-ht-work]

I am contemplating simply resetting this cookie myself as a non session cookie with a long expiration time

The annoying thing is, it is an HTTP only cookie, so you can not access it from JavaScript. Looks like the only way to make it straight is to reimplement authentication yourself...

[seidnerj]

I am contemplating simply resetting this cookie myself as a non session cookie with a long expiration time

The annoying thing is, it is an HTTP only cookie, so you can not access it from JavaScript. Looks like the only way to make it straight is to reimplement authentication yourself...

Well, I wasn't planning on using JavaScript, but rather setting it server side using another subdomain of the same domain.

One of SWA's cookies is stored under ".www.domain.com" and the other under "www.domain.com". If I recall correctly setting the cookie server side from one subdomain to another should work.

While you're at it, you can also remove the HttpOnly flag.

[JonSilver]

It is absolutely ludicrous that an issue of significant importance (and mission criticality to some) remains unresolved after 2 years and has had no apparent input from anyone from Microsoft during that time.

@anthonychu and colleagues - anything to contribute?

[seidnerj]

Anyone there? this is crazy stupid!

[scottkuhl]

Static Web Apps has had very little movement in a long time. I suspect it was not a big hit and is not being funded much by Microsoft anymore. I would love for someone on the team to prove me wrong. It's a great product and needs some attention.

[karthikeyantc]

Hi, Did anyone found any solution for this?