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

  • pe1uca@lemmy.pe1uca.devOP
    1·
    1 year ago

    You got me thinking in something more, are API keys stored in plain text in DB? Otherwise I don’t see a way to quickly know it’s valid, I’d have to validate it against all the hashes in the DB.
    With client id it’d be easy to just validate the secret against a single hash for that user.

    • ck_@discuss.tchncs.de
      3·
      1 year ago

      Its never really a good approach to store secrets in plain text. I don’t see how that would be more expensive for your database than validating clientId + secret.

    • TootSweet@lemmy.worldEnglish
      2·
      1 year ago

      There are lots of solutions out there for “secrets management.” If you’re using Kubernetes, there are some which integrate with Kubernetes. I use Spring Cloud Config where I work and it supports storing encrypted values in the configuration. What solution would be best for you depends on your software stack. (And I don’t have a ton of experience with most options.) But some googling could get you more answers.