Okta authState$ for Route resolving

[roddev-v]

Describe the bug

Hi there! I encountered the following issue while working with OktaAuth and I wanted to identify a possible fix or bug to this scenario. This is my first time posting an issue on OSS! Sorry in advance for possible mistakes!

In my team we wanted to use okta-angular and the authState$ observable from the OktaAuthStateService inside a main Router resolver to load the user state and additional userProfile before the UI is rendered. Due to the nature of the Resolver we converted the authState$ to a Promise to handle state changes until the Route is resolved. The point is that we need to wait for an Authenticated state before loading content.

The issue is that the okta-angular wrapper over the @okta-auth-js package wraps the authStateManager in a BehaviorSubject that will resolve firstly an 'isAuthenticated: false' in stead of the original state (null). This approach causes a route resolving strategy to be complex to solve since implies multiple possible state changes. In my testing scenario I noticed aspects as:

const {authState$} = inject(OktaAuthStateService); authState$.console.log(state => console.log(state.isAuthenticated))

• User not logged in: false -> false
• User log-in with SSO (AD) provider: false -> true
• User logged-in from previous session: false -> true
• User logged-in with user/password: false -> false -> true
• Redirect to callbackUrl -> One state update as false

Due to the unpredictable state changes a handler for the route get's very complicated to handle without hogging the route and assuming various strategies.

If this can be considered a bug, can the okta-angular package resolve in any way the actual auth state and not an initial isAuthenticated: false state and possible N other updates to the user auth state? I found this limitation in this specific resolving scenario where the data is needed before the page get's rendered.

I tried various operators to takeUntil the right state is emitted but this resolving issue makes the scenario of loading data before interaction complicated to handle.

Reproduction Steps?

1. Create an Angular project and install @okta-angular
2. On the main route of the application attach the following resolver:

export function oktaResolver: ResolveFn = () =>  {
  const oktaAuth = inject(OktaAuthStateService);
  
  return new Promise(resolve => {
  // values emitted: isAuthenticated: false / isAuthenticated: true
  // By the time I get the actual true state I already resolved the routing in order not to block the navigation
  // Would be awesome if the authState$ could resolve a single final state since the Angular resolver when it's server as a 
  // promise to await the route resolution will need a single value emitted.

    oktaAuth.authState$.subscribe(({isAuthenticated}) => {
      if(isAuthenticated) {
        // load extra user data;
        resolve();
      }
      resolve();
    })
  });
}

3. Try a Redirect log-in and try to resolve the route without having to handle multiple state changes when the auth State get's updated

SDK Versions

@okta-angular 6.3.1
@okta-auth-js: 7.5.1

Additional Information

No response

[jaredperreault-okta]

@roddev-v Can I ask a few clarifying questions?

• Is there a reason you're using a resolver instead of a guard?
• Is there a reason you need your route to resolve in both authenticated and unauthenticated states?
  • It may be easier to have separate code paths (routes) for the different states and simply redirect to Components which are expecting unauthenticated states when a user attempts to access a route requiring authentication

[roddev-v]

@jaredperreault-okta Sure. Thanks for the reply!

• In our application we have a dedicated guard that handles the security checks. The resolver was added as an extra step to have the data ready before the main user interaction starts. The purpose of this resolver was just to load data. That shouldn't decide if the navigation can complete.
• To clarify it: In our setup we have a main wrapper component that holds all of our sub-routing and components that need to tap into the user state. Having a single entry point made sense to include a step to resolve the user state after the guard granted access. I'm not interested in the unauthenticated state. I was only interested to get the right state without possible unauthenticated values after a SSO login.
• It might be easier but the requirement was to have the user state ready before the application starts so we can kick in other actions.

Hope it clears out a bit. I can follow-up with other info if needed. Thanks!

[alisaduncan]

Hi there, @roddev-v ! I work with @jaredperreault-okta at Okta, so I hope you are okay with me joining this thread. I appreciate your clarification. It's beneficial!

To make sure I understand, do you happen to have the resolver defined on the sub-route that requires authentication for navigation or another route? I'm trying to ensure I know what you mean by the resolver shouldn't decide if the navigation can complete. Can you share a snippet of your route definitions (feel free to redact/substitute whatever is private) so we can see where the guards and resolvers are defined?

Regarding using the authState$ to ignore unauthenticated state, I've used the filter operator. Would something like this work for you?

export const userProfileResolver: ResolveFn<string> =
(route, state, oktaAuthStateService = inject(OktaAuthStateService), oktaAuth = inject(OKTA_AUTH)) => {
  return oktaAuthStateService.authState$.pipe(
    filter((authState: AuthState) => !!authState.isAuthenticated),
    switchMap(_ => defer(() => oktaAuth.token.getUserInfo())),
    map((userClaims:UserClaims<CustomUserClaims>) => (userClaims.preferred_username ?? 'Awesome dev'))
  );
};

[roddev-v]

Hi there @alisaduncan . Thanks for joining in! Highly appreciated. Regarding the router setup, I have the following structure:

const routes: Routes = [
  {
    path: '',
    component: AppWrapperComponent,
    resolve: [UserResolver],
    children: [
      {
        path: '',
        pathMatch: 'full',
        redirectTo: '/a',
      },
      {
        path: 'a',
        component: ComponentA,
        canActivate: [authGuard],
      },
      {
        path: 'b',
        component: ComponentB,
        canActivate: [authGuard],
      },
    ],
  },
];

We have a series of public and private routes. The private routes have an authGuard attached to them while the public ones have none.

The main resolver will resolve the user state as follow:

export function UserResolver(): ResolveFn<boolean> {
  const oktaAuthService = inject(OktaAuthStateService);
  const oktaAuth = inject(OKTA_AUTH);

  return () => {
    return oktaAuthService.authState$.pipe(
      filter((state) => !!state),
      switchMap((state) =>
        state.isAuthenticated ? oktaAuth.getUser() : of(null)
      ),
      map((user) => !!user)
    );
  };
}

To control access to specific routes we use this Guard: (simplified. We have other security/environment checks but this okta step is part of the actual check.)

export const authGuardGuard: CanActivateFn = async (route, state) => {
  const oktaAuth = inject(OKTA_AUTH);
  return !!(await oktaAuth.getUser());
};

The issue that we face is the fact that the okta.authState$ might not fire the right state after some user interaction and thus never resolving the route navigation. For example after a SSO login(with our corporate Identity provider), when the Okta will redirect back to the application, the authState$ might not fire the {isAuthorized: true} event. Thanks for reaching out! If anything else is needed I could try to provide additional info.

[jaredperreault-okta]

Just to make sure I understand the flow, a user is:

1. redirected to Okta
2. redirected to corporate IdP
3. redirected back to Okta
4. redirected to App (with auth code) <--- breaks here, authState$ event is not triggered

How are you processing the Auth Code redirect (aka LoginCallback)?

[roddev-v]

@jaredperreault-okta We process the redirect using the base OktaCallbackComponent. That route is exposed outside the Resolver-wrapped routes.

[jaredperreault-okta]

For example after a SSO login(with our corporate Identity provider), when the Okta will redirect back to the application, the authState$ might not fire the {isAuthorized: true} event

Do see a request to /tokens in your network tab when this occurs?

[roddev-v]

@jaredperreault-okta Yes. the /tokens request is proccessed.

[jaredperreault-okta]

@roddev-v You may need to reach to https://support.okta.com/, I am not sure how to reproduce your issue. It seems like it only occurs when an authorization code redirect after an SSO login via company-Idp is utilized.

Are you able to reproduce the issue with https://github.com/okta/samples-js-angular/tree/master/okta-hosted-login?

[roddev-v]

@jaredperreault-okta Thanks a lot for all the support! I think we can close this bug for now until further notice.I'll try to reproduce it with the provided sample and if needed, I'll re-open with a more proper sandbox. Thanks again for all the support!