Saving session token locally in NextJS Site

Client SDKs JavaScript SDK
1

Hi All! Thank you in advance for any help you can share.

I’m in the process of building a new site in NextJS (13.5.6) that will tie-in to our existing Parse App hosted on heroku. I have a couple of questions, since I’m new to this particular development context, so I need to be sure I know whether or not my intentions are secure or not.

I have set up working examples of signing in to existing accounts from both a client component and a server component. My preference is to use only server components for the Parse interaction, but I’ve run into an issue with authentication/session tokens. Running on the client side, things are pretty simple, as it’s very easy to get the current user, and that user stays signed in according to their session token info. When running in a server component, it becomes more complicated since there’s no longer a current user stored in the system (the js is now running in the node server, so no current user available). Because of this, users would need to authenticate every time they wanted to view account information on our site, which I don’t want to happen.

My question is whether or not saving the user’s session token locally is secure. From what I understand, after a user signs in, I can send the session token to the client where it can be saved to local storage. After that, I simply get the session token later when the user visits the site. If it’s still valid, I can fetch user data. If it’s not, just request that they sign in again.

Since the Parse SDK when running locally in the browser (NextJS Client Component) is saving some type of session data (I’m assuming the session token itself) in “localStorage,” I’m guessing this is all secure. However, in my research, I’m seeing that saving data of this nature in localStorage is not secure.

If it is secure, can I get a quick summary as to why it’s secure? To my understanding, if someone were to get hold of our Parse server url, our Parse App ID and a user’s session token, they would be able to do pretty much anything they wanted to that user’s account. The user data we store in our system is encrypted, but the account could still be damaged beyond repair.

If it’s not secure, why is it secure using the Parse JS SDK locally in a web browser?

Lastly, what are my options for handling all Parse interactions, including authentication, on the server side in React Server Components?

2

Hi,
Storing a user’s session token in local storage is a common practice, but it should be done securely. It’s important to avoid exposing the token in your source code and consider using HTTP-only cookies for added security.

In terms of other services like Google Firebase, they also use similar mechanisms for token storage, often utilizing secure methods such as HTTP-only cookies to protect sensitive data. The key is to follow best practices and security guidelines to ensure the safety of session tokens and user authentication data.

Exactly, obtaining a token stored in local storage even with these precautions in place, is akin to unauthorized use of a laptop with an active user account. Security in this context relies on the responsibility of the user.

3

Thank you very much for the quick reply @rgunindi. Your explanation pointed me to closer to where I needed to be looking in my research, so I believe I’m getting a much better understanding of what is needed here. This website security stuff is very tricky and is taking a lot of time to understand, so getting help in a forum like this is much appreciated.

If you have the time, maybe I can get your feedback on what I’m planning now. Since I’m sending the user’s session token back to the client, I’m going to encrypt it before sending it. From what I’ve researched after your response, I could try to find a JWE setup, and send it that way. However, I’ve gotten familiar with normal JWT logic, so I’m planning to use Node Crypto to encrypt the session token first, place that in a signed JWT, then send it back in an HTTP Only cookie. When receiving a request on the server, I’ll simply check the JWT first to make sure it’s authentic, decrypt the session token, then use the token to get the Parse User.

Does anything look obviously wrong in that implementation?

4

Indeed, If you’ll use JWT and the JWT validation process is successful, you can proceed with the request using the “sessionToken” included in the JWT. This way, you won’t need to re-encrypt the “sessionToken” separately. If the JWT is not valid or doesn’t pass the authentication checks, you can reject the request. This simplifies the authentication and session management process while maintaining security.

5

Just a quick follow-up on this topic for those who might be running into similar questions. After implementing my own JWT solution with http-only cookies, I went back and looked into the Next-Auth plugin for NextJS. When I first checked the plugin, I didn’t understand how it worked and how to use it. After going through the process of creating my own solution, Next-Auth started to make sense. It’s an incredibly robust authentication system, and very flexible. It creates encrypted JWTs by default, and handles CSRF Tokens as well. In the end, if you’re using Parse with NextJS, I highly recommend going through the process of learning it. It will save a ton of time in the end and provide all the security you’ll need for your site.

6

Im looking into this at the moment I dont suppose you have any pointers ? new to nextjs