←back to thread

Everything I know about good API design

(www.seangoedecke.com)
428 points ahamez | 1 comments | 24 Aug 25 19:10 UTC | HN request time: 0.213s | source
Show context
cyberax ◴[24 Aug 25 21:29 UTC] No.45007982[source]▶
> You should let people use your APIs with a long-lived API key.

Sigh... I wish this were not true. It's a shame that no alternatives have emerged so far.

replies(2): >>45008330 #>>45008372 #
pixelatedindex ◴[24 Aug 25 22:27 UTC] No.45008372[source]▶
To add on, are they talking about access tokens or refresh tokens? It can’t be just one token, because then when it expires you have to update it manually from a portal or go through the same auth process, neither of which is good.

And what time frame is “long-lived”? IME access tokens almost always have a lifetime of one week and refresh tokens anywhere from 6 months to a year.

replies(3): >>45008399 #>>45008522 #>>45008655 #
cyberax ◴[24 Aug 25 22:52 UTC] No.45008522[source]▶
If you're using APIs from third parties, the most typical authentication method is a static key that you stick in the "Authorization" HTTP header.

OAuth flows are not at all common for server-to-server communications.

In my perfect world, I would replace API keys with certificates and use mutual TLS for authentication.

replies(3): >>45008592 #>>45009001 #>>45011031 #
1. zzo38computer ◴[25 Aug 25 06:52 UTC] No.45011031[source]▶
I would also use mutual TLS; in addition to improved security (on both sides), it also allows for many additional possibilities, such as partial delegation of authorization, etc. (If not everyone wants it, it can be made an option rather than mandatory.)