When comparing oauth2 providers I find that Google, while being the most compliant has the absolute worst working examples of their code. Everytime I see example code from google I get the mental image picture of a 24 year old developer who claims "its works!" while not even considering how someone who has never used the technology they are proposing may interpret their completely uncommented code base.
This framework obscure the oauth process from the developer, so you are completely dependent on the code same being simple to understand to get the implementation working. Secondly creating the oauth app is buried deep in google's "API Dashboard"
Compare this to oauth2 providers that actually give you the curl approaches directly, and allow you to compare it to their API. The oauth implementation is not hidden, and you can easily figure out what needs to be done.
Here are my recommendations to oauth providers: Make the entire three legged process easy to natively implement Build auth apis that are simple extensions of that flow Make sure that the client api can access enough user information to create a user record on the target app without asking for more information. Make it easy for developer to create client app secrets and manage multiple environments.
Just like Shared Workers, a Service Worker runs in the background, but it can even run when your website is not actually open.
Daemons via http? Interesting.
Looks like requests are locked down to the origin (mostly... "importScripts()" & maybe CORS?). But other than that could be good for background update/notification checks, etc.