Hacker News new | past | comments | ask | show | jobs | submit login

Ciao guys, what could be the use case for such API?



This was the use case[0] that brought it to my attention:

- single page application using access and refresh tokens to interact with an API

- refresh is one time use, as recommended by the OAuth security best practices[1]

- SPA is open in more than one tab

- two tabs try to refresh the token at the same time, second one fails because refresh token is used up

0: https://bsky.app/profile/ambarvm.bsky.social/post/3lakznzipt...

1: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...


Thanks for this, I've been using the localstorage for the same use case a while ago, I'll try to go back and update it.


I guess I don't actually get the point, because if I am locking a resource in one tab so that other tabs can't use that resource... how is that not going to lead to behavior that a user would think was broken.

Two tabs try to refresh the token at the same time, user opened tab 2, tab 2 can't refresh because things locked in tab 1 - user thinks app is broken? Isn't that the way it would happen. I guess you can detect it is locked in another tab though so you could give the user a warning about this?

I guess I am missing something about the scenario..


It's not locking the UI refresh, it is only locking the access token refresh.

Let's play it out.

- User authenticates, gets an access token A1 and a refresh token R1. R1 is one time use only.

- A1 and R1 are stored as cookies (secure and httponly to prevent XSS).

- A1 is used to access multiple APIs, but is only good for 5 minutes.

- The SPA opens up a new tab for whatever reason, so the browser is making requests to the APIs from both tabs (T1 and T2)

- 5 minutes passes, and T1 tries to call an API. The API call fails because A1 is not valid. T1 then makes a request to the OAuth server with R1, which returns a new access token (A2), a new refresh token (R2) and invalidates R1.

- 0.1 seconds later, T2 tries to call an API with A1, and also discovers it needs to get a new access token. It tries to use R1, but R1 is invalid because it has already been used

With this locking API, T1 could lock access to R1 when it was about to use it. T2 would then see the lock request fail, and not try to use R1. After R2 has been stored, T2 could use R2 (or T2 could use A2).


thanks, this was the part that clarified for me "After R2 has been stored, T2 could use R2 (or T2 could use A2)."


Awesome, glad it helped!


Maybe it's old person yelling at cloud vibes, but I'm already annoyed enough at the majority of SPAs for breaking so many useful default browser features, such as stable links, navigation, multi-tab functionality, open in new tab etc. This is only gonna make them even more cancer my gut feeling tells me.


Oh yeah, I agree. I personally like the rails approach of light JS for necessary interaction, but keeping all logic serverside.

The URL is the command line and all that.

But like you, I sometimes feel like an old person yelling at the cloud.


if a crypto miner infects a site you have several tabs open they won't fight for cpu at the same time.


Besides what sibling has written, write access to IndexedDB also often needs to be guarded by a mutex https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...


I don't get this complaint, because IndexedDB supports transactions. Why are these insufficient?


IndexedDB transactions give guarantees about atomicity but not about isolation. Note that the word "isolation" doesn't appear in the spec https://w3c.github.io/IndexedDB/


share a websocket/sse connection via a worker


Click the link, read the words. There's a list in it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: