feat: implement timeout warning for SSO token timeout

[timisenco2015]

Description

There has been a reported issue of users suddenly being logged out due to token expiration. This feature will notify the users that their token is about to expire. They can log out or continue using the app and renew their token.

Types of changes

New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING doc
• I have checked that unit tests pass locally with my changes
• I have run the npm script lint on the frontend and backend
• [] I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• I have approval from the product owner for the contribution in this pull request

Further comments

[github-actions]

Coverage Report (Application)

Totals
Statements:	41.89% ( 2636 / 6292 )
Methods:	36.84% ( 326 / 885 )
Lines:	47.43% ( 1759 / 3709 )
Branches:	32.45% ( 551 / 1698 )

[github-actions]

Coverage Report (Frontend)

Totals
Statements:	67.45% ( 1142 / 1693 )
Methods:	64.24% ( 203 / 316 )
Lines:	71.61% ( 802 / 1120 )
Branches:	53.31% ( 137 / 257 )

[github-actions]

Release 3757a91 deployed at https://chefs-dev.apps.silver.devops.gov.bc.ca/pr-1067

[WalterMoar]

This 15 minutes value should be based on the token - it could be different in different environments or deployments, and we might wand to change it in Keycloak, which would break it here.

[timisenco2015]

The token expires every 5 minutes, and the refresh token every 30 minutes. Addition of both the Idle time and timer counter down is 25 minutes. This would allow users to refresh the token if they stay signed in

[WalterMoar]

But if we go into Keycloak and change the token to expire every 60 minutes, then this will be displayed too early. I think all the logic should be based on the timeout value in the token (not exactly sure what that is - maybe the exp?). I'll need to look into how these tokens are being used.

[bcvesalink]

@WalterMoar @timisenco2015 just to clarify and make my suggestion on this topic. Instead of asking user to login again, what if we store the refresh token in DB within the user table and then if any api call (Save form, Get form, etc.) returns 403 status, make keycloak api call to update access_token with stored in DB refresh_token so if it's still valid we would update the access_token in header?

[WalterMoar]

@WalterMoar @timisenco2015 just to clarify and make my suggestion on this topic. Instead of asking user to login again, what if we store the refresh token in DB within the user table and then if any api call (Save form, Get form, etc.) returns 403 status, make keycloak api call to update access_token with stored in DB refresh_token so if it's still valid we would update the access_token in header?

Interesting! I don't know if the API should be responsible for renewing tokens, though, and I think it would lose an important functionality that we are supposed to have now: 10 hour login sessions. And the refresh token is only valid for 30 minutes, so it wouldn't even get people through a coffee / lunch break, but the current "expected" behaviour should allow being idle all day. Just to clarify:

The behaviour now is that the access token has a lifespan of 5 minutes. Every 10 seconds it's checked to see if it expires in less than 60 seconds, and if so then it (and the refresh token) are refreshed - so the access token gets refreshed every 4 minutes:

    const updateTokenInterval = setInterval(
      () =>
        keycloak.updateToken(60).catch(() => {
          keycloak.clearToken();
        }),
      10000
    );

So the access token should be refreshed and valid from when the user logs in until 10 hours later (the maximum time an authenticated login is valid, as defined in Keycloak). In theory we should never have 403s in these 10 hours - the exception is that for some reason the access token is not being refreshed on this schedule.

In Chrome and Firefox on Windows this seems to work fine, although there might be some other use case I haven't tried yet. I think that for performance Chrome changes the interval for hidden tabs, but only if the interval is very small, so it shouldn't affect us. I'm also wondering if people are using some other browser that maybe has different behaviour for setInterval() when the browser tab is hidden, the browser is minimized, the screen is locked, etc.

[bcvesalink]

@WalterMoar @timisenco2015 just to clarify and make my suggestion on this topic. Instead of asking user to login again, what if we store the refresh token in DB within the user table and then if any api call (Save form, Get form, etc.) returns 403 status, make keycloak api call to update access_token with stored in DB refresh_token so if it's still valid we would update the access_token in header?

Interesting! I don't know if the API should be responsible for renewing tokens, though, and I think it would lose an important functionality that we are supposed to have now: 10 hour login sessions. And the refresh token is only valid for 30 minutes, so it wouldn't even get people through a coffee / lunch break, but the current "expected" behaviour should allow being idle all day. Just to clarify:

The behaviour now is that the access token has a lifespan of 5 minutes. Every 10 seconds it's checked to see if it expires in less than 60 seconds, and if so then it (and the refresh token) are refreshed - so the access token gets refreshed every 4 minutes:

    const updateTokenInterval = setInterval(
      () =>
        keycloak.updateToken(60).catch(() => {
          keycloak.clearToken();
        }),
      10000
    );

So the access token should be refreshed and valid from when the user logs in until 10 hours later (the maximum time an authenticated login is valid, as defined in Keycloak). In theory we should never have 403s in these 10 hours - the exception is that for some reason the access token is not being refreshed on this schedule.

In Chrome and Firefox on Windows this seems to work fine, although there might be some other use case I haven't tried yet. I think that for performance Chrome changes the interval for hidden tabs, but only if the interval is very small, so it shouldn't affect us. I'm also wondering if people are using some other browser that maybe has different behaviour for setInterval() when the browser tab is hidden, the browser is minimized, the screen is locked, etc.

it's not on API side to refresh the token, I meant on middleware side here https://github.com/bcgov/common-hosted-form-service/blob/master/app/src/forms/auth/middleware/userAccess.js#L39 but ok, if we we go for above you specify, should we even ask user to login again (popup window I mean). Can we just update the token without asking user?

[WalterMoar]

@WalterMoar @timisenco2015 just to clarify and make my suggestion on this topic. Instead of asking user to login again, what if we store the refresh token in DB within the user table and then if any api call (Save form, Get form, etc.) returns 403 status, make keycloak api call to update access_token with stored in DB refresh_token so if it's still valid we would update the access_token in header?

Interesting! I don't know if the API should be responsible for renewing tokens, though, and I think it would lose an important functionality that we are supposed to have now: 10 hour login sessions. And the refresh token is only valid for 30 minutes, so it wouldn't even get people through a coffee / lunch break, but the current "expected" behaviour should allow being idle all day. Just to clarify:
The behaviour now is that the access token has a lifespan of 5 minutes. Every 10 seconds it's checked to see if it expires in less than 60 seconds, and if so then it (and the refresh token) are refreshed - so the access token gets refreshed every 4 minutes:

    const updateTokenInterval = setInterval(
      () =>
        keycloak.updateToken(60).catch(() => {
          keycloak.clearToken();
        }),
      10000
    );

So the access token should be refreshed and valid from when the user logs in until 10 hours later (the maximum time an authenticated login is valid, as defined in Keycloak). In theory we should never have 403s in these 10 hours - the exception is that for some reason the access token is not being refreshed on this schedule.
In Chrome and Firefox on Windows this seems to work fine, although there might be some other use case I haven't tried yet. I think that for performance Chrome changes the interval for hidden tabs, but only if the interval is very small, so it shouldn't affect us. I'm also wondering if people are using some other browser that maybe has different behaviour for setInterval() when the browser tab is hidden, the browser is minimized, the screen is locked, etc.

it's not on API side to refresh the token, I meant on middleware side here https://github.com/bcgov/common-hosted-form-service/blob/master/app/src/forms/auth/middleware/userAccess.js#L39 but ok, if we we go for above you specify, should we even ask user to login again (popup window I mean). Can we just update the token without asking user?

Yes - this is exactly the thing - in the frontend we should already be automatically updating the token before it expires, and should continue to do so for 10 hours. In Confluence I asked the JEDI people if perhaps they are hitting the 10 hour limit. In that case, they will definitely have an expired token because it can no longer be renewed, and a new login will be needed.

I think that point in userAccess.js would be perfect for adding some logging about why the token is invalid. That might help us to diagnose the problem.

[WalterMoar]

Closing this since the problem the users are having does not seem to be due to timeouts.