mars-wtf
Please help me with Next authentication issue #4
-
|
I'm wondering how I can use NEXT_AUTH, for example, if the end user logs into the frontend app using Google provider, how can I use NEXT_AUTH on the frontend to call the API on app (2) and use the same credentials. I guess in this case I should persist the user and share the same mongoDB database for the user, but I have a feeling it won't be that simple. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
The solution i have found is to sign the JWT with an asymmetric key and then share the PUBLIC KEY with the other APIS this way I can verify the information was signed by my server ( jwt issuer which holds the private key ). There is a need to override the encode / decode methods for JWT on next-auth in order to use RS256 instead of the default algorithm. From that point I would be able to send the encrypted JWT token to another HTTP API ( via HTTP HEADER ) and verify it on the HTTP API which will only need to know the PUBLIC KEY in order to verify the signature ( the private key never leaves my jwt issuing environment ) thus being able to verify the signature even if offline ( i.e. no extra http requests are needed ). Some related read can be done here: https://github.com/auth0/node-jsonwebtoken Please let me know your thoughts, i'm wondering which other alternative implementations could be used here and if the implementation i'm suggesting has any flaws. You can check this another github discussion here |
Beta Was this translation helpful? Give feedback.
-
|
Look good, thanks |
Beta Was this translation helpful? Give feedback.
The solution i have found is to sign the JWT with an asymmetric key and then share the PUBLIC KEY with the other APIS this way I can verify the information was signed by my server ( jwt issuer which holds the private key ).
There is a need to override the encode / decode methods for JWT on next-auth in order to use RS256 instead of the default algorithm.
From that point I would be able to send the encrypted JWT token to another HTTP API ( via HTTP HEADER ) and verify it on the HTTP API which will only need to know the PUBLIC KEY in order to verify the signature ( the private key never leaves my jwt issuing environment ) thus being able to verify the signature even if offline ( i.e. no ext…