Moving to cookie based sessions?
I'm not a fan of the JWT with localstorage managing the authorization system. Does anyone with some deeper understanding of the auth systems want to give me some jumping off points for implementing the cookie based session system? I see it uses Lucia. End goal would be a PR of a system of choosing between JWT+localstorage or standard cookie sessions.
8 Replies
Hi @space black. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the knowledge sources provided, I can offer some insights on Wasp's authentication system and the potential for moving to cookie-based sessions:
1. Current System: Wasp currently uses sessions stored in
localStorage on the client and in the database on the server. It utilizes Lucia Auth v3 for session management, as mentioned in the Auth Overview documentation.
2. Past Considerations: There has been an ongoing discussion about switching from JWT and localStorage to session-based authentication with cookies. This is documented in a GitHub issue titled "Should we use sessions instead of JWT in Wasp for authentication? What about cookies vs local storage?" GitHub Issue #573.
3. Challenges: The team attempted to swap JWTs and localStorage for Sessions and cookies in a pull request (#635) but encountered difficulties, particularly with CSRF protection and cross-domain usage.
4. Future Plans: There's been discussion about potentially having a Wasp deployment setup that will use a single domain (e.g., the server will serve the client), which would make the use of cookies more feasible for Wasp apps. In this scenario, they would invest in CSRF protection.
5. Lucia Integration: Wasp already uses Lucia for session management, so further leveraging Lucia's capabilities could be a good starting point for implementing cookie-based sessions.
6. Arctic Library: For OAuth providers, Wasp is considering using the Arctic library, which is part of the Lucia ecosystem. This shows a commitment to the Lucia ecosystem, which could be leveraged for cookie-based sessions as well. GitHub Issue #1869
To implement a cookie-based session system or provide an option to choose between JWT+localStorage and cookie sessions, you might want to:
1. Review the Lucia Auth v3 documentation for cookie-based session implementations.
2. Look into CSRF protection mechanisms compatible with Lucia and Wasp's architecture.
3. Consider the cross-domain implications and how to handle them in Wasp's context.
4. Explore how to integrate this as an optional feature in Wasp, allowing users to choose between the current system and a cookie-based approach.
Given the ongoing discussions and previous attempts, it would be beneficial to engage with the Wasp team directly on this topic, perhaps by commenting on the existing GitHub issue or opening a new one to discuss your specific implementation ideas.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @space black, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai I reviewed that issue, and it seems like the issues brought up are definitely amenable. HTTPS can be enabled on local dev, or you can turn off the third party cookie for your local dev work. Easy enough.
So imagine a setup like this:
- Server issues a single HttpOnly, Secure, SameSite=Lax cookie
- Session ID stored in database with expiration
- Client can't directly delete the cookie (not reachable by JS)
Online logout - client clicks logout, server deletes db session and clears cookie via Set-Cookie header
Offline logout - server deletes db session or it expires. When client comes back, they won't have access.
To me, seems like all the concerns are addressed, and security is improved with no downside.
Of course, the JWT system could still be in the application and chosen if for whatever reason you have some specialized setup.
Let me check the knowledge base for you again. One moment! :books:
Wohooo @space black, you just became a Waspeteer level 1!
----------------------
Your proposed setup for a cookie-based session system in Wasp addresses many of the concerns raised in the GitHub issue discussion. Let's analyze your proposal based on the information from our knowledge sources:
1. Single HttpOnly, Secure, SameSite=Lax cookie:
This approach aligns with security best practices. The HttpOnly flag prevents JavaScript access, reducing XSS risks. The Secure flag ensures HTTPS usage, and SameSite=Lax provides a good balance between security and functionality.
2. Session ID stored in database:
Wasp already implements this. According to the Auth Entities documentation, there's a
Session entity that stores session information, including an expiration time.
3. Online and Offline logout handling:
Your proposed logout mechanisms seem sound and address the concerns raised in the GitHub issue discussion. The online logout process you described is similar to what Wasp currently does with its logout action, as mentioned in the Logout action documentation.
4. Security improvements:
Your approach indeed addresses many of the security concerns discussed in the GitHub issue, particularly around CSRF protection and the limitations of JWT.
5. Compatibility with current system:
Keeping the JWT system as an option for specialized setups is a good idea, as it maintains flexibility for users with specific requirements.
Your proposal seems to address the main concerns raised in the GitHub issue discussion while improving security. It's worth noting that the Wasp team has been considering similar changes. As mentioned in one of the comments:
"We could decide as a first step to just put the user id into a cookie (similar to our use of jwts). This will help with security (being cookie based) as well as not require a database."
GitHub Issue #573
Your proposal goes a step further by suggesting the use of a database-backed session, which aligns with another comment in the same issue:
"I would even go for db solution immediately then, and we can just require you to have db in that case."
Given that your proposal aligns well with the ongoing discussions and addresses key concerns, it could be a valuable contribution to Wasp. You might consider creating a detailed proposal or even a proof-of-concept implementation as a pull request. This could help move the discussion forward and potentially lead to the implementation of a more secure, cookie-based session system in Wasp.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @space black, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?hey @space black these are some good observations. did you have time to check out the related github issue? @martinsos might be able to tell you more about the progress here currently.
@Vinny (@Wasp) a little late to the punch my friend https://github.com/wasp-lang/wasp/pull/2480
GitHub
session cookie auth with JWT backward compatibility by sktripamer ·...
Description
Session cookie auth option with full JWT backwards compatibility by default. Addresses concerns from #573
CSRF protection and httpOnly cookie
Full compatibility with websocket
JWTs wil...
haha ok sorry about that.
Thanks for the contribution