You need to consider several factors here. I hope your API key do have an expiration time ? Even if it do so, it is vulnerable to a replay attack if an adversary get hold into your HTTPS request. As a remedy, you can introduce a Time stamp or counter to your request.
Counter Replay attacks
A timestamp can be added to the message and encrypted along with the rest of the message content. The service can
retrieve the timestamp after decrypting the message and fail the request if the timestamp is too old for the threshold
that is already agreed on. This cuts down on the window of opportunity to replay a request. Downside to this approach is both server and client need be be in sync with time.
An alternative to a timestamp is a counter . With
a counter, you don’t need to be concerned about the skew between the clocks. However, clients must implement a
counter to ensure the count sent in a request is greater than the count in the previous request at least by one, and the
server must keep a record of the last received counter. Of course, the message has to be signed so that a malicious user
does not increment the counter and replay the rest of the request.
Hash-Based Message Authentication Code to Counter MITM Attack
The primary mechanism
to ensure data integrity of messages is a Hash-Based Message Authentication Code (HMAC). HMAC is just a piece
of data created through a cryptographic hashing algorithm and a shared secret key. However, if the message needs to be encrypted for confidentiality, you can easily add that functionality
using the same private key we use for HMAC or you can introduce a new key specifically for encryption.
When a user sends a request, you need to concern on following three important parameters.
- The public key, which is the key associated with the user
- The counter
- The Timestamp
In addition to the parameters, the request includes a signature that ensures that none of the parameters are
tampered with. It is possible to create the signature based not only on the three parameters but also on the entire body
of the request if the objective is to make sure nothing in the request gets modified.
To make sure no one tampers with the parameters, we can include an HMAC-SHA256 of all three values plus the
request URI and HTTP method.
You can introduce following 4 attributes to your header.
X-KEY
This is your API Key
X-Signature
If the value sent by the client application in the X-Signature matches the HMAC-SHA256 of the
values of X-KEY, X-Counter, X-Stamp, request URI, and the HTTP method, we can safely conclude
that nothing was altered in transit.
X-Stamp
The value sent by the client and the UNIX time of the current time are compared. If the
skew between these two are within the allowable tolerance limit, the request is not a replay.
UNIX time is the number of seconds elapsed since midnight of January 1, 1970 Coordinated
Universal Time (UTC).
X-Counter
If the value sent by the client is greater than the last received counter in the record kept by
the server, the request is not a replay. Although I use both the timestamp and counter in the
implementation example in this chapter, one typically is good enough, depending on your
needs. If clock times are reasonably in sync, a timestamp is the best approach because there is no
overhead in terms of storing the counter in the web API side or incrementing it in the client side.
conclusion
It is better to use already battle tested framework such as OAuth to cater your need. But if you think it is too complex, you need to consider the things that are being explained in this answer.
