Ask HN: How do you enforce least-privilege when an API token has full access?

3 points by ricberw 67 days ago | 2 comments

Curious how people handle least-privilege access when integrating third-party APIs that only offer a single coarse permission scope (or limited scopes that are still over-provisioned for a specific use case).

A lot of services expose APIs where the token basically grants everything the integration can do (read/write/delete across the entire account), making it hard to enforce the principle of least privilege internally when multiple internal services or agents are calling the same API.

In those cases, do you...

Put an API proxy/gateway in front of the third-party API to enforce granular permissions?

Use RBAC/ABAC rules in a proxy layer to filter which endpoints/actions can be called?

Just accept the coarse permissions and risk associated?

Something else?

Would love to hear real architectures people are using in production, especially when the upstream API itself doesn’t support fine-grained scopes.

FabienBSDN 67 days ago |

One pattern worth considering before reaching for a proxy layer: minimize what you actually send to the third-party API in the first place.

If your use case allows it, sending only a derivative of the sensitive data (a hash, a token, a summary) rather than the raw data itself removes an entire class of exposure. The third-party never holds something that can be leaked or misused, regardless of what their token scope allows.

For cases where you genuinely need to send raw data, the API proxy approach with RBAC/ABAC is the most practical solution I've seen work at scale. The proxy becomes your internal trust boundary — internal services get scoped credentials from the proxy, never the upstream full-access token directly.

The "just accept the coarse permissions" path is underrated for low- risk integrations though. The overhead of a proxy layer is real, and sometimes the honest answer is that the data isn't sensitive enough to justify it.

brianwmunz 67 days ago |

A good idea is to build thin proxy layers that map "coarse" upstream tokens to more fine tuned internal permissions. The proxy holds the real API token and your internal services authenticate with scoped tokens that only allow specific endpoints/operations. Works well but you're basically rebuilding OAuth scoping yourself...which is why some teams just accept the risk and focus their security effort on token rotation and monitoring instead.