Hey all, just updating this post with my findings (special thanks to @john.gateley for his input here).
To recap, one of the major challenges was having multiple domains make requests to a single API. Each one having its own access token was not possible because I wasn’t able to know in advance what domain it was and therefore could not add it as an allowed origin. Therefore I was left with maintaining a single access token for a known domain. In this case, that known domain was my chrome extension.
Funnelling all the requests through the chrome extension’s service worker was fine, but a new challenge arose with refreshing the token. Since it’s a service worker, the act of launching an authorization flow can be a little jarring as a user experience, therefore I was looking for programmatic ways to get a new access token. Unfortunately, the available method (a refresh token) was worrisome since chrome’s native storage API is not necessarily a safe way to store these tokens.
Therefore I approached the authorization flow in another way. I placed an auth proxy infront of my API that maintains a session for the user on the same domain as the API. Thankfully, the work needed to this had already been done for me: auth0/express-openid-connect. Now my chrome extension doesn’t necessarily need to store anything since all requests include a session cookie, and the auth proxy can safely deal with refresh the session if necessary.
My final architecture looks like so:
