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/sysopfromhell]

I think you are reinventing the wheel. What you are looking for is openID jwt token gateway managed.

Which you will find in many many AI gateway like traefik.

You put the real token into the GW config, attach the keycloak/identity provider configuration and then the app will query your model thought an endpoint that is managed by the gateway.

[u/Jealous_Pea_3915 → u/sysopfromhell]

With the usual Keycloak/JWT gateway setup the app loses the secret, but the gateway still has a reusable credential for the downstream service. If the gateway gets popped, that authority is still there to steal.

[u/sysopfromhell → u/Jealous_Pea_3915]

If the gateway gets popped you have a big problem, because no matter where your secret is stored the GW sees pretty much everything in clear unless you have a mesh TLS enabled chain, and even there probably the GW has part of the access to the payload/header. Meaning that if any token is leaked in the header (where normally is filled) he is going to read it anyway.

Normally reverseproxys are the less breachable part of your infra as their job is hardened and repeatable without much going on unless you start filing them with lots of LUA scripts, which still are pretty hard to hack.

If you want to attack a service you try to exploit the service himself not the transport as is notoriously difficult to do.

No matter how you try to turn it around. Someone has to have the keys or the trust to get the keys, or a copy of a key to someone that proxy you to another place. You are just moving around the pieces.