angular-auth-oidc-client: AutoLoginGuard appears to cause some sort of infinite loop.

I plan to test and release tomorrow 11.6.10

Hi Fabian,

Thanks for your response. I’m aware of the need to call checkAuth() on the public route. I just mentioned this, because I think it shows the root cause of this issue. Let me explain:

In the sample project (sample-code-flow-auto-login), when the checkAuth() is not commented, the following behavior occurs: When visiting the home page, you can click the link to the protected page, and the user is being redirected to the authorization server. When the user does not login, but instead navigates to the home page again or to any other public route, the user is immediately being redirected to the authorization server again. So, the home page and all other public routes are not reachable anymore.

The reason for this is the setting of the redirect key in the local storage. The call to checkAuth() always redirects to that page, even if the user is not authenticated. Once the redirect is set in local storage, every route gets redirected to the authorization server due to the CheckAuth() call in app.component.ts.

For this reason, I and I think others, have setup a specific path in our apps to which the authorization server redirects. So, we don’t need the checkAuth call, and simply set the AutoLoginGuard on that specific path. This is when the problem described in this issue occurs. The AutoLoginGuard also calls the checkAuth method, and that method is still redirecting to the page set in LocalStorage even when the user is not authenticated. This happens before the AutoLoginGuard is able to finish so it seems, and the due to the redirects, we have an infinite loop.

I think the problem lies here in the source code: https://github.com/damienbod/angular-auth-oidc-client/blob/main/projects/angular-auth-oidc-client/src/lib/check-auth.service.ts#L75

The user is always redirected, also when not authenticated.

I may have a solution: Add a authentication check before redirecting:

tap(() => {

        const isAuthenticated = this.authStateService.areAuthStorageTokensValid();

        if(isAuthenticated){

          const savedRouteForRedirect = this.autoLoginService.getStoredRedirectRoute();

          if (savedRouteForRedirect) {
            this.autoLoginService.deleteStoredRedirectRoute();
            this.router.navigateByUrl(savedRouteForRedirect);
          }
        }
      }),

This fix works in the sample project. CheckAuth() can be left uncommented, and the homepage is always reachable, with the redirect key in local storage.

It seems logical to me the user needs to be authenticated before being redirected, but maybe I’m missing something, I don’t know the library that well.

Thanks @robinvanderknaap for the PR!

Hey thanks for that response! That makes totally sense. Would you like to do a PR for that?

I was able to reproduce this problem with the sample-code-flow-auto-login project. If the call to checkAuth in app.component.ts is commented out, you can follow the steps as described by @chad-smith.

So, basically:

• Visit home page
• Navigate to /protected page
• Do not login!
• Visit home page again
• Navigate to /protected again, and keep the network tab open, you can see the authorize calls flooding in.

If you remove the redirect key in local storage. You can visit the protected page again, and the problem disappears.

I’ve spent some time trying to diagnose this, as it was occurring quite readily for us.

The first clue I came across was that it didn’t occur in earlier versions, so it could be traced back to an addition after 11.6.2

The second clue came when I finally tweaked the code enough to see where the loop was occuring(¹). This appeared to be along the lines of:

1. Visit /secure
2. User is not authenticated. AutoLoginGuard: a. Calls checkAuth (return false) b. Stores redirect url (‘redirect’ in localStorage) c. Takes you to the auth service
3. User cancels the auth request or it fails for some reason
4. User visits /secure again
5. User is still not authenticated.
6. AutoLoginGuard calls checkAuth a. Recently added code in checkAuth picks up the redirect url (‘/secure’) and redirects you b. GOTO 4

Incidentally this was occurring readily for us because we were hitting an issue with the silent renew request getting mixed up with a normal code flow request when we dropped our renew timeout down to a lower value to test it - this caused our authentication request to return a HTTP 400, eventually triggering the redirect loop.

¹. Debugging this was a pain because it triggered a location.href change in RedirectService, which caused the debugger to become ineffective, commenting this out allowed me to get further.

Have done a PR where the autologin works at my place https://github.com/grffn/demo-auto-login/pull/1

I’ll try to provide one

I’ve been unable to test the solution in our own codebase due to other backlog items, but it did correct the issue with the demo project, so I have high hopes.

I’d say go ahead and close this issue, I can open another or bump this if the issue resurfaces.

Thanks for the help.