feat(core): allow clearing cookies from jwt()

[iMrDJAi]

☕️ Reasoning

Currently there is no way to invalidate session from the jwt() callback. This change allows clearing the user cookies when jwt() returns a falsy value null.

Also, a new provider option has been added, decodeJWT, which allows passing the existing token of a user (if any) instead of the default one to the jwt() callback after provider's authorize(). This allows creating providers for the purpose of checking and invalidating existing user sessions.

🧢 Checklist

• Documentation
• Tests
• Ready to be merged

🎫 Affected issues

Fixes: #6325

[vercel]

@iMrDJAi is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
auth-docs	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Jan 10, 2023 at 0:13AM (UTC)

[balazsorban44]

Few comments:

• This should be done against https://github.com/nextauthjs/next-auth/tree/main/packages/core as next-auth only receives critical fixes at this point
• Let's allow returning null in jwt which indicates that we should call sessionStore.clean().
• Looks like you did changes to the session callback too, but I don't understand the reason. Could we revert that?

[iMrDJAi]

@balazsorban44 Hello, sorry for the delay, working on the changes that you have requested.

Regarding the session callback, clearing the cookies could be done when fetching the session, not sure what else to return from it when the token is falsy null:

https://github.com/iMrDJAi/next-auth/blob/27dc1b20c0fa6c0d0e3c15f099ef27d8a132159e/packages/next-auth/src/core/routes/session.ts#L63-L68

Does setting the response.body to undefined do the job? Or should we avoid calling it at all in this case? What do you think?

Regarding the new option decodeJWT (or it could be decodeExistingJWT, it certainly needs a clearer name), the point is, if the auth cookies exist while the user is attempting to call a provider, it allows to decode the JWT of that user:

https://github.com/iMrDJAi/next-auth/blob/27dc1b20c0fa6c0d0e3c15f099ef27d8a132159e/packages/next-auth/src/core/routes/callback.ts#L41-L46

Then passing it to jwt() instead of defaultToken:

https://github.com/iMrDJAi/next-auth/blob/27dc1b20c0fa6c0d0e3c15f099ef27d8a132159e/packages/next-auth/src/core/routes/callback.ts#L41-L46

In this way, we could for example make a provider to sign out users, as we have their pervious state.

[balazsorban44]

So basically passing the previous token if I understand correctly. That should be a different PR. Could we split it please and simplify this PR?

[iMrDJAi]

@balazsorban44 Alright! one thing left:

The comment above needs to be extended that explains, returning null will invalidate the JWT session.

Working on it...

[iMrDJAi]

@balazsorban44 Before creating a new PR, what should we call that option?

[balazsorban44]

don't think it should be an option, just give it as prevToken or currentToken in JWT? 🤔 Or maybe it does make sense to override token. Indecisive... Let's discuss pros/cons on the new PR.

BTW this will resolve #3946

[rolanday]

Just curious regarding ...

"This should be done against https://github.com/nextauthjs/next-auth/tree/main/packages/core as next-auth only receives critical fixes at this point"

What exactly does "at this point" mean? Is next-auth end-of-life?

[iMrDJAi]

@rolanday Auth.js will replace NextAuth.js.

@balazsorban44 Actually that's a very good idea, we can pass both pervious and new tokens! I'll play with it a little bit then I'll create a PR.

Edit: Here is the new PR link: #6357.

[balazsorban44]

Thanks!

[balazsorban44]

@rolanday #6132 (comment)