Assuming that all the tabs run on the same browser and therefore can share cookie storage, the following mechanism can be implemented:

1. Upon session start, every tab obtains it's own unique_tab_id.
2. The first tab is assigned as a tab_in_charge, who will dispatch everything there is to do regarding authentication.
3. When another tab needs to refresh the token, the tab sends a request to the tab_in_charge via a cookie or local storage.
4. The tab_in_charge has the obligation to check every X seconds if a refresh request has been submitted by another tab.
5. If there is more than one request to refresh the token, then it only accepts the first and rejects the other, as when the new access token is received, then all of the tabs will receive that token.

Another thing I would add here is Proactive Token Refreshing. You can use the iat and exp data from the token payload to calculate when it will expire, therefore giving you info about how much time you have. You can make it request a new access token 45 seconds before it expires, and adding this information in the request you send to the tab_in_charge.

Finally, you need to gracefully transfer the position of tab_in_charge to another tab if you are closing the current.

Assuming that all the tabs run on the same browser and therefore can share cookie storage, the following mechanism can be implemented:

1. Upon session start, every tab obtains it's own unique_tab_id.
2. The first tab is assigned as a tab_in_charge, who will dispatch everything there is to do regarding authentication.
3. When another tab needs to refresh the token, the tab sends a request to the tab_in_charge via a cookie or local storage.
4. The tab_in_charge has the obligation to check every X seconds if a refresh request has been submitted by another tab.
5. If there is more than one request to refresh the token, then it only accepts the first and rejects the other, as when the new access token is received, then all of the tabs will receive that token.

Another thing I would add here is Proactive Token Refreshing. You can use the iat and exp data from the token payload to calculate when it will expire, therefore giving you info about how much time you have. You can make it request a new access token 45 seconds before it expires, and adding this information in the request you send to the tab_in_charge. This will ensure resilient communication with your sockets, making sure there is zero down time while waiting for a new token or restarting the connection.

Finally, you need to gracefully transfer the position of tab_in_charge to another tab if you are closing the current.

So here is the problem we are faced with:

A client is authenticated and provided with two tokens:

• Access Token which can last for perhaps an hour.
• Refresh Token which can last for a day, a week or longer.

With this pretext, we can develop a mechanism where every API Response is intercepted by a function which detects an expired token response (Assume 401, but it could also be 422 since some libraries will not be able to process the token if it is invalid - an issue I have had with flask_jwt_extended.) When this is detected, you call the API to refresh your token. Now, there are two possible scenarios:

1. The Refresh Token has expired.
2. The Refresh Token is still alive.

In the case of 1, you need to send the user back to login and immediately clear any data that has been cached in the browser while he was authenticated.

In the case of 2, you need to obtain and store the new access token, after which you use that token to again call the initial route where your request failed due to an expired access token.

To address the issue of having a shared session, you could also store a flag - token_is_updating in local storage, which would instruct the other session to wait until the token_is_updating flag turns to false. This can be done via a shared local session within the browser.

Assuming that all the tabs run on the same browser and therefore can share cookie storage, the following mechanism can be implemented:

1. Upon session start, every tab obtains it's own unique_tab_id.
2. The first tab is assigned as a tab_in_charge, who will dispatch everything there is to do regarding authentication.
3. When another tab needs to refresh the token, the tab sends a request to the tab_in_charge via a cookie or local storage.
4. The tab_in_charge has the obligation to check every X seconds if a refresh request has been submitted by another tab.
5. If there is more than one request to refresh the token, then it only accepts the first and rejects the other, as when the new access token is received, then all of the tabs will receive that token.

Another thing I would add here is Proactive Token Refreshing. You can use the iat and exp data from the token payload to calculate when it will expire, therefore giving you info about how much time you have. You can make it request a new access token 45 seconds before it expires, and adding this information in the request you send to the tab_in_charge.

Finally, you need to gracefully transfer the position of tab_in_charge to another tab if you are closing the current.