oidc-client-ts

oidc-client-ts copied to clipboard

Trying to use this library in an application to authenticate via our corporate SSO. Login is fine, and in my development environment (Firefox) the silent-refresh works fine. But when we deploy this, almost all users (majority Chrome users, in case it matters) have issues where the silent-refresh will fail, then start a feedback loop where it retries anywhere from 120 to 25 seconds in interval. We have had to disable the silent-refresh entirely and force-reload the app's tab before the access token expires. The error messages seen generally refer to problems with the iframe.

Has anyone else seen this, or something like it? The configuration of the UserManager is:

{
  authority: PROVIDER_BASE,
  client_id: CLIENT_ID,
  redirect_uri: REDIRECT_URI,
  response_type: "code",
  scope: "openid",
  automaticSilentRenew: false,
}

The only thing changed was the automaticSilentRenew setting (previously true).

I have tried doing the refresh manually (with my own injected iframe), but that fails when the library sees the incoming request lacking a value in the state parameter.

in cases where the state is not found, this might be a problem with the router aka fragment vs query. Enabling logging within this library should give you some insights. I use this pattern to speedup the automatic token refresh in the configuration: accessTokenExpiringNotificationTimeInSeconds: ACCESS_TOKEN_EXPIRE_TIME - 30,

in cases where the state is not found, this might be a problem with the router aka fragment vs query.

Sorry, might not have been clear: I was trying to do a manual token refresh by constructing my own iframe, etc., but because it didn't have the session ID in the state parameter it would fail. I don't (to my knowledge) have a way to determine the session ID that oidc-client-ts is using for that tab, unless I can get it from the UserManager instance, somehow?

But the core issue here, is that the silent-refresh is failing and leading to rapid retries against our authentication server. That has led to the team that manages said service requiring us to take immediate action.

We have tracked down the root-cause of this issue: our production and staging servers use nginx to serve the application over SSL. By default, nginx sets the header X-Frame-Options to a value of DENY when serving SSL content. I am working on getting the servers' configurations updated (we have three layers of proxying, so this is an effort).

But this exposed the "real" problem: when this error occurrs, the error message thrown by the component kind of obfuscates the issue; while it is clear that it involves the iframe element, it isn't clear that the X-Frame-Options setting is preventing the SSO response from being rendered/processed. And, worse, the component doesn't see the root cause of this and keeps trying to refresh, over and over again. In our case, this led to some users who had left the app open in a browser tab creating hundreds of login requests in just a few hours.

I would recommend that the component's error-handling being modified to detect this situation upon initial failure and disable the repeated retries. I can re-title this issue to reflect that, or I can close this issue and open a new one. Please let me know which you prefer.

I would recommend that the component's error-handling being modified to detect this situation upon initial failure and disable the repeated retries.

What i prefer is a solution, which is not tight to a specific "custom" setup. The detection to disable the repeated (failed) retries should be made independently of your reverse proxy header issue. Maybe a simple failed counter is enough...

I can re-title this issue to reflect that, or I can close this issue and open a new one. Please let me know which you prefer.

Lets keep using this issue, no need for a new one.