I have an implementation for an internal API, the requirement is to implement some sort of basic authentication instead of oauth (generating a token).
Do you think there’s any difference between using just an API key vs using a client id + secret?
For what I see it’d be just like saying “using a password” vs “using a user and a password”.
The difference is that you can have multiple API keys for the same account.
You can revoke API keys from a lost device without changing your password.
You can grant a different service a restricted API key for limited access.
API keys can expire, forcing password expiry is very use unfriendly.
The password is the “root secret” of the account. It is (mostly) unrevokable and doesn’t expire. It is a huge risk to have the password lying around. So it is better to quickly exchange the password for a less risky token, then you can wipe the password. Then all clients don’t need to store the password. The user just needs to provide it once then lower-value secrets can be used for future authentication.
I don’t fully understand what use case you’re thinking about.
An API key which expires is very hard to work with, imagine deploying an app with that kind of key, or a service/bot which uses that key.
Maybe you’re thinking about access tokens, which need to be regenerated every so often and can be generated with a refresh token.
API tokens don’t need to expire. But having them expire is a nice security benefit. It means that eventually they will be useless even if they are sitting around on an old laptop that gets thrown away.
For many use cases this works well. For example a client app can easily refresh the token from time-to-time. This can be managed with an access/refresh token system (which has the advantage that the token you are frequently sending over the wire doesn’t have refresh capabilities)
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
The difference is that you can have multiple API keys for the same account.
The password is the “root secret” of the account. It is (mostly) unrevokable and doesn’t expire. It is a huge risk to have the password lying around. So it is better to quickly exchange the password for a less risky token, then you can wipe the password. Then all clients don’t need to store the password. The user just needs to provide it once then lower-value secrets can be used for future authentication.
I don’t fully understand what use case you’re thinking about.
An API key which expires is very hard to work with, imagine deploying an app with that kind of key, or a service/bot which uses that key.
Maybe you’re thinking about access tokens, which need to be regenerated every so often and can be generated with a refresh token.
API tokens don’t need to expire. But having them expire is a nice security benefit. It means that eventually they will be useless even if they are sitting around on an old laptop that gets thrown away.
For many use cases this works well. For example a client app can easily refresh the token from time-to-time. This can be managed with an access/refresh token system (which has the advantage that the token you are frequently sending over the wire doesn’t have refresh capabilities)