User / guest auth

[tj-schultz]

Overview

We need to be able to authenticate user / guest interactions with the app via REST.

Some Options:

JWT

• User logs in -> server returns a signed JWT
• Client stores it
• Every REST request includes the JWT

Also,

• This could be shared in the sharable guest link.

Server‑side sessions

• Session table
• User logs in -> server creates a session entry in DB
• Server returns a generated session ID
• Client sends it with every request to indicate logon

Open Questions:

• Which of these options best supports both signed-in authentication and ephemeral game sessions?
• Do we need a combination of the two?

[dstettler]

JWT seems like it could fit both, although I'm unsure how many payload fields we would really need for auth purposes. An httpOnly cookie sent by the server would be pretty much invisible from a client perspective (in terms of ease of implementation), and is pretty secure with the proper CORS setup (preventing XSS, etc.).

On creating an ephemeral session, the user could be given a newly-minted JWT, maybe with a placeholder UID that could also be easily converted to a user token upon registration, since they'll already have these saved after starting the game anyway. From there each browser session could be given a new token (or the same, doesn't matter for the client), and the server could just associate all user tokens to authenticate their actions.

If a session is purely ephemeral, we can just purge the tokens for each side once the game is completed, or after a certain time passes. It might be beneficial for the backend to store a placeholder UID for these (can JWT strings be unique keys?), but from a frontend perspective it doesn't really matter; as long we get some token when starting a game, we can send it back without issue.

WRT shareable links- each player would need their own tokens, no? Probably better to have an independent game-id/active-game-session or something, and link to the UID, which would then be linked to the tokens (especially if we want to allow users to pick up a game on a different device/browser).

[sreeramgvp11]

I think JWT with httpOnly cookies sounds like a good approach for what we’re trying to do, especially since we need to support both logged-in users and guest sessions.

From the frontend side, httpOnly cookies are nice because we don’t really have to manage tokens manually — the browser just sends them with requests, which keeps things simple and also a bit more secure.

For guest sessions, giving them a temporary JWT with some kind of placeholder UID makes sense to me. That way the flow is the same whether someone is logged in or just playing as a guest, and if they decide to sign up later, we can just link that session to their account.

For shareable links, I feel like it’s cleaner if we don’t rely on tokens in the URL. Maybe we can just use a gameId in the link, and then the backend maps that to the actual game/session. Each player would still have their own token for auth.

So overall I’m thinking:

• JWT stored in httpOnly cookies for both users and guests
• Backend handles mapping tokens to users/guests and game sessions
• Use a gameId for sharing games instead of exposing tokens

This keeps things pretty straightforward on the frontend while still giving flexibility on the backend.