API Keys will never die. Every time you would think you have killed them, some startup is gonna come and say "look how complicated it's to setup an OAuth flow just to get X from the other companies. Here is our setup" and it's 1 line of javascript or python with `let client = awesomeClient("{api-key}");` and everyone will love it.
I wrote a post[0] a few years ago about how you basically get OAuth when you start layering security principles (rotation, time limits, central verification) onto API keys.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
Man, its been so long since I saw Azure DevOps/TFS interface and all these years later it still doesn't make any sense. Why does the navigation hierarchy go
Workload identity. Whatever is using an API key could instead be given an identity, and narrow privileges assigned to that identity. API keys tend to be overscoped/overprivileged.
And passwords. Shared secrets in general are a bad idea. If you're copy/pasting strings around to be used for authentication, you've done something wrong.
Workload identities and passwordless auth are the one true path.
API Keys will never die. Every time you would think you have killed them, some startup is gonna come and say "look how complicated it's to setup an OAuth flow just to get X from the other companies. Here is our setup" and it's 1 line of javascript or python with `let client = awesomeClient("{api-key}");` and everyone will love it.
Do you have any examples ?
It's the first time I hear about replacing API keys
I wrote a post[0] a few years ago about how you basically get OAuth when you start layering security principles (rotation, time limits, central verification) onto API keys.
Turns out those standards writers knew something!
0: https://fusionauth.io/blog/securing-your-api
OAuth with refresh tokens.
IAM roles/workload identity.
Even time-limited or signed JWT, though has a separate issues.
Maybe you'll say 'those are both just text values passed like an apikey' though api keys don't frequently rotate/time limited, which is an important security feature.
So how would this help in this case? The oauth info would’ve just been in the csv or in someone’s env file.
1 reply →
> OAuth with refresh tokens.
Then the LLM slurps up your refresh token. What's next?
5 replies →
At that point you've just reinvented Kerberos tickets really...
1 reply →
This can be done in Azure using Entra (OAuth). I don't have API keys, or passwords of any kind, anywhere in the stack.
Infrastructure - https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour...
Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Function...
Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
Man, its been so long since I saw Azure DevOps/TFS interface and all these years later it still doesn't make any sense. Why does the navigation hierarchy go
Workload identity. Whatever is using an API key could instead be given an identity, and narrow privileges assigned to that identity. API keys tend to be overscoped/overprivileged.
And passwords. Shared secrets in general are a bad idea. If you're copy/pasting strings around to be used for authentication, you've done something wrong.
Workload identities and passwordless auth are the one true path.