←back to thread

428 points ahamez | 1 comments | | HN request time: 0s | source
Show context
cyberax ◴[] 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 ◴[] 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 ◴[] 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 #
nostrebored ◴[] No.45008592[source]
In your perfect world, are you primarily the producer or consumer of the API?

I hate mTLS APIs because they often mean I need to change how my services are bundled and deployed. But to your point, if everything were mTLS I wouldn’t care.

replies(1): >>45009738 #
1. cyberax ◴[] No.45009738{3}[source]
> In your perfect world, are you primarily the producer or consumer of the API?

Both, really. mTLS deployment is the sticking point, but it's slowly getting better. AWS load balancers now support it, they terminate the TLS connection, validate the certificate, and stick it into an HTTP header. Google Cloud Platform and CloudFlare also support it.