Angular-auth-oidc-client: getIsAuthorized() does not wait for token validation to resolve.

Created on 28 Jun 2018  路  4Comments  路  Source: damienbod/angular-auth-oidc-client

Hi - first of all thanks for creating this library!

I am currently faced with this problem:

  • user visits /dashboard
  • loggedInGuard checks if user is authenticated (false), because there is no # symbol in the url we perform oidc authorize call.
  • User logs in, oidc redirects to /dashboard, the token validation begins.
  • the logged in guard checks if the user is logged in, which returns false because the token is still being validated. Because there is no # in the url, no authorize() call is performed. The loggedInGuard returns false. The user now sees a the '/unauthorized' page, despite being successfully authenticated.
  • token validation ends, and when the authorized event comes through the url that the user was trying to visit ('/dashboard') is loaded from the session storage and the user is redirected.

To resolve this issue, I have modified the loggedInGuard as following:

  canActivate(_route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
    return this.userService.isLoggedIn$
    .switchMap((isAuthorized: boolean) => {
        if (isAuthorized) {
            return Observable.of(true);
        }

        // This hash check is here because the oidc server will redirect us back to the frontend like this:
        // /dashboard#id_token=...
        // Therefore, this check should be interpreted as 'Did we come from the oidc login page?'.
        if (!window.location.hash) {
          this.userService.urlAfterLogin = state.url;
          this.router.navigate(['/login']);
          return Observable.of(false);
        } else {
          return this.oidSecurityService.onAuthorizationResult
          .take(1)
          .map((authorizationResult) => {
            if (authorizationResult === AuthorizationResult.authorized) {
              return true;
            }

            this.router.navigate(['/unauthorized']);
            return false;
          });
        }
    });

This is not ideal because I have no guarantee that the authorization result event is about to be fired. In other words, I have no idea whether oidcService.getIsAuthorized() or oidcService.onAuthorizationResult() is the appropriate action, because I have no way of knowing whether the token is currently being validated. Since getIsAuthorized() is an observable, I would expect it to wait for the token validation to complete before sending back the result.

Please let me know if I am misunderstanding something about the correct usage of this library. Thanks again!

EDIT: I should note that I am on [email protected], so this problem might already be resolved. If so, any advice on how to approach the solution would be welcome (this is quite a large project with lots of dependencies, so upgrading will probably not be possible in the foreseeable future)

enhancement

Most helpful comment

I have the same identical problem in my application.
Checking the angular-auth-oidc-client code I saw that the getIsAuthorized method is backed by a BehaviourSubject initialized to false, so if someone calls this method before the auth is completed it immediately returns this value.

I think that simply changing the default value to a null or similar value could allow to distingush between auth not completed and auth failed

All 4 comments

I have the same problem. Login -> unauthorized -> home page. and then if i try again to login, it works and redirects to the right page.

I have the same identical problem in my application.
Checking the angular-auth-oidc-client code I saw that the getIsAuthorized method is backed by a BehaviourSubject initialized to false, so if someone calls this method before the auth is completed it immediately returns this value.

I think that simply changing the default value to a null or similar value could allow to distingush between auth not completed and auth failed

fixed in version 6.0.12

fixed in version 6.0.12

Correct, it seems to be reintroduced in 7.0.1, once I rolled back to 6.0.12 it was fine

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nizarkhsib picture nizarkhsib  路  4Comments

yelhouti picture yelhouti  路  4Comments

cgatian picture cgatian  路  4Comments

jhossy picture jhossy  路  4Comments

sdev95 picture sdev95  路  3Comments