Support passing in a custom lock storage for use by browser-tabs-lock #1466
Description
Checklist
- I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
- I have looked into the documentation and API documentation, and have not found a suitable solution or answer.
- I have searched the issues and have not found a suitable solution or answer.
- I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- I agree to the terms within the Auth0 Code of Conduct.
Describe the problem you'd like to have solved
I'm trying to use this library within the service worker of a manifest v3 Chrome extension. This was explored on #831 and closed due to the dependency on browser-tabs-lock which has a dependency on window.localstorage which is not available in a manifest v3 chrome extension.
I understand the need for a locking mechanism, and I see that #1455 is currently open with a proposal to switch to the (relatively) new standard Web Locks API.
I appreciate that may take some time to implement, so I wondered if a simpler short term option to unblock could be to add an option on Auth0ClientOptions to provide a browser-tabs-lock compatible storage implementation.
The default constructor takes in an optional StorageHandler. The default implementation uses window.localStorage, but in theory any storage location that supports the synchronous access operations would suffice. (I note that the default implementation throw new Error("Unsupported"); on the async ops).
One objection to this may be that service workers don't have a synchronous storage mechanism available (the extension storage APIs are all async), however a common extension architecture is to have the service worker perform all operations, and for popups and content scripts on a range of tabs to send operations through the service worker. As such, all api calls would be in the same process space and an in memory lock storage should suffice.
Describe the ideal solution
Add lockStorage to Auth0ClientOptions that implements the StorageHandler interface from browser-tabs-lock. Warn that only the synchronous methods must be implemented, and that the storage should be available to any context that is attempting to share an authentication session.
Alternatives and current workarounds
The only other alternative is to bypass the library completely and implement a bespoke PKCE flow as explored in the community discussions here and here using the identity api and launchWebAuthFlow.
Additional context
No response