[Blazor][Wasm] Set oidc Authentication Options to Local Storage

Is there an existing issue for this?

• I have searched the existing issues

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

There is an existing issue for this but it is closed (#20574), I really think this feature is needed to allow the developer to choose where he wants to store. My current problem is that I choose Blazor as my frontend technology and I’m using ElectronJS as my container, I want to be able to allow the user to open multiple windows do make use of multiple monitors. Right now using SessionStorage, every time the user needs to Undock a panel into a separate window it triggers authentication again, I know it does not ask for credentials, it does it silently but it does go through the “Authorizing…” handshake before actually redirecting to the component. That is bad for user experience it is generating a new token in each new window. I tried to remediate this through Electron but it does not work, even populating the sessionStorage with the content of the main window it still goes through the authorization dance.

Describe the solution you’d like

I want to be able to set the Storage mechanism to be used, just like MsalAuthentication:

builder.Services.AddMsalAuthentication(options => { options.ProviderOptions.Cache.CacheLocation = "localStorage"; ... });

so it would be something like:

builder.Services.AddOidcAuthentication(options => { options.ProviderOptions.Cache.CacheLocation = "localStorage"; ... });

Additional context

No response

[gingters]

As a workaround, you can monkey patch the window.sessionStorage to point to the localStorage instead:

Just before including the AuthenticationService.js you can add this:

    <script>
        /* Monkey patch the localStorage onto the sessionStorage variable and accessor

           Since oidc-client-js by default uses sessionStorage and the Blazor AuthenticationService
           wrapper around it does not allow changing the configuration of that to localStorage,
           and because the wrapper directly uses window.sessionStorage for its own additional data,
           we have to change the global variable and the window property to point to localStorage instead.
        */
        const originalSessionStorage = window.sessionStorage;
        const sessionStorage = window.localStorage;
        Object.defineProperty(window, 'sessionStorage', { get: () => window.localStorage });
    </script>
    <script src="_content/Microsoft.AspNetCore.Components.WebAssembly.Authentication/AuthenticationService.js"></script>

Yes, this is a bit rough and when you still need to access sessionStorage you need to use originalSessionStorage instead, but it works and keeps you logged in between different browser sessions.

[ahmad2smile]

Please consider this feature more carefully than this comment:

https://github.com/dotnet/aspnetcore/issues/20574#issuecomment-610545261

I don’t think you should dismiss such a fundamental requirement on such a diverse platform like web. Many people have their own unique scenarios which you can’t possibly account for all, so giving more options is the right away here rather than locking ppl down cause you “know better” security.

To put a concrete example where exception is needed, I’m using OIDC Provider which has disabled iFrame with error:

Refused to display 'http://localhost:8080/' in a frame because it set 'X-Frame-Options' to 'deny'.

So, I endup having to manually login on each tab, Plus of it I don’t wanna call the server on each tab/new page load, Plus I’m building a internal tool where I’m perfectly happy to take risks of localStorage.