

Simple Ways to Protect an API - nwjsmith
http://techblog.thescore.com/2014/06/25/http-basic-authentication-and-http-token-authentication/

======
lsh123
It is not 100% clear but it looks like the authentication credentials in the
blog post are static and are shared between clients (from the code comment:
“In real applications, we will not have the authentication credentials lying
around in code. We will store them in external configuration.”).

This is REALLY bad idea to have static and shared credentials. Especially in
the case of mobile client when the client code itself is in a "hostile"
environment. A "bad" guy can inspect the code and extract the authentication
credentials. As soon as it happens, you need to update _all_ other clients to
push the new shared secret.

While OAuth protocol has a number of problems, it gets this right: all the
tokens are specific to the client and the compromise of one token would not
compromise others. The application can react by marking the compromised token
as invalid on the server side without requiring expensive clients update.

~~~
ttharma
Agreed, and theScore client apps actually use OAuth. We use HTTP Token
Authentication for internal services with a limited number of consumers (other
internal services). For this purpose, static and shared credentials are fine.

~~~
lsh123
If this is an internal services call, then I am not sure what is the value of
having HTTP authentication. Personally, I would setup X509 certificates on
both client and server; and then just use those for the authentication. Plus
IP restriction if you are hosting in the cloud.

------
vijayaggarwal
According to RFC 2617[1], _Both Digest and Basic Authentication are very much
on the weak end of the security strength spectrum._

[1]:
[http://tools.ietf.org/html/rfc2617#section-4.4](http://tools.ietf.org/html/rfc2617#section-4.4)

~~~
EvanAnderson
The main criticism relates to eavesdropping. Wrapping Basic or Digest
authentication in TLS eliminates that issue.

~~~
xorbyte
The article makes no mention of TLS anywhere, and the example endpoints are
all HTTP. So, this is a thoroughly insecure implementation, relying on very
weak security mechanisms, prone to straightforward interception and tampering,
replay etc.

------
mobiuscog
Why is the API accessible from the public internet if it's not a public API ?

~~~
andreasklinger
Why is an `/admin` area password protected if it's on the public internet?

