1.3 KiB
ADR-0002: Session-Token Authentication on the Signaling Server
Status
Accepted
Context
The signaling server trusted client-supplied user IDs on REST mutations and WebSocket identify, allowing impersonation for kicks, bans, joins, plugin administration, and push dispatch. The product client already used bearer tokens for the Electron Local API, but the shared signaling server had no equivalent binding between HTTP/WebSocket actions and a logged-in user.
Decision
Issue opaque session tokens on login/register, persist them in server SQLite, require Authorization: Bearer on all mutating REST routes, and require identify.token on WebSocket connections before any other client message is accepted. Actor fields (currentOwnerId, actorUserId, requesterUserId) are derived from the token instead of request bodies.
Rationale
This closes identity spoofing without changing the P2P product model: discovery stays public, chat/media still relay over WebSocket, and DM WebRTC signaling remains available across servers. Bcrypt password hashing with transparent SHA-256 upgrade preserves existing accounts. A deprecation window for body-only auth was intentionally omitted so all clients must authenticate in one release, avoiding prolonged dual-trust behavior.