mTLS vs API keys for authenticating mobile apps

Why an API key does not authenticate your app

The API key model is the shared secret model: the client knows a string, sends it with every request, and the server compares it. It works well between servers, where the secret lives in an environment you control.

In a mobile app the binary is in the hands of the user and of anyone who downloads it from the store. Pulling strings out of an APK takes minutes with public tooling, and obfuscation only changes how many minutes. Worse, the key is the same for every install, so extracting it once compromises it for everyone, and rotating it means shipping a new version.

And since the key travels with every request, intercepting the traffic once is enough to have it.

What makes mTLS different

With mTLS the client does not send a secret: it proves possession of a private key by signing, without the key ever travelling. That key is generated on the device and kept in the platform keystore, which it is not designed to leave.

The certificate is also unique per install. Compromising one device compromises that device, not your whole user base, and revoking it affects nobody else.

A practical comparison

• Binary extraction: an API key can be pulled out; a private key in the platform keystore cannot, not in the same way.
• Traffic interception: the key travels with every request; the private key never travels.
• Blast radius of a leak: the key is global; a certificate covers a single device.
• Rotation: the key requires shipping a new version; the certificate rotates on its own, in the background.
• Selective revocation: with a shared key there is no such thing; with certificates it is the natural operation.

What it costs you in return

mTLS is not free in complexity. Somebody has to issue, deliver, renew and revoke one certificate per device, and configure the edge server to require it. That is exactly the work a service like ShieldCert absorbs: the protocol is standard, the logistics are the product.