Hey @dlohmann0! Welcome to the community! Apologies for the delayed response.
These are great questions. Session expiration is somewhat tricky, though, as there are many layers (app session, IDP session, 3rd party IDP session, etc). Usually it is simple in case of one app, but quickly becomes complex in case of multiple apps with different requirements. In those cases sometimes it may be ok to have unusual expiration times - like token expiration can be longer than the session. However most of the time such situation means that there wasn’t enough analysis and the customer should consider step-up/MFA instead. Long story short, normally, you’d have a shorter access token, longer refresh token, and a shorter session.
For a single page app, you could persist logged in state in different ways depending on the SDK you’re using. I presume you’re using auth0-spa-js, in which case there’s a method you’d provide as a ‘value’ to your Auth0.Context wrapper: getTokenSilently: (...p) => auth0Client.getTokenSilently(...p). Here’s an example app with this implemented (try deploying it, logging in and refreshing the page). It’s unofficial, but it’s based on Auth0 React SPA example and features persistence 
Now, when it comes to storing tokens in localStorage, there’s a theoretical risk of exposing this data in case of an XSS attack. With this being said, XSS attack is basically a “game over” anyway. So we suggest to put all efforts possible into preventing this kind of attack. To minimize damage in case of XSS attack, you could try minimizing sensitive data you store in a token and tweak it’s expiration time.
I hope this answers your questions. Please let me know if you need any details or clarifications regarding this.