@onpaws One big reason is that one of the reasons we introduced this feature is because cookies are being blocked by enhancements in browser privacy technology, such as Safari’s ITP or by default in Brave.
Strictly on the client side, we assume that this SDK is being used with a SPA architecture, meaning you probably won’t have a backend to set cookies. If you did, you would most likely be doing authentication on your backend and wouldn’t be using this library. In any case, the cookie in this scenario could not be HttpOnly as it would have to be read by JavaScript.
In the end, whether you store tokens in a cookie or in local storage doesn’t make too much difference as they both suffer from the same issues regarding XSS vulnerabilities and so on.
I do realize refresh token rotation means rotating refresh tokens frequently
You’re correct, but they also have built-in reuse detection - if a refresh token is leaked and used, a subsequent exchange will kick in the detection and the entire “family” of refresh tokens will be invalidated.