Security vulnerabilities of POST over SSL

Assuming you mean TLS instead of SSL itself (which is far older and broken), it is absolutely fine to transmit the password in a POST request. This is standard and how virtually every major and secure web authentication service works. You just have to make sure that the TLS is configured properly. TLS mitigates all the attacks you are worried about. It uses HMAC (or a similar authentication) for integrity, and mitigates replay attacks, reflection attacks, and similar issues that affect authentication systems. Note that new vulnerabilities may be found that require either upgrading the version of TLS or manual mitigations. SSL Labs can test for known vulnerabilities in a TLS implementation.

HTTPS serves a few purposes, preventing replay attacks and providing confidentiality of the message being sent. To uphold these guarantees, the client must of course verify the TLS certificate from the server correctly, i.e. match certificate against the expected domain (or if you have self-signed certificates, against a fingerprint). Otherwise, a man-in-the-middle attack can take place without either end noticing. This way, the client knows it is really talking to the right server.

But how can the server trust the client? For that, you could use either a client certificate or, as you propose, an API key. API keys are a common concept so if there was some big issue with doing this, we would have stopped doing it by now. It is good practice to regularly renew an API key and it might convenient to have a key ID field to be able to rotate them easily, but generally it should not be a big risk to use the same key for years -- of course, it depends on the sensitivity of the information, how many people have access to the key, etc.