Client specified not to prompt and blank page after session expire

polklabs commented 2 years ago

I'm submitting a:

[x] 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:

login to the web app
close the browser (no logout)
wait for the token and the refresh token to expire
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 commented 2 years ago

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

polklabs commented 2 years ago

@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 commented 2 years ago

Thanks for reporting this, we'll look into it

Internal Ref: OKTA-447151

tlahav commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

polklabs commented 2 years ago

@jaredperreault-okta Any updates on this?

shuowu commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 (https://github.com/okta/okta-auth-js/pull/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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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

okta / okta-angular