Waking up from sleep

[pbklink]

oidc-client-ts does not seem to handle the computer going to sleep. When the computer wakes up, typically the error that occurs is:

[SilentRenewService] _tokenExpiring: Error from signinSilent: IFrame timed out without a response

and oidc-client-ts stops trying to silently refresh the token.

My main question is, should this be handled in my application or by oidc-client-ts?

If I need to handle in my application, first I would need to detect this condition. My thinking is to use the Page Visibility API. Whenever the page becomes visible, I would check for a timeout problem in oidc-client-ts. If this is detected, I would try to get oidc-client-ts to continue its silent refreshing with UserManager.signinSilent().

It is possible (though unlikely) that the refresh token has timed out if the computer has been asleep for a long time. So if UserManager.signinSilent() fails, I would try again with UserManager.signinRedirect() however that would effectively restart my application.

Any ideas on how this can be handled?
If my application has to handle this, how could it detect that oidc-client-ts has timed out and is no longer doing silent refreshes?

Thanks for your help.

[kherock]

I've also noticed this but haven't gotten far enough along in the app I'm working on to realize a good fix for it. I do think that the existing timers aren't appropriate in that they are subject to pausing when the tab is suspended, such as when the system goes to sleep.

I'm not entirely sure why the iframe times out. My best guess is that when page isn't visible, the iframe spawned by the session monitor doesn't load until it becomes visible again. If we're unable to spawn an iframe in the background, there's not much we can do to ensure the session is refreshed in time.

I'll have time to experiment with this soon, I think some combination of following should help:

• replace setTimeout / setInterval of durations lasting longer than a minute with 30-second timers that compare a timestamp to absolute time
• avoid spawning iframes when the document is hidden, or avoid cancelling the silent renew service if the document is hidden at the time of failure.

[pbklink]

Not sure if you are familiar with throttling of Chrome timers: https://developer.chrome.com/blog/timer-throttling-in-chrome-88.

You probably cannot use a timer with duration of less than 1 minute when the page is not visible.

[kherock]

That behavior is ok. Also I was mistaken in how we currently handle timers, the workaround I had in mind is already implemented:

oidc-client-ts/src/utils/Timer.ts

Lines 59 to 61 in 63ea517

	// we're using a fairly short timer and then checking the expiration in the
	// callback to handle scenarios where the browser device sleeps, and then
	// the timers end up getting delayed.

The only I problem I can identify now is in how we spawn iframes while the page is hidden.

[pbklink]

If the page is not visible (browser minimised or tab in background) for 5 minutes, then I think Chrome will apply intensive throttling to this timer. Instead of being 5 seconds, it will become 60 seconds.

If DefaultAccessTokenExpiringNotificationTimeInSeconds is 60 seconds, could this become a problem?

[pamapa]

I am seeing this too. Also this does not seem something new as you can see here IdentityModel/oidc-client-js#172.

I was reading other libraries code and they seem to do it quite similar, as you can see here. One interesting part though is the sand-boxing, we should do the same for sake of security i guess.

[pamapa]

Idea: Maybe we just have to accept this IFrame timed out without a response caused by browser tab sleep. But we can more gracefully react on it. By doing a new fresh silent renew request and if that one is good no need to raise an error to the events listeners, if not ok the 2nd time raise an error and tell the world.

[longsleep]

I am not exactly sure why this is a problem. The iframe can time out for all kind of reasons. The application using the library must deal with it in its addSilentRenewError handler.

What we have been doing for a long time on silent renew errors goes like this:

1. check error reason (if there is any), if there is a known one like interaction_required or login_required, trigger removeUser and be done.
2. For any other error, use setTimeout to schedule a getUser after a few seconds and if that yields a user which is not expired trigger stopSilentRenew and immediately startSilentRenew again (this makes silent renew work again, for example after resume). If getUser here did not return a user or the user is expired, trigger removeUser and be done.

Example: https://github.com/Kopano-dev/kpop/blob/master/src/oidc/actions.js#L521-L551

[pamapa]

@longsleep thanks for sharing those behaviors, makes all sense! Maybe its possible to move that (or parts of it, specially your point 2 except removeUser) down to the library, as such not everybody needs to deal with all that.

If that is not possible we can maybe extend our https://github.com/authts/react-oidc-context library.

[pamapa]

@kherock something like this in the react-oidc-context?

        // event SilentRenewError (silent renew error)
        const handleSilentRenewError = (error: Error) => {
            // check for the hopeless
            if (error.name === "ErrorResponse") {
                // application must take care
                dispatch({ type: "ERROR", error });
                return;
            }

            // retrying silent renew
            setTimeout(async () => {
                const user = await userManager.getUser();
                if (user && (!user.expired || user.refresh_token)) {
                    userManager.stopSilentRenew();
                    userManager.startSilentRenew();
                } else {
                    // application must take care
                    dispatch({ type: "ERROR", error });                
                }
              }, 5 * 1000);
        };
        userManager.events.addSilentRenewError(handleSilentRenewError);

• Should we move this into oidc-client-ts?

[longsleep]

• Should we move this into oidc-client-ts?

I think handling this error is very application specific. Maybe a "default" silent renew handler would be in order, but it should be possible to override/replace it completely if one needs different behavior.

[pamapa]

After thinking more about this:

As a user of this library i would expect the silent renew process to continue until the auth server responses with an error response. For the likes of iframe timeout out due to TAB/PC sleep or network not connected it shall continue/retry. This whole behavior should be default, but user should be able to disable this by a new settings parameter.

[bh3605]

I would expect the silent renew process to be a best effort and only attempt to renew one time. Having a timeoutduration setting to increase or decrease the default time and having a class that can replace the default renewal behavior so people could implement their own retry logic could be helpful as well.

[Badisi]

Never faced this issue while putting my MacBook into sleep.. but I faced it on mobile though.

When putting my ionic app into sleep (ie. moving it to background) the oidc-client interval (which checks for token expiration ) stops executing. Waking up the app from background will then triggers an AccessTokenExpired event.

So my fix was to listen for that particular event and try a potential silent renew :

this.userManager.events.addAccessTokenExpired(() => {
    // Token can expire while the app is in background
    //   -> try a silent renew in that case and otherwise redirect to home
    if (this.settings.automaticSilentRenew) {
        this.userManager.signinSilent().catch(error => this.redirect('/', error));
    }
});

[pbklink]

Further investigated why my application is not recovering from sleep. Implemented code as suggested by @longsleep and @pamapa above. However user.refresh_token is undefined.

I reviewed and debugged with the oidc-client-ts source code to see how the refresh token is retrieved however could not figure out how this should work.

Any hints as to how I can further troubleshoot this problem?

[pamapa]

By default the refresh_token is not requested, as it is dangerous to have it in the browser context exposed to users. Typically you need to add offline_access into scope and configure something on the auth server side.
The best practice (in browser exposed to users) is to refresh the access token by using the silent renew process (which as support for with and without refresh_token, aka iframe prompt=none).

[CanD42]

Hi, we see in Chrome after PC woke up from sleep:

POST https://accounts400.sap.com/oauth2/token net::ERR_INTERNET_DISCONNECTED
[JsonService] postForm: Network error
[SilentRenewService] _tokenExpiring: Error from signinSilent: TypeError: Failed to fetch

and the library isn't recovering from that error (automaticSilentRenew is true) and token renewal is working fine otherwise.
Is there something we can do here?

Thanks,
Daniel

[pamapa]

@CanD42 Please make a new issue and add a link to this issue. This issue is old and already closed...