Hacker News Reader

Comment by fny | Hacker News Reader

Is there any reason why keys don't constantly update? It seems like a service could exist where every five minutes a rotation occurs across services with decaying privileges. For example, the 5 minute old key still works, but the 10 minute woman has completely expired.

View on HN

How would you update the keys every 5 min?

Either you'd use an encryption algorithm that depended on a "deeper" key... or you'd fetch the new key while authenticated with, you guessed it, another "deeper" key.

It's keys all the way down. Every key you use, it's your responsibility to keep it private.

(Unless you want to be dealing with physical hardware dongles that generate keys, but those aren't exactly easily portable.)

Not exactly the same but I had to integrate with a payments API which required one call to an auth endpoint with user/password under HTTP basic auth to get an access token. The actual calls to calculate and execute payments used this access token instead as a bearer token. Those ones expired.

I'm not sure I really see the point, but I guess you could lock down the main call on another system, store the temporary token somewhere, and have the other systems use it.

As you say, you still need the top level credentials somewhere to get a new token.

Yah, that's the OAuth Client Credentials flow but as noted, you still have a static set of creds that are required to generate the short lived access token. Besides being useful for being able to limit scope in some circumstances, the main point of the client cred flow is to appease eager sec arch's who insist on OAuth.

The refresh can be done with the old key, within the time-window. You only need the deeper key for the first time authentication, when starting up or provisioning the service.

What you have to consider is that starting a service is often not just a one time fire-and-forget operations. Applications crash need auto-restart, usually via systemd, kubernetes or something. So the keys-all-the-way down knowledge need to be integrated throughout that whole stack or on the side of it.

Kubernetes ServiceAccounts are based on a very similar flow, they are temporary certificates that are mounted into each Pod, used to connect to the API server and deciding what that Pod is allowed to access.

Reply on news.ycombinator.com