solid-client-authn-browser should use storage abstraction for storing a current session or offer control of a namespace in the localstorage

Search terms you've used

currentSession, prefix localstorage, localstorage, sub diretory,

Impacted package

Which packages do you think might be impacted by the bug ?

• solid-client-authn-browser
• solid-client-authn-node
• solid-client-authn-core
• oidc-client-ext
• Other (please specify): ...

Bug description

I have a use case where I have 2 or more solid apps in the same domain under a different path. Each app uses
localstorage for session management with a unique prefix (e.g. app1.string.solidClientAuthenticationUser:...). This works fine apart
for the currentSession in combination with the restorePreviousSession option. Logging in to another application will cause the restore session to fail for other apps in the domain.

According to the description: https://github.com/inrupt/solid-client-authn-js/blob/3fd7bb44de656bf044e9b09bb3f29fcada5e8de4/packages/browser/src/Session.ts#L227-L233
the reason for not using the storage abstraction layer is because of the browser-only context where
this current session is stored. However, as a developer there is no control with this decision.
There is also no way to change the namespace of the localstorage to include a prefix.

To Reproduce

1. Create two applications under the same domain in different sub directories (/app1, /app2 )
2. Use a custom storage method (localstorage) with a unique prefix for each sub directory
3. Log in to /app1 with restorePreviousSession enabled
4. Refresh the page (you will not have to log in)
5. Visit /app2 with ``restorePreviousSession` enabled and log in
6. Refresh the page (you will not have to log in)
7. Visit /app1 again, you will have to log in again

Expected result

I would expect solid-client-authn-browser to use the storage method that is provided, or to have some control in the key that is used (i.e. a prefix). Developers are also not able to handle the storing of a current session themselves due to the unexported silentlyAuthenticate.

Personally I feel that it should use the provided storage method - as this method is used to find the session information
https://github.com/inrupt/solid-client-authn-js/blob/3fd7bb44de656bf044e9b09bb3f29fcada5e8de4/packages/browser/src/Session.ts#L350-L368

Actual result

The client library has full control over the key causing unexpected behaviour as mentioned in the bug report.

Environment

    @inrupt/solid-client-authn-browser: ^1.11.7 => 1.11.7

Start in packages/browser/src/Session.ts, especially the current-session handling around lines 227-233 and the session lookup around lines 350-368. Compare how the provided storage method and its prefix are used with how the current session key is stored. Done means separate applications on one domain can restore their own sessions without interfering with one another.