I’ve been thinking lately about how all of the authentication methods used in API to API communications (RESTful API’s) are mostly methods that have been designed to be human oriented first (tokenspasswordsetc) & how in API this often means you need a secret store to have the passwordstokens stored in it.
My idea is that the requester API will contact the receiver API with a hashed token & a callback webhook address, the callback URL effectively acting as the user identity which the receiver API then contacts (in a new connection) which he then get the unhashed token from, the receiver token then compares the hashed and unhashed version of the token and should they match he knows that the requester of the original request is in fact the API of the webhook.
I’ve also created a docker-compose POC of the concept at my github which works as i thought it will (please note that while I will gladly receive notes about the POC this question is only about the theory of the concept as a whole being secure).
Is this really secure? Is there any vulnerability I missed to this authentication method which will allow an attacker to trick the receiver API by impersonating another API?
If there isn’t is there any way to prove without a doubt (mathematically or otherwise) that this is in fact secure?
Assume the following are given:
- HTTPS is used (to protect against MITM) on all requests
- The backend DB is secure
- Tokens are generated randomly & are not reused
- The hashing function is modern enough to provide good protection
- The DNS register of both API’s is secure
- This is an authentication only method, not authorization nor encryption.
- The main risk that this tries to protect is from attackers impersonating the legitimate requester API and sending a request to the receiver API pretending to be him in a network facing API (IE not localhost only, possibly a local subnet but also possibly through the internet).