Open DenyVeyten opened 2 years ago
I would like to second this request.
However, I need to make some notes about the link you provided. I am focused on the service worker(SW) approach listed in that link. However, there's currently a draft document talking about the security implications of such an approach (which also rules out all of the other approaches outlined).
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-7.4 It discourages the use of SWs as OAuth clients and lists a few reasons.
These approaches are made possible if the site itself is compromised. (It's best not to make things worse when something bad happens. In this case, an attacker that has compromised an origin could generate tokens for users at will. That's much worse.)
The problem is that while the SW can handle these requests and prevent the page from making them, it will be unable to do that in a new window/frame if the SW has been unregistered by malicious code first.
However, if you take a few precautions, this won't be an issue.
same-site: lax
or better.same-site
.(1-3) are likely best-practice for any serious IDP implementation.
All of these work together to prevent the page from initiating an authorization flow and obtaining an authorization code (together with the code_validator can be used to obtain an access and possible refresh token from any machine).
SWs do not stay active for long. Tricks to keep the tokens in scopes or globals don't work since they are reset when the SW sleeps and comes back.
You can hang state off of things like self.registration or self.serviceWorker (yuck) but those don't survive SW updates or page reloads.
What is needed is a secure, private store for things like tokens that the SW can use to persist information. The page must not have access to this storage. And it would be great if it were encrypted at rest on the filesystem.
The current options we have are all shared: indexedDB, Cache, cookieStore.
Web apps as public clients in OAuth2.0 need to save access and refresh tokens in a browser context.
There are different techniques to achieve this, but when we consider security and persistence (page refresh/tab reopen), there are only two options: http-only secure cookie or Service Worker.
There is performance issue with cookie where it's sent with every request to a domain that set it. Where access token is not needed sometimes and refresh token is not needed most of the time. Also, all requests to services that use that access token should be proxied via the same domain.
Service Worker approach has no such issues/limitations as app can decide explicitly when to attach token to a request. But it has two issues currently in comparison to cookie technique:
I think if those two issues could be solved, Service Worker approach would be the best practice to store access/refresh token.
Sorry if it looks stackoverflowy, I thought to post it in a form of feature request in case I got the aspects correctly. Would be glad to hear if these issues can be resolved by existing technologies.