title: HTTP Basic Authentication instead of TLS client certification
body: <p>The answer below is from <a href="https://stackoverflow.com/questions/454355/security-of-rest-authentication-schemes">this</a> question;</p>
  <blockquote>
  <p>The awarded answer doesn't actually address the question at all. It only mentions SSL in the context of data transfer and doesn't actually cover authentication.</p>
  <p>You're really asking about securely authenticating REST API clients. Unless you're using TLS client authentication, SSL alone is NOT a viable authentication mechanism for a REST API. SSL without client authc only authenticates the server, which is irrelevant for most REST APIs.</p>
  <p>If you don't use TLS client authentication you'll need to use something like a digest-based authentication scheme (like Amazon Web Service's custom scheme) or OAuth or even HTTP Basic authentication (but over SSL only).</p>
  </blockquote>
  <p>So considering I will use <strong>HTTPS without client certification</strong>
  my question here is poster says if we dont use <strong>client SSL certification</strong> server does not really know whom its talking to. What I understand here is if I use a authentication-token to access to authenticate the client against the server. Then server does not know whom is sending the token <strong>even</strong> if that token is paired  with a user id in my servers database.</p>
  <p>First of all</p>
  <p>1-is this a real problem? If I especialy use Https?(without TLS client authentication)</p>
  <p>2- and most important, assuming that is an important security flaw; How can Http basic authentication help here as poster mentioned? Http basic authentication just sends encoded username password in a header. So when client receives a token (<strong>in return after he sends his username password)</strong> then for the rest of his requests he will use this token in this header instead of password, and everything is fine all of a sudden?</p>
  <p>Still Server does not know from where the request is coming from, maybe server has a valid token with a matched user in its database but unknown who really<strong>send</strong> it.
  (while I still see this very hard that the token would be stolen over https and used by someone else!)</p>
  <p>Whenever I bring this subject I get replies..&quot;Well..you send a token but server does not know whom send the token, not very secure&quot; so I understand this as the browser keeps a sort of auth-certification and server knows where the request is coming from the right place THEN I can be sure that the paired user with that token (checked from my DB)is &quot;really correct&quot;</p>
  <p>Or maybe what am telling here is not correct</p>