Why MURX?
There are many ways to put authentication in front of a pool of servers. This page is an honest look at where MURX fits, what it borrows from existing designs, and when you should use something else.
What MURX is good at
Out of the data path
MURX redirects instead of proxying. After the handshake the client talks straight to the backend, so the gateway adds no bandwidth cost or latency to the session itself and can stay small.
Any protocol behind it
The backend leg is plain TCP (optionally TLS). An ERP client, a database driver, a game client or a chat client can all sit behind MURX. It is not tied to HTTP.
Routing built in
Backends register and report their load over authenticated UDP, and MURX sends each client to a live, lightly loaded node. Authentication and "where do I connect?" come in one round trip.
No shared state
Tokens are signed for one node and verified by that node alone. There is no ticket cache or session database to keep in sync, just one secret per node.
Small enough to read
Six opcodes, a short spec, byte-exact test vectors, and a reference implementation that uses only the Python standard library.
Compared with what you may already use
| In the data path? | Chooses the backend? | Scope | How it relates to MURX | |
|---|---|---|---|---|
| MURX | No | Yes, from live load | Any TCP protocol | Authenticate once, get a signed ticket and a destination. |
| Kerberos | No | No | Enterprise single sign-on | The closest relative: a ticket issued centrally and checked by the service. Kerberos assumes the client already knows which service to use, and it needs a realm, a KDC and keytabs. MURX adds routing and is much smaller in scope. |
| SOCKS5 | Yes | No, the client names the target | Generic TCP/UDP relay | A proxy that relays every byte. MURX answers the opposite question: it tells the client where to go and then gets out of the way. |
| OAuth 2.0 / OpenID Connect | No | No | HTTP APIs and web login | Also issues tokens that services verify locally, but it is built around HTTP, browsers and delegated authorization. It doesn't say which server a client should connect to. |
| Reverse and access proxies Envoy, NGINX, Teleport, … | Yes | Yes | Mostly HTTP, some L4 | Very capable (inspection, per-request policy, audit), but every byte flows through them. MURX is for when you want the gateway only at the start of a session. |
| Service discovery DNS SRV, Consul, … | No | Yes | Any protocol | Finds a healthy backend but doesn't authenticate anyone. MURX combines discovery with authentication and hands out a ticket. |
When not to use MURX
- You're all-HTTP and already run OIDC behind a load balancer. That stack is mature and well understood, and MURX would add little.
- You need per-request authorization or content inspection. MURX decides once, at the start of a session. Use a proxy that sees the traffic.
- You need battle-tested software today. The reference implementation is alpha. The spec is small and has test vectors, but it hasn't had wide production use yet.
- Your backends can't check a token. Something on the backend side has to verify the signed ticket. MURX can't protect a service that accepts any connection.
In short
If you run a pool of non-HTTP servers and want clients to log in once and be sent to the right one, without putting a proxy in the middle of every session, MURX is built for that. See how it works →