Disclaimer: A definitive answer to these type of questions is always almost impossible to provide because the overall security for custom implementations that deviate from standardized approaches will depend on every detail and assumption of the implementation and that is usually impossible to translate into a single question.
One (bad) thing does stand out in your suggested approach; a client-side component within a browser-based application should not store refresh tokens. Refresh tokens are usually long-lived credentials and the browser environment is too hostile.
In conclusion, the standard way to implement your scenario and the one with less implementation efforts would be to use the hosted login page and silent authentication for token renewal.
As an additional note, we are considering improving the available scenarios for developers that cannot leverage the hosted login page due to strict requirements beyond their control, however, at this time these are not yet fully available.
It’s not allowing access with an expired access token; it is allowing access with a still valid local session. That still valid local session could allow you to obtain another access token by using the refresh token on the server, but this would be an implementation detail; the important part is that you would be managing access in your web application through a local session (cookie) and you never exposed refresh token in an environment that would be an XSS away from being compromised.
Both SPA’s and Web applications can keep the user signed in for a long a time; it’s just how they can do so that may be a bit different. Web applications with logic on the backends can use local sessions based on cookies to have complete control; for a SPA this would not be the case, so a SPA could be said that is more constrained in what it can do.