DEV Community

Cover image for Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

Tokens Can Be Copied. Sockets Cannot. This Changes Everything.

Thuangf45 on March 17, 2026

Most web developers today live in a world of abstractions. The Network is a black box that delivers JSON. The OS is a mysterious entity that runs t...
Collapse
 
felipegxavier profile image
Felipe Xavier

This only works for long live connections, right? e.g. Websockets, gRPC streaming, custom sockets.

HTTP is stateless even when the KeepAlive header is sent (not 100% reliable)

So every request will change the file descriptor id

Collapse
 
thuangf45 profile image
Thuangf45 • Edited

You're correct — this is designed for long-lived connections (WebSockets, custom sockets).

For web browsers: a browser already opens ~6 connections per tab for HTTP. Why not dedicate one as a permanent WebSocket for authenticated communication? HTTP handles stateless resource fetching; WebSocket handles identity-bound sessions. KeepAlive was never a security primitive anyway — just a performance optimization. The architectural split is actually cleaner this way.

For native apps: it's even simpler. The OS already provides secure storage (Keychain on iOS, Keystore on Android, DPAPI on Windows). The app retrieves the secret key once, sends it on the first connection, and SessionService binds that physical socket. If the connection drops, the app silently re-sends the key — one round trip, no token juggling on every request.

The core idea is the same in both cases: authenticate once per physical connection, not once per request.

Collapse
 
thuangf45 profile image
Thuangf45

If you want to explore the full implementation, everything is on NuGet and GitHub.

NuGet: nuget.org/packages/LuciferCore
GitHub: github.com/thuangf45/LuciferCore

Collapse
 
nicholasthegreat profile image
Nicholas

"I watched a child — with zero IT knowledge — use AI to build a working web tool."
That must be very difficult for you, a developer with 10 years of experience who definitely does not use AI, I'm so sorry.

Collapse
 
thuangf45 profile image
Thuangf45

Actually that's exactly why I wrote this.

If a child with AI can break Netflix in an afternoon,
imagine what someone with 10 years of experience and AI can build.

The tools changed. The question is whether your mental models did.

Collapse
 
thuangf45 profile image
Thuangf45

Some will say "just use short-lived JWTs."

That's better than nothing — but "better than nothing"
and "secure by design" are two very different things.

Collapse
 
thuangf45 profile image
Thuangf45

Worth noting: when the physical connection drops, the identity binding
disappears automatically. No logout logic needed. The OS cleans it up for you.

That's the part I love most about this model.

Collapse
 
buffermodeler profile image
BufferModeler

"A child with no IT knowledge cracked Netflix"
and you just casually dropped that in the intro 💀

Great read though, the physical binding concept makes a lot of sense.

Collapse
 
thuangf45 profile image
Thuangf45

Haha yeah I figured if I buried it in section 3
nobody would read it — so I just opened with it 😄

Glad the physical binding concept made sense,
that's the part that actually matters.

Collapse
 
johndoedev profile image
Johndoe

The Netflix story hit different. Never thought about session security
this way before. The socket binding idea is genuinely clever.

Collapse
 
thuangf45 profile image
Thuangf45

Glad it landed that way! The socket binding idea
took me a while to internalize too — once it clicks,
you can't unsee it in every auth system you look at.