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”.

  • @pe1ucaOP
    link
    fedilink
    210 months ago

    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.

    • @kevincox@lemmy.ml
      link
      fedilink
      210 months ago

      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)