'expiresIn' in iOS has an incorrect value

[jess-hwang]

Checklist

• The issue can be reproduced in the react-native-auth0 sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

"authorize" returns "expiresIn" in Unix timestamp format, but in iOS, when using "saveCredentials," the value is mistakenly assigned using "timeIntervalSinceNow," leading to incorrect values for "expiresIn."
I think it should be "timeIntervalSince1970."
"expiresIn" contains strange dates like "2077-03-03 22:24:35 +0000."

Reproduction

I tested it in version 3.0.0-beta.3.

Additional context

No response

react-native-auth0 version

3.0.0-beta.3

React Native version

0.68.2

Expo version

No response

Platform

iOS

Platform version(s)

16.4

[brushton-ces]

I'm seeing something similar.

After a normal authorise, I was seeing getCredentials return
"expiresIn": 3381989740,
but the accessToken returned was decoding to "exp": 1691038070,

And then after calling getCredentials with force refresh I got
"expiresIn": 1691195705,
and the accessToken returned was decoding to "exp": 1691195705,
Which seems to properly match.

So it seems the expiresIn value from the initial login was not correct? The authorise method uses the saveCredentials method -

react-native-auth0/src/hooks/auth0-provider.js

Line 83 in 71a5e92

await client.credentialsManager.saveCredentials(credentials);

This error leads to hasValidCredentials returning true when the accessToken returned has expired...

[poovamraj]

@Widcket Can you check this one out?

[Widcket]

Hi @jess-hwang, thanks for raising this.

I just reproduced this issue. Indeed, the expiresIn value returned to the JS layer after login is a Unix timestamp, but it's being added to the current time inside saveCredentials():

The solution would be to use the Date(timeIntervalSince1970:) initializer instead.

[poovamraj]

Hi @jess-hwang and @brushton-ces thanks for raising this. We have fixed this in the PR here - #686.

Please test it and let us know. We will close this issue and the conversation can be continued there.