[Bug]: AutoLoginPartialRoutesGuard is not trying to silentRenew if refresh token still valid

[machovec]

Version

17

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

22:32:30.476 [DEBUG] XXX - persisted idToken and accessToken are valid angular-auth-oidc-client.js:214:13
22:32:31.287 Navigated to https://<our-identity-provider>/auth?client_id=...
22:32:31.302 [DEBUG] XXX - persisted accessToken is expired

Steps to reproduce the behavior

Setup configuration like so:
export const authConfig: PassedInitialConfig = {
  config: {
    ...environment.oauth,
    postLoginRoute: '/',
    forbiddenRoute: '/forbidden',
    unauthorizedRoute: '/unauthorized',
    authority: environment.oauth.authority,
    redirectUrl: `${window.location.origin}/callback`,
    postLogoutRedirectUri: `${window.location.origin}/logout`,
    historyCleanupOff: true,
    responseType: 'code',
    silentRenew: true,
    useRefreshToken: true,
    renewTimeBeforeTokenExpiresInSeconds: 270,
    secureRoutes: [environment.api.xxx, environment.api.yyy],
    ignoreNonceAfterRefresh: true,
    renewUserInfoAfterTokenRenew: true,
    triggerRefreshWhenIdTokenExpired: false,
    logLevel: LogLevel.Debug,
  }
}
Use AutoLoginPartialRoutesGuard to protect some routes

During navigating betwen protected routes (using menu or links) 
in case the navigation is timed right after accessToken is expired 
but before silentRenew finish renewing accessToken using refreshToken. 
Guard is checking using method checkAuth() witch leads to 
isAuthenticated be false and continous to loginService.login(). 
This is redirect to our Identity provider and calls /auth endpoint 
starting new Code flow PKCE. This can by finished but in cost of 
returning in to app using /callback endpoint witch leads to lose app state on client.

A clear and concise description of what you expected to happen.

I wonder why AutoLoginPartialRoutesGuard is not 
trying to use still valid refreshToken to obtain new accessToken? 

I expect to try use refreshToken if is valid and only after fail start new login flow from scratch.

Additional context

No response

[machovec]

Probably this issue has same source like in #1883?

[GeroldSchierholz]

Its related but we are not using the guard but call oidcSecurityService methods. This is why your fix will not solve the general problem but good idea to just override the "renewTimeBeforeTokenExpiresInSeconds" - although it looks like a hack ;)

[machovec]

I knew it was more of a hack. Unfortunately, I did not allow myself to make major changes. For now, we are trying to solve it using our own guard, which checks whether silentRefresh is running and possibly delays the evaluation of AutoLoginPartialRoutesGuard. Maybe AutoLoginPartialRoutesGuard could/should check itself this way too?

[shinokamparos]

Hi @machovec ,

In your custom guard, how are you determining whether a silentRefresh is running? We need to look at something similar to adress this issue.

We are using iframe for silent renew, not using refresh tokens.

[machovec]

Hi @shinokamparos

Unfortunetly, we ended implementing custom guard due to we were not able to correctli detect this state due to not public api for this informations. So we try switch to different library (angular-oauth2-oidc) in one smaller project and so far we are satisfied and we are plannig to migrate also another projects to use this library insted.

[shinokamparos]

Thanks @machovec .

Did you abandon AutoLoginPartialRoutesGuard altogether or did you put your custom guard in front of it?

I'm interested in your approach for that custom guard? What did you do there? Is it satisfactory? Is this the sole reason you are moving to angular-oauth2-oidc?

[FabianGosebrink]

You can check for a sample application using guards here https://github.com/FabianGosebrink/doggo-rate-app/blob/main/angular/libs/shared/util-auth/src/lib/guards/auth.guard.ts

[machovec]

And do you have any information that behaviour of isAuthenticated was changed? Because original problem was that this was returning false even if app has still valid token's perfectly fine for backend calls, but due to configured renewTimeBeforeTokenExpiresInSeconds was validity calculated to false and refresh flow (correctly) started by library. But in guard at this exact time this leads to user leaving protected page due to redirecting to logout page for example and losing some state in app, because new login was needed.

[shinokamparos]

Thanks @FabianGosebrink
I was more asking about what in particular @machovec did in his custom guard as a workaround for this issue. Would you have any suggestions?

@machovec would you be able to shed any light on this? I would be interested to hear what approach you took.

[machovec]

I'm sorry, but there was probably some misunderstanding (my English is not the best).

In the end, we failed and didn't implement any CustomGuard. Because we were not able to detect if there was any refresh process going on, so we moved to another library.

Therefore, I am not able to provide any example of how we did it.