Who holds the client secret?

Mon, 27 Jul 2026 00:00:00 +0000

keryx posts to TikTok and YouTube on your behalf, which meant I had to answer a question every OAuth tutorial skips: who actually holds the client secret? They all assume you’re a server that can keep one, and never say so. You register your app, you get a client ID and a client secret, you keep the secret on your backend, and the whole flow hangs off the fact that one trusted party can hold a secret. That assumption is doing a lot of work, and it falls apart the moment the thing doing the OAuth is a command-line tool that posts to TikTok or YouTube on your behalf.

There’s no server. keryx runs on your machine. So the secret would have to live somewhere on the client side, and the two obvious places are both wrong.

You could bake the client secret into the binary. But keryx is open source, and a secret baked into an open-source binary isn’t a secret at all. Anyone can pull it out of the source or the compiled artifact in about ten seconds. Worse, it’s a shared secret: every install carries the same one, so a single extraction compromises the app for everyone, and rotating it means shipping a new release to the entire userbase. That’s not a credential, it’s a liability with a version number.

Or you could make every user register their own OAuth app at every platform they want to post to. No shipped secret, which is the right instinct, but now the setup story is “before you can use this tool, go and create developer apps on four different social networks.” For a lot of people that’s where the tool gets closed and forgotten.

The way out is to name what keryx actually is: a tool with no safe way to keep a client secret in the first place. OAuth already has a name for it: a public client. It’s the category for native and CLI apps that demonstrably can’t keep a client secret confidential, and the whole flow is designed around that admission. No client secret is shipped at all. The thing that actually matters, the durable credential, is the per-user refresh token you get after authorising, and that’s yours, tied to your account, living on your machine. keryx stores it the careful way, preferring an environment variable, then the OS keychain, then config, which is a whole topic in its own right. Nothing secret ever goes in the binary, because there’s nothing secret to put there.

That leaves the client ID, which isn’t a secret (it’s fine for it to be public), and the question of where it comes from. For now keryx is bring-your-own-app: you register an app on the platform, you get your client ID, keryx uses it with the public-client flow. It’s a bit of one-time setup, but it’s setup that leaks nothing, because there’s no shared secret anywhere in the system to leak.

And this is the trade-off I’m sitting in, openly, rather than pretending there’s a free option. The convenient version is a hosted broker: keryx runs a single registered app, you authorise against that, and you never register anything. Zero setup. It’s genuinely nicer for the user. But it means I’m now running a piece of trusted infrastructure that holds the app registration for everyone, that has to stay up, that becomes a target, and that turns a local-first tool into one with a dependency on a service I operate. That’s a real commitment, not a weekend’s work, so the broker is deferred rather than dismissed. Bring-your-own-app is the right default until I can stand a broker up properly.

If you’re ever distributing an OAuth client that isn’t a web app, the temptation is to recreate the server-side flow you know, secret and all, somewhere that can’t keep a secret. The better move is to stop pretending there’s a secret to keep: name it a public client, lean on the per-user token, and most of the problem just evaporates. You were never going to keep that secret anyway.

Auth on PHP Boy Scout

Who holds the client secret?