Hey HN! I'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've used sessions and tokens in the past and the complexity of implementation makes me question if it's needed. What do you guys think? Is this safe? It <i>feels</i> unsafe in my gut, but in principle I can't think of anything wrong with it as long as everything happens over SSL. Please correct me if i'm mistaken.
I would avoid this.<p>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.<p>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.<p>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.<p>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 (<a href="https://jwt.io/" rel="nofollow">https://jwt.io/</a>). It is incredibly simple to setup and you would just return the token after the user hits some login endpoint.