Next-auth: Why custom encoder is needed for JWT signing to work as intended?

[MelMacaluso]

Your question
We noticed that with the out of the box JWT signing (I guess you are using JOSE package) we can't decode it from our backend as it provides an invalid signature, we had to manually do the signing etc. as follows:

```js
///[...nextauth].js
jwt: {
encode: async ({ secret, token, maxAge }) => {
const encodedToken = jwt.sign(token, secret, { algorithm: 'HS512' })

return encodedToken

},
decode: async ({ secret, token, maxAge }) => {
const verify = jwt.verify(token, secret)

return verify

},

},

What are you trying to do
We would like to use the out of the box signing to avoid adding to the boilerplate.

[iaincollins]

Yeah we REALLY need to improve the docs for JWT options- and maybe simplify the (undocumented) options that are support.

I have a feeling API options we support are a bit more complicated than they needs to be, which is why it's not been documented yet, but at this point us just documenting what they are and how they work is probably a good idea.

The custom encode/decode functions were basically a lazy escape hatch to allow people to do any old thing they want in case they ran into issues like this.

[MelMacaluso]

Ah amazing thanks, maybe keep them so we can still do this (as didn't find any other way ahaha), hint: maybe there's an issue in using the secrets when it comes to jwt...

[stale[bot]]

Hi there! It looks like this issue hasn't had any activity for a while. It will be closed if no further activity occurs. If you think your issue is still relevant, feel free to comment on it to keep it open. (Read more at #912) Thanks!