I’m working on an authentication system for my app using Phoenix LiveView and considering implementing token-based authentication (e.g., with Phoenix.Token or JWT). I’d love to hear how others approach this, especially when it comes to safely handling reconnections after the WebSocket connection drops.
Here’s the workflow I’ve been ideating:
A user submits their email and password for authentication.
If the system successfully authenticates the user, it generates a token (using Phoenix.Token, JWT, or something similar).
The system attaches the token to the LiveView socket (or session—still deciding).
If the user’s WebSocket connection drops (e.g., due to network issues), the browser attempts to reconnect.
Here’s where I’m stuck:
How can I ensure the connection safely reuses the already-generated token during the LiveView reconnection process?
Should I rely on the LiveView session or some other mechanism to persist and validate the token securely for subsequent reconnect attempts?
Are there any gotchas I should watch out for when integrating token-based authentication into a LiveView app?
Any advice, insights, or examples from your own implementations would be greatly appreciated!
Each time a new re-connection happens it still begins with a http upgrade connection request/response, so all security considerations that go for http requests like CSRF are valid concerns here too.
IMO a generic phoenix project provides great defaults for security, add to that all security hardening that goes for https and you are good to go with the default setup.
You should probably use mix phx.gen.auth even on a side project just to follow the code if you want to implement it from scratch. They’re using Phoenix.Token and save it in the session.
There should be nothing you have to do for session re-connects.
Also: you can use Phoenix.Token or JWT but you do not have to.
What phx.gen.auth is doing is actually different - they do not use either. They just generate a simple random token value using :crypto.strong_rand_bytes and then insert that token along with user_id to a database table.
After that’s done, the value of the token is set in the session.
Session is signed, so in theory they could have put user_id there, but their approach is smarter as they store the token in the session, but the mapping to user_id on server, which allows them to invalidate the session wherever they want by just deleting the token on the server.
This is the approach I have adopted across my apps, not just LiveView, and this has saved me a lot of trouble.
Phoenix.Token or JWT could be used instead of Phoenix sessions. You usually use them with APIs. They’re not suitable for session/cookie based authentication because of their size, which can be big and your session storage is probably in cookie, meaning that it has a hard limit that is not too big at all.
So that’s my gotcha at the end. I do advise you use mix phx.gen.auth and spend an hour or so with generated code, it will be very educational!
