[alexk]

You can't leak API keys if there are no API keys to leak! The article recommends OIDC for apps, which is a step up, especially if you rotate the bearer token, however there is another option - use short-lived certs.

Our project Machine ID is replacing API keys with short-lived certificates:

https://goteleport.com/docs/machine-id/introduction/

Another great option is SPIFFEE https://spiffe.io/

The adoption is slower than we wanted, because it's not trivial to replace API keys, but we see more and more companies using mTLS + short lived certs as alternative to shared secrets.

[danappelxx]

How does this approach practically differ from using short-lived JWTs+TLS?

[alexk]

Short version is that with mTLS and short-lived certificates you don't have to worry about anyone stealing and re-using your JWT tokens and revoking tokens.

LVH from Latacora explains it way better than I could in "A child's garden of inter-service authentication" [1]

However, here is my view:

If your token is not bound to the connection, someone can steal and reuse it, just like any other token. It is possible to use OAuth token binding [2], but at this level of complexity, mTLS + short lived certs deliver the same security and are easier to deploy.

It's easy to mess up JWT signatures, although, to be fair, it's not like X.509 certificates format is any better, however it's been more tested over years of use.

[1] https://latacora.micro.blog/2018/06/12/a-childs-garden.html [2] https://connect2id.com/learn/token-binding

[danappelxx]

Interesting. You already don’t have to worry about revoking JWTs if they’re sufficiently short lived. This gives you the exact level of protection as a short-lived mTLS cert, because if that gets stolen the attacker can continue to establish connections until it expires, unless as you say you revoke the certificate. So clearly I am missing something.

[alexk]

They key difference is with mTLS approach you'd have to steal the private key of the client certificate if you want to impersonate the client. In most secure deployments of mTLS and short lived certs, private key never escapes the TPM, Secure enclave or Yubikey, so it's extremely hard to mount an attack and impersonate a service.

With JWT (assuming it's not bound) you can steal JWT token and re-use it until it expires.

[still_grokking]

I still don't get the difference.

If someone steals your secrets you're screwed. No matter what kind of secrets that are. That's clear.

But if you keep your secrets in a HSM (TPM, SmartCard, …) and only use them to derive session keys directly on the secure device there is absolutely no difference which concrete tech you're using (given that secure cryptography is in place).

mTLS is a great approach, no question. But I just don't see how it's more secure than any other public key crypto.

[vladvasiliu]

If I'm not mistaken, the difference is that in the case of JWT, your app manipulates the secret directly, so it must show up in clear form somewhere, from the app's perspective.

So, if the app host is compromised, the attacker shouldn't have too hard a time to extract the JWT and use it from somewhere else.

In contrast, with an HSM, the attacker would need to have the HSM sign any new connection attempt, which should be a bit more involved if it happens on a different machine.

[xyzzy123]

mTLS tends to add infrastructure complexity, I much prefer it when you can "terminate" auth where you like in the ingress path for user-facing stuff rather than first-hop auth.

I wish there were "real" standards and a better ecosystem for request signing.

[danappelxx]

Right! Which is why we use (public) short-lived JWTs and (private) long-lived refresh tokens. What’s missing?

[maidul]

Frankly, I think it will take years to replace API-keys (if it will ever happen). Developers are much better-off using CLI tools that prevent leaking secrets by blocking commits to git (e.g., https://github.com/Infisical/infisical or https://github.com/trufflesecurity/trufflehog)

[alexk]

I don't think those are mutually exclusive options :) Most developers, especially with lots of legacy apps are better off using a secrets manager. But there is no reason to not push the boundaries of security for new software and onboard passwordless and secretless options.

P.S.

I tried Infisical a couple of months ago. I think if I was Hashicorp Vault team's PM, I'd be worried. Your team has done such a great job at U.X. I was astonished to see an early startup with such a great integration catalog. I think you aced it - modern developers are desperate for out of the box integrations with 100+ services they have to use every day.

[vmatsiiako]

Wow! Thanks you Alex. This feedback means a lot coming from you! We're huge fans of Teleport, and learned a lot from you as a fellow YC company :)

[alexk]

No problem! Keep it up with out of the box integrations, focus on U.X. and developer experience and I think you will be on track to become as big or bigger than Hashicorp :)

[rcme]

How do you generate the short-lived certs?