4 ms·
> It’s fine for internal tools exposed to trusted users, No, not really? > or you can implement a “bring your own API key” pattern where users supply their ow
by e12e 2y ago
> It’s fine for internal tools exposed to trusted users,
No, not really?
> or you can implement a “bring your own API key” pattern where users supply their own key to use with your client-side app.
This is a valid use-case, even if it breeds unsafe patterns (just allow random site/code on the internet impersonate you and spend money on your behalf).
But it's not really worse than how 3rd party integrations generally do that anyway.
- rvnx 2y agoThey could do a system where you can create one API key with a budget for a site, and that's it, that would be enough, but until they have that budget system, it's not really a good approach
- simonw 2y agoWhy isn’t it OK for internal tools with trusted users? It’s functionally the same as saying “hey coworker, here’s an API key you can use, it’s billed to the company”.
- e12e 2y agoI suppose - my general reaction is that use of such magic api keys are difficult to audit, revoke etc - and there's the constant risk they will leak.