3 ms·

Yet another argument for the death of the API key. Replacements abound; let's get on with it.

by ttul 5mo ago

LelouBil 5mo ago
Do you have any examples ? It's the first time I hear about replacing API keys
- leoooodias 5mo ago
  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.
- jpalawaga 5mo ago
  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.
  - JoeBOFH 5mo ago
    So how would this help in this case? The oauth info would’ve just been in the csv or in someone’s env file.
    - sofixa 5mo ago
      With OIDC, the "info" would be just a URL with the public signing keys that the server accepts as legitimate signers. The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate. So the "info" leaking is really not a problem.
  - XorNot 5mo ago
    At that point you've just reinvented Kerberos tickets really...
    - dcrazy 5mo ago
      It’s almost like Kerberos was designed and implemented for a reason!
  - jallmann 5mo ago
    > OAuth with refresh tokens. Then the LLM slurps up your refresh token. What's next?
    - kittoes 5mo ago
      Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password. Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
      - jallmann 5mo ago
        The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens. Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own. What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best. Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
      - Sohcahtoa82 5mo ago
        > Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place? The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token. It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything. I grow so tired of half-baked security theater.
    - deleted 5mo ago
      [deleted]
- mooreds 5mo ago
  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 https://fusionauth.io/blog/securing-your-api
- kittoes 5mo ago
  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.Resources https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour... Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Functions https://dev.azure.com/byteterrace/Koholint/_git/Web.Function... Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
  - eddythompson80 5mo ago
    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 {OrgName}/{ProjectName}/Repos/Files/{RepoName}
parliament32 5mo ago
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.
eddythompson80 5mo ago
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.

Yet another argument for the death of the API key. Replacements abound; let's get on with it.

by ttul 5mo ago

Yet another argument for the death of the API key. Replacements abound; let's get on with it.

LelouBil 5mo ago

Do you have any examples ? It's the first time I hear about replacing API keys

leoooodias 5mo ago
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.
jpalawaga 5mo ago
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.
- JoeBOFH 5mo ago
  So how would this help in this case? The oauth info would’ve just been in the csv or in someone’s env file.
  - sofixa 5mo ago
    With OIDC, the "info" would be just a URL with the public signing keys that the server accepts as legitimate signers. The server still does authorisation on top. And unless you control the private keys, you cannot mint JWTs that are accepted as legitimate. So the "info" leaking is really not a problem.
- XorNot 5mo ago
  At that point you've just reinvented Kerberos tickets really...
  - dcrazy 5mo ago
    It’s almost like Kerberos was designed and implemented for a reason!
- jallmann 5mo ago
  > OAuth with refresh tokens. Then the LLM slurps up your refresh token. What's next?
  - kittoes 5mo ago
    Is that really a concern though in the same way API keys are? Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? API keys are truly passwords, while refresh tokens are exchanged for a password. Sure, a leak would be bad but I'd argue that it's orders of magnitude less likely compared to the accepted norm.
    - jallmann 5mo ago
      The accepted norm is, increasingly, full disk access, regardless of how bad of an idea it is. At a minimum, agents typically will have a way of obtaining new access tokens. Refresh tokens don't solve anything in this case; they just shuffle the problem around, and introduce other complications of their own. What you want are capability scoped credentials that are enforced on the backend. That is agnostic to credential issuance mechanism, although passkeys are the best. Using these credentials effectively still presupposes hygiene that might not exist in a typical developer environment, eg no root credentials (or access to such) sitting anywhere. There's probably a good product and market for whoever can solve this in a low-friction way.
    - Sohcahtoa82 5mo ago
      > Since when do OAuth clients store refresh tokens in areas that LLMs regularly scan? If you can store your refresh token outside of where LLMs regularly scan, then why not just store your API token in that place? The point is that refresh tokens do nothing to increase security. If a refresh token can be used to get a token, then the refresh token might as well be the actual token. It's akin to performing client-side password hashing. It doesn't make your password more secure, it just means your hash is now your password. If someone is able to sniff your traffic, hashing the password first doesn't change anything. I grow so tired of half-baked security theater.
  - deleted 5mo ago
    [deleted]
mooreds 5mo ago
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 https://fusionauth.io/blog/securing-your-api
kittoes 5mo ago
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.Resources https://dev.azure.com/byteterrace/Koholint/_git/Azure.Resour... Server - https://dev.azure.com/byteterrace/Koholint/_git/Web.Functions https://dev.azure.com/byteterrace/Koholint/_git/Web.Function... Client - https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal https://dev.azure.com/byteterrace/Koholint/_git/Web.Portal
- eddythompson80 5mo ago
  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 {OrgName}/{ProjectName}/Repos/Files/{RepoName}

parliament32 5mo ago

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.

eddythompson80 5mo ago

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.