At this moment the 30 days are indeed a hard limit on the session timeout; there’s an already known issue that we are aware and intend to fix that is about the authentication method to get refreshed tokens based on a session is not renewing the idle timeout which could result in failure to get refreshed tokens sooner than the maximum timeout.
However, even the 30 days are not sufficient for your use case so the above fix would not address your concerns. The reality is that at this time only refresh tokens provide with a always lasting mechanism to renew tokens (at least until they are revoked); the unfortunate side-effect of that is that refresh tokens are not really suitable for browser-based applications.
From my perspective if you really need to provide a lifelong login experience I would consider having more than just a browser-based application. Most of the time developers already have a capable web server behind their browser-based applications that is simply not used fully and is mostly used only to serve the static files that will bootstrap the browser-based application. If you’re in a situation that you can easily go beyond just static file serving I would suggest you to consider the use of hybrid flows that could allow the immediate delivery of tokens to the client-side for increased user experience, but could also allow the use of grant types (authorization code) eligible to the use of refresh tokens.
You would then maintain refresh tokens at the server-side that could be used until explicitly revoked. This would imply that you should now maintain your notion of a session between your browser-based application and your server-side which is something regular web applications in general already do after processing the response from the identity provider. In theory you would be able to provide the typical user experience of a browser-based application while leveraging increased flexibility by having a server-side that does something more than just serving static files.