2

I'm using oidc-client-js in my client for one of my SPA projects. I have an identity server which is written in IdentityServer4.

If I change date-time of server manually, the oidc-client-js can't validate response of server in log in user, because the date times are not the same.

And also if I change date-time of client manually and keep server with auto date time option, again the response from server is not valid.

I think any JavaScript solution for working with date-time, is not reliable and all date-times must be validated in server.

How can I validate token in server not in client?

Is my assumption is correct ? And if its not correct, is there any solution for oidc-client-js to use server time instead of browser time?

This is my client configuration 

const userManagerConfig = {
  client_id: '58bdb6b3dd264200a1186573a8abf884',
  redirect_uri: `${window.location.protocol}//${window.location.hostname}${window.location.port ? `:${window.location.port}` : ''}/authentication/callback`,
  response_type: 'code',
  post_logout_redirect_uri: `${window.location.protocol}//${window.location.hostname}${window.location.port ? `:${window.location.port}` : ''}`,
  scope: 'openid profile phone tes.api',
  authority: `http://localhost:5016`,
  silent_redirect_uri: `${window.location.protocol}//${window.location.hostname}${window.location.port ? `:${window.location.port}` : ''}/authentication/silent_callback`,
  automaticSilentRenew: true,
  filterProtocolClaims: true,
  loadUserInfo: true,
  triggerAuthFlow : true
};
jsDevia
  • 1,282
  • 4
  • 14
  • 37

1 Answers1

0

The time has to be correct. On Server or on Client, it does not matter, but it has to be the actual time. If you temper with the time, the claims on the token (iat, nbf, etc.) may represent a moment on the past or the future so it won't work.

Why would you change the date/time of the server or the client to an invalid one?

How can I validate token in server not in client?

On SPAs everything oidc-related happens in the client code, validation of the token included.

This is not the only, nor the most important, validation that the client does on the token, the main validation is checking that is signed with the pair of the public key exposed by the authority.

I think any JavaScript solution for working with date-time, is not reliable and all date-times must be validated in server.

Why trusting the clock on the server more than the clock on the client machine, what about desktop applications, what about offline...

Pablo Recalde
  • 3,334
  • 1
  • 22
  • 47
  • The problem is, that if one of the users of your site doesn't sync their clocks it can drift. Your everyday user don't care if there are good technical reasons for keeping your clock in sync. They don't care and they probably don't know why it's not syncing – mathiasbn Nov 02 '20 at 15:07
  • Right, so what's your proposed solution to this problem? – Pablo Recalde Nov 10 '20 at 17:14
  • Also they will care when every service that uses oauth2.0 or anything implemented on top stops working. – Pablo Recalde Nov 10 '20 at 17:15
  • Yeah, of cause you're right. Or rather, manufacturers will remove or make it very difficult to alter the clock. In the meantime, my product is not big enough to ignore user complaints even though it's there own fault – mathiasbn Nov 10 '20 at 19:38