Scenario: I design a REST API where authenticated users can hit the API over TLS. I have to use TLS as the data transmitted over the wire is sensitive. I don't need authorization right now, but I don't want to exlude the possibility. I want to use some kind of API Key(/Secret) method. I would prefer to avoid using OAuth. I have two possible solutions. In both cases, the API key (and secret) would be generated by us.
I. Simple API Key
Include an API key in the HTTP header, I can authenticate the client based on that header. The API key is safe, because of TLS. Replay attacks are not possible, guaranteed also by TLS. Very simple to implement by our clients. As far as I understand TLS, the request cannot be tampered (MAC). All security measures are provided by TLS. The client only adds the API Key HTTP header.
II. HMAC signature with an API secret
The request should include a signature, hashed with the secret, timestamp and the hash of the request payload. Now it cannot be tampered or replayed and the secret is not even transmitted over the wire. Safest, but hard to implement on the client side. (writing client libraries is not an option)
Does the first solution pose any threat and provide sufficient security to my clients (and our API), or I should use the more complicated second one? Also, what are the shortcomings of the first one?