Best practice to handle expired refresh tokens?

Hello, I am using Azure AD as the auth provider and there is 24 hours lifetime of the refresh token. After 24 hours I am getting the following error in console log:

Does anyone have an advice how to handle this error? What is the best practice?

Currently I am thinking about handling it when access_token expires in this event by doing signOut.

mgr.events.addAccessTokenExpired(function () {
    log("token expired");    
    chrome.storage.local.get(['user'], (data) => {
        client.useRefreshToken({state: data["user"], timeoutInSeconds: 5 }).then(user => {
            console.log("refreshedToken user: ", user);
            mgr.storeUser(new oidc.User(user));
        }).catch(err => {
            // possible fail here is that the lifetime of the refreshToken ended.
            // for AzureAD it is 24 hours for SPA. 90 days for all other apps.
            console.error(err);
            globalThis.signOut();
        });
    });
});

I feel like this is not the best UX for the users to be automatically signed out every 24 hours. Is there a better way?

[Badisi]

@Alino, an expired refresh_token doesn’t mean the user's session has expired too. You don’t necessarily have to re-log in.

What the blue box means:

Usually the flow of ODIC Auth code + PKCE is as follow:

1. User navigates to your app (https://my-app.com)
2. Authentication is required
3. User is redirected to OP (https://my-op.com)
4. User authenticates
5. A session cookie associated to the OP is set in the web browser
6. User is redirected back to your app with a code
7. Your app now has to exchange the code with the OP to get the tokens (ie. id_token, access_token, refresh_token)
8. Your app can use the access_token to call your private APIs

---

1. When access_token is about to expire, an ajax call will be made with the refresh_token to get complete new tokens
2. And so on…

---

1. When refresh_token expire, you are stuck. You cannot ask for new tokens and there is no way to authenticate the user back without having him to interact somehow.

There is a technique though, where you could be using an hidden iframe that would navigate to the OP and re-use the session cookie. Allowing you to get tokens in returns, if a user’s session was still active. This is ideal (in theory) because completely transparent for the user.

But web browsers like Safari are now using privacy features (ITP - Intelligent Tracking Prevention) that prevents third party cookies to be sent, making this technique useless (ie. my-app.com cannot use cookies from my-op.com even in a child frame). If you want to use cookies from my-op.com then you have to be on my-op.com (top frame).

So the only solution is to navigate to the OP from the top level frame instead of the iframe:

1. Your app detects the refresh_token expiration
2. User is redirected to the OP
3. Session is retrieved on the OP (if still active) (thanks to the cookie)
4. User is directly redirected back to the app

=> no user interaction needed (just a back and forth, like if your app was refreshed) => regarding the UX, user’s would have to be prompted before the redirect occurs otherwise there is a risk for them to loose what they were doing

[Alino]

Understood, thank you. I have noticed the cookie inside the auth popups that are being opened when using chrome.identity.launchWebAuthFlow That brings me to the idea that I am going to test chrome.identity.launchWebAuthFlow with non interactive mode perhaps, to see if that renews the refresh_token.

EDIT: I have tested it, and it seems to work. But I am going to test for few more days.