
Ask HN: Vulnerabilities with Basic Auth in Header Over SSL? - davidhariri
Hey HN! I&#x27;m designing a(nother) API and I have a question for the more security-savvy users here. If I put my API on HTTPS and refuse insecure clients, is there any risk in doing authentication as a username:password authentication header instead of using tokens? I&#x27;ve used sessions and tokens in the past and the complexity of implementation makes me question if it&#x27;s needed. What do you guys think? Is this safe? It <i>feels</i> unsafe in my gut, but in principle I can&#x27;t think of anything wrong with it as long as everything happens over SSL. Please correct me if i&#x27;m mistaken.
======
joncalhoun
I would avoid this.

Imagine your API user is testing it out via CURL and accidentally sends the
request to the wrong server via a typo - now they may have sent their password
to the wrong server and given them info that they shouldn't have.

Or what if someone wants to build an app on top of your API and let users
provide them with their API key? They now have to provide that app with their
username and password, rather than a revokable token.

Tokens just provide far too many benefits for a relatively minor amount of
setup to suggest using raw username/pw. You can revoke tokens. You can create
multiple for one account. You can limit permissions of tokens independently.

If you don't expect users to actually interact with your API (and instead use
it through a JS app or something similar) I would still avoid using raw
username/pw in every request. It just leaves too many opportunities for
something to go wrong. Instead check out JWT
([https://jwt.io/](https://jwt.io/)). It is incredibly simple to setup and you
would just return the token after the user hits some login endpoint.

~~~
davidhariri
Thanks Jon! I'll look into JWT.

