accessTokenExpires is incorrectly assigned as an integer (number of seconds) vs. a timestamp

[btusi]

Describe the bug
I believe I uncovered a bug related to OAuth 2 handling in v3.2.0-canary.41. In #1211 the expires_in value (expressed as number of seconds from the current time, per the OAuth spec) is now passed in to accessTokenExpires rather than simply remaining null. However, account.access_token_expires is declared as a timestamp in the schema. Using the Prisma adapter with PostgreSQL, this leads to an error when logging in. I'm using Auth0 as my provider, but this should be an issue with any OAuth provider.

Steps to reproduce

• Setup Next-Auth backed by a relational database (e.g. PostgreSQL)
• Upgrade to v3.2.0-canary.41
• Attempt to log in with a new account not yet present in the database.

Sorry, no public repo with repro at this time.

Expected behavior
I expect the login to be successful.

Screenshots or error logs

[next-auth][debug][prisma_link_account] 2 auth0 oauth auth0|REMOVED undefined REMOVED 86400
[next-auth][error][oauth_callback_handler_error] 
https://next-auth.js.org/errors#oauth_callback_handler_error PrismaClientValidationError: 
Invalid `prisma.account.create()` invocation:

{
  data: {
    accessToken: 'REMOVED',
    refreshToken: undefined,
    compoundId: 'REMOVED',
    providerAccountId: 'auth0|REMOVED',
    providerId: 'auth0',
    providerType: 'oauth',
    accessTokenExpires: 86400,
                        ~~~~~
    userId: 2
  }
}

Argument accessTokenExpires: Got invalid value 86400 on prisma.createOneAccount. Provided Int, expected DateTime or Null.

Additional context
none

[balazsorban44]

Thanks for reporting!

expressed as number of seconds from the current time, per the OAuth spec)

According what I have found, it should be:

RECOMMENDED. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
If omitted, the authorization server SHOULD provide the
expiration time via other means or document the default value.

https://tools.ietf.org/html/rfc6749#section-5.1

I of course did not intend to crash anything with this change, so I'll set accessTokenExpires back to null, and leave expires_in as is for users who could utilize this value (like for example userland token rotation using refresh_token). I might have had the wrong assumption that actually setting accessTokenExpires is just a nice thing to do for our users as it has been reported a few times being only null.

[github-actions]

🎉 This issue has been resolved in version 3.2.0-canary.42 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀

[balazsorban44]

@btusi by the way, do you think if I set: accessTokenExpires: new Date(Date.now() + raw.expires_in * 1000) it would have been ok?

@williamluke4 what do you think?

[btusi]

Thanks for getting that fixed so quick! I'm not going to have the chance to sit down and try it until later this week but I'll do it as soon as I can.

I think your proposed change will work. I'll give that a shot and see what happens.

[btusi]

I've verified both that the issue preventing logins has been fixed as of v3.2.0-canary.43, and that Postgres accepts accessTokenExpires: new Date(Date.now() + raw.expires_in * 1000).

[github-actions]

🎉 This issue has been resolved in version 3.2.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 3.3.0-canary.1 🎉

The release is available on:

• GitHub release
• npm package (@canary dist-tag)

Your semantic-release bot 📦🚀