Client specified not to prompt and blank page after session expire

[polklabs]

I'm submitting a:

• Bug report
• Feature request
• Other (Describe below)

Current behavior

When opening app which requires okta authentication the user is not redirected to sign in. They just see a blank page with nothing.
In the console is the error: The client specified not to prompt, but the user is not logged in
To trigger redirect you have to refresh the page (opening dev tools also triggers redirect)

Expected behavior

Okta automatically redirects user to sign in page and then returns user to app after login

Minimal reproduction of the problem with instructions

Steps to reproduce:

1. login to the web app
2. close the browser (no logout)
3. wait for the token and the refresh token to expire
4. open the web app

blank page, no redirect with error message in console.
The client specified not to prompt, but the user is not logged in

Extra information about the use case/user story you are trying to implement

It was working perfectly in the old version
"@okta/okta-angular": "^3.1.0",
"@okta/okta-auth-js": "^4.9.1",
but has stopped working since updating

Environment

• Package version: 4.1.0
• Angular version: 10.2.3
• Browser: Chrome
• OS: win32 x64
• Node version (node -v): 16.13.0
• Other: @okta/okta-auth-js: 5.6.0

Configuration

• Okta application type: Okta hosted signin widget

[jaredperreault-okta]

@polklabs Do you mind providing a code snippet that causes this behavior?

[polklabs]

@jaredperreault-okta Can't really provide too much code at the moment. But here are some potentially relevant snippets. Maybe I missed something upgrading from version 3.x to 4.x?

Almost all site routes are protected, only routes that aren't protected are /logout and /implicit/callback

const routes: Routes = [
     {
        path: 'home',
        loadChildren: () => import('./home/home.module').then(m => m.HomeModule),
        canActivateChild: [ OktaAuthGuard ]
    },
]

App.module.ts

const oktaConfig: OktaAuthOptions = {
  clientId: environment.otkaClientId,
  issuer: environment.oktaIssuer,
  redirectUri: environment.HomeUrl + 'implicit/callback',
  scopes: ['profile', 'openid'],
  tokenManager: {
    expireEarlySeconds: 30,
  },
  devMode: false // environment.production === false
};
const oktaAuth = new OktaAuth(oktaConfig);

@NgModule({
  declarations: [
    AppComponent,
    ...
    LogoutComponent,
    RedirectingComponent,
    ImplicitCallbackComponent,
  ],
  imports: [
    BrowserAnimationsModule,

    ...

    OktaAuthModule
  ],
  exports: [
    OktaAuthModule
  ],
  providers: [
    { provide: OKTA_CONFIG, useValue: {oktaAuth}}
  ],
  bootstrap: [
    AppComponent
  ]
})
export class AppModule { }

[jaredperreault-okta]

Thanks for reporting this, we'll look into it

Internal Ref: OKTA-447151

[tlahav]

Hi. Piggie backing off of this, I have experienced the same in multiple Production applications as well. Here is my ticket on the Okta board for reference: https://devforum.okta.com/t/users-are-not-redirected-to-log-in-widget-when-returning-to-page-after-a-token-timeout/17830

@jaredperreault-okta I have also opened a support ticket in Okta Support (#01235377) if it helps!

[jaredperreault-okta]

@icatchx22i What version of angular are you using? And did you also experience this issue after migrating to version 4.x of okta-angular?

[tlahav]

We're using Angular 12 and yes still experiencing after upgrading to the latest okta-angular and okta-auth-js:
"@okta/okta-angular": "^4.1.0",
"@okta/okta-auth-js": "^5.6.0"

Our base route looks like this:
{ path: 'implicit/callback', component: OktaCallbackComponent },
{ path: '', canActivate: [OktaAuthGuard], loadChildren: () => import('../../components/my-forms/my-forms.module').then(m => m.MyFormsModule)},

We also tried placing the Guards inside the MyFormsModule routing instead. But that did not improve the situation.

Can this be some kind of Lazyloading / Redirect deadlock? I noticed both examples here use lazy loading.

[tlahav]

FYI: I also tested the routes with canLoad instead of canActivate but that did not help

[polklabs]

@jaredperreault-okta Any updates on this?

[shuowu]

@polklabs The issue might related to the mis-use of different route callbacks, here is a guideline for it:

• Set canLoad callback only for lazy loading module, it's just one time guard, once the module is loaded, the guard will not work.
• Set canActive to protect the route, like /protected , it's the callback guard for the current route.
• Set canActiveChildren only to protect children routes, like /protected/child1 , it should also come with a children array in route config.

You can also find code example from one of our test apps.

[polklabs]

@shuowu That's not the issue.
canLoad is not the behavior that I want and canActivate/canActivateChildren produce the same behavior.

This only happens after the session and okta sessions have expired. Odd behavior is that opening the dev tools window will trigger the page to redirect to login, otherwise it just sits on a blank white page indefinitely waiting for authentication

[shuowu]

@tlahav @polklabs I have identified an issue within the token auto renew process, it currently can cause unhandled promises in memory, and if error is thrown from there, it can break the following authState update.

Here is a PR (okta/okta-auth-js#1033) to fix the issue (in okta-auth-js), can you verify the change to see if it helps with the issue you have?

[tlahav]

Hey, I tested the PR locally and noticed that it worked. Although, I was not ever able to duplicate the issue on demand so I do cant tell for certain that this fixed the problem.

[tlahav]

@shuowu That's not the issue. canLoad is not the behavior that I want and canActivate/canActivateChildren produce the same behavior.

This only happens after the session and okta sessions have expired. Odd behavior is that opening the dev tools window will trigger the page to redirect to login, otherwise it just sits on a blank white page indefinitely waiting for authentication

I wanted to echo this as we've experienced that as well. In fact, I believe it's not the opening of the DevTools but actually the resizing of the View window that triggers the forward to the okta log in page.

[polklabs]

Having some trouble getting the code to test the PR locally. But I believe I've been seeing the exact same issue as tlahav.
I also noticed that is was a window resize that triggers it, but I was unable to trigger the resize programmatically. So my current work around is a button on the page that triggers a complete page refresh.

[pusherman]

This is resolved for me in @okta/okta-auth-js: 5.10.0