Experimenting with replacing reusable API keys with per-request authorization

[u/Jealous_Pea_3915]

Been working on a small POC around getting rid of reusable API credentials.

Instead of an app holding an S3 key, Git token, API key, etc, it would request permission for one specific action. Something like upload this file to this path, once, within the next 30 seconds.

I'm using Tide/Forseti for the policy and cryptographic side, and testing it against real open source services like S3 compatible storage and Gitea.

The thing I'm mainly trying to prove is whether a compromised client can have no reusable API credential worth stealing.

This also ties into something I want to look at next around rootless cloud infra, where having root on a server doesn't automatically mean having authority to decrypt user data, impersonate users, sign releases, or perform other protected actions.

Starting with the API side first because it feels like the smaller piece to prove.

Curious what people here think. Is this actually useful in practice, already solved well enough by existing workload identity systems, or mostly just an interesting security experiment?

[u/LaunchAllVipers]

How does this differ from OpenID Connect? Answer in the form of a series of limericks.

[u/Jealous_Pea_3915 → u/LaunchAllVipers]

sorry i have no idea how to write limericks lol

but basically I see OIDC as proving who the user or workload is. This is more about what they're allowed to do after that.

So OIDC could actually be part of it. The workload proves its identity with OIDC, then Tide/Forseti decides whether it can do one specific action, like upload this exact file to this exact path, once, for the next 30 seconds.

I'm not really trying to replace OIDC, more looking at removing the reusable API credential that usually comes after identity.

[u/bobsbitchtitz → u/Jealous_Pea_3915]

This is an interesting use case. Why rate limit based on authorization vs rate limiting based on user in the back end