Best practice to handle expired refresh tokens?

[Alino]

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?

[pamapa]

You could request a new refresh_token, something like:

const params = { "client_id": ...
  "scope": "other offline_access",
  "grant_type": "authorization_code"
  "code": ...
  ...
}
...
request refresh token via code/flow...

See https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

This library does not support that yet, but i would appreciate a patch to do so...

[Alino]

Thanks for reply, but it is not clear how you would request a new refresh_token without having to sign in again.

There is also this info

So it says an interactive authentication is needed after refresh_token expires.

So I guess my solution to sign out and display the login screen is correct? So that the user can interactively start the sign in again? EDIT: it says reload of the application is needed and the user does not have to see any UX. So now I think I can maybe just somewhere in the background execute some oidc sign in method?

I am really confused.

[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

---

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

---

11. 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:

11. Your app detects the refresh_token expiration
12. User is redirected to the OP
13. Session is retrieved on the OP (if still active) (thanks to the cookie)
14. 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]

@Badisi wow, thank you very much for this detailed answer. I will try to process this to create a solution. But I believe it will be more complicated for me since I am doing this inside a chrome extension service worker. But if I create a workable solution I will update my sample repo -> https://github.com/Alino/OIDC-client-ts-chromium-sample

[Badisi]

Another solution, would be to use the refresh token rotation (ie. when your application exchanges a refresh token to get a new access token (9), a new refresh token is also returned). More info : here.

As for what @pamapa was saying, I'm not sure what he was referring to. Maybe he could explain it a bit more :-)

[Alino]

I was trying to find this session cookie after I have authenticated by running document.cookie in devtools console but it gives me an empty string, so there is no cookie. Is this library supposed to store that cookie? I am not getting any error regarding this.

My idea is to find this session cookie and somehow reuse it to contact OP again from the service worker.

[Badisi]

Cookies are associated to a domain, you won't be able to see them or access them from script if you are on another domain (this is a security limitation). And cookies are mostly managed by web browsers themselves, they are stored when asked from a response header and sent when matching their policies, this library is not doing anything on this matter.

So the session cookie here is related to the OP, if you navigates to your OP url and watch for cookies in devtools from there, then you will see it. This is why the iframe technique was used -> because the iframe was actually navigating to the OP -> and being on the same domain the web browser was sending the stored cookie -> the redirect was then made in the iframe and a script was posting the result to the parent frame (ie. your app)

[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.