5 ms·
Why not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries. I would consider more complica
by jpalomaki 9y ago
Why not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries.
I would consider more complicated solutions only if you first come to conclusion that these simple things are not fit for the purpose.
True that some fancy token based solution may reduce database load, but if the API is doing something useful then that one primary key lookup and potentially the password hashing won't be a show stopper. Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly. With API key you can just change the key and requests stop immediately (with MVP product this might be an issue, since maybe you have decided to add rate limits etc later).
- comradesmith 9y agoHTTP Basic authentication should never be used, it is very vulnerable to traffic analysis attacks. HTTP Digest authentication however, would be a perfectly fine solution.
- dozzie 9y agoHow so? Over SSL? (Note that you should never call anything requiring authentication/authorization over plain HTTP.)
- comradesmith 9y agoA quick Google suggests you're right, as in either case you must run SSL/TLS. Appypolylogies.
- deleted 9y ago[deleted]
- alex_duf 9y agoI would agree, always start simple - unless you manipulate sensitive data - a shared secret is a good place to start (api-key or basic/digest auth) You can always introduce other forms of authentication later. I have a slight preference for basic/digest auth as the secret isn't part of the URL, and therefore not cached/logged by any network equipment.
- webster23 9y agoThe api-key does not need to be part of the URL, you can also put it in the Authorization header. edit: typo
- iEchoic 9y ago> Drawback with tokens and skipping the DB check is that you can't simply kill a client behaving badly. You can solve this with a token/user blacklist. There are desirable (and undesirable) characteristics of using a blacklist instead of a whitelist, but you don't lose this capability.
- mattbroekhuis 9y agoHow do you share your blacklist across servers
- DanHulton 9y agoThe same way you share any of your other data across servers. Save it in a DB or Redis instance that all your servers can reach.
- eropple 9y agoAt which point you're hitting it on every request and since it'll be a nice, fast, indexed database lookup you might as well just use session tokens instead of a back-assward blacklist. Do the simplest thing that will work.
- iEchoic 9y agoAs I mentioned, blacklists have different characteristics, some of which are desirable. A blacklist of tokens is (for the vast majority of use cases) orders of magnitude smaller than a whitelist, which means they can often be replicated into memory for in-memory lookups on the webserver. This is a complex distributed systems topic, and there are applications for both.
- eropple 9y agoThere are cases where a blacklist totally makes sense, I will agree with you on that. "I can access this thing" are totally not that for the 99.9% case. Do the simplest thing that will work--and the simplest thing so very rarely involves public-key cryptography!
- Scarbutt 9y agoWhy not use either simple API key or HTTP basic auth? Both are simple to implement and supported by all the tools and libraries. Does basic auth works if the client is a browser and you want to have a nice login screen?