让我们将其分为许多点:

1):您使用有效的SSL证书来保护用户与服务器之间的通信(必须有效)

2)在POST请求的正文中发送用户名和密码是***做法(切勿使用GET发送敏感信息(例如凭据))

3)是在HTTP请求和响应标头中发送api令牌是***做法(同样，请勿使用GET发送敏感信息，例如会话令牌)

因此，基于以上几点，似乎此实施过程中没有风险，但您需要考虑以下几点:

1)对于空闲用户，API令牌的超时时间应较短. (5到15分钟是根据应用程序的关键程度得出的平均值)

2) API令牌的长度应为长字符串，约等于. 30〜40个字符.

3) API令牌的生成必须是随机的，并且难以预测以防止受到(会话预测攻击)的攻击.

希望这对您有所帮助.

I am building a web application and my web server is secure, meaning that it uses an ssl cert with the front end to encrypt the connection.

When a user logs in, a JSON object which looks like this is created, and sent to the server.

{
    username:"the user's username",
    password:"the user's password"
}

On the server this is verified with a hashing algorithm that uses a salt. Once it is verified an api token is created which is valid for a certain amount of time, and is passed back and forth in the header in order to verify the user when requests are being made. Is sending the username and password like this best practice/secure, or is it better to send it in the header?

Lets divide it to many points:

1) you use a valid SSL certificate to secure the communication between the user and the server (It must be valid)

2) Sending the username and password in the body of the POST request is the best practice (Never use GET to send sensitive information such as Credentials)

3) Sending the api token in the HTTP request and response headers is the best practice (Again never use GET to send sensitive information such as session tokens)

So based on the points above, it seems that there is no risk in this implementation but you need to take the following points in your consideration:

1) The time out of the API token should be short in case of idle user. (5 ~ 15 mins are the averages based on the criticality of the application)

2) The length of the API token should be long string approx. 30 ~ 40 characters.

3) The API token generation must be randomized and hard to predict to protect from (session prediction attacks.)

Hope this help you.