auth and licensing for tool and game developers
Authentication without the opinions.
allowd gives you the parts of an auth and licensing system: license keys, accounts, devices, sessions and entitlements. Your project decides how they fit together.
Access is by application. Our team reviews every brand before it goes live.
The server signs the handshake with your project's key. The sdk checks it before it sends anything else.
One authenticate call. The client sends what it has, and your policy decides what's required.
Allowed, so the encrypted payload comes down, gets checked against its hash, and decrypts in memory. The session runs on a heartbeat.
Same license, second machine. The denial says exactly why, with a code that doesn't change.
Change the policy and replay the request. Same evaluation, no effects applied.
A fake server can't sign the handshake, so the sdk never opens a channel.
What's different
Most licensing services pick a login flow for you, answer every failure with "invalid" and check keys against a server anyone can stand up. allowd is built the other way around.
| topic | the usual | allowd |
|---|---|---|
| login | A few fixed modes. You pick the closest one. | Factors you combine: license key, account, discord and device, each required, optional or off. |
| denials | "Invalid" for everything. | A stable reason code for every denial, like license_expired or device_limit_reached. |
| server | A response anyone can emulate. | A handshake signed with your project's key. An emulator can't produce the signature. |
| payload | A download link. | Ciphertext, delivered only to an authenticated session and decrypted in memory. |
| access | Subscription levels. | Entitlements you name, like core or beta. |
| changes | Edit it live and watch what breaks. | Simulate a request against a policy before you save it. Every version is kept. |
Define access your way.
-
compose the login
License key, account, discord and device are separate factors. Each one is required, optional or off. License only, account only or both, through the same api.
-
one authenticate call
The client sends what it has in one call and the policy decides which factors it needs. There's no endpoint per login mode.
-
entitlements
Access comes from named unlocks like
coreorbeta. Durations grant them. Policies and release channels require them. -
limits that behave
Device and session limits come from the duration or the policy default. At a limit, the policy decides: deny, replace the oldest, or lock the account for a few days.
Know what happened, and why.
-
exact reason codes
Every denial carries a machine-readable code. Codes are public api and stay stable. The policy decides whether clients see the exact code or a generic denial.
-
simulate
Run a request against a policy from the panel. It's the same evaluation production runs, with the effects skipped.
-
events for everything
Every decision and every change is an event, written in the same transaction. The audit log is the same stream.
-
api, panel and sdk
The panel calls the same management api you do. There are no dashboard-only endpoints. Clients use the C++ sdk for Windows x64.
A server you can't fake.
-
signed handshake
Every session starts with an X25519 exchange signed by your project's Ed25519 key. The sdk checks it against the keys in your binary, so an emulated server fails at the first message.
-
encrypted channel
Every request and response after that is encrypted with ChaCha20-Poly1305 and numbered against replay. TLS interception only shows ciphertext. There's no bearer token to lift.
-
encrypted payloads
Your dll or exe is stored encrypted under its own key and delivered only to authenticated sessions. The sdk decrypts it in memory and never writes it to disk.
-
keys per environment
Every project has a development and a production environment, each with its own signing key, secret keys and data. Nothing crosses between them.
No client-side check survives a patched binary. What a patched client can't get is what only exists on the server, which is why your payload stays there until a real session asks for it.