Anonymus API Auth Provider
Inspired by: https://hackernoon.com/improve-the-security-of-api-keys-v5kp3wdu
Architecture
The basic idea is, to prevent unauthorised access of a public endpoint by bots or bad clients. Only known clients should be able to use the api. For example when you have a POST interface which should only be able to be requested by your own website. All requests from other clients to this public POST endpoint should be rejected.
This Repository introduces a separate serive, the "Anonymus API Auth Provider" (aaap), which can be requested to retrieve an access-token. The public endpoint can then validate this token.
The aaap and the public endpoint therefore share an api-key as secret. The aaap signs the token with the api-key and the public endpoint can check if the signature was signed with this api-key. Otherwise the public endpoint would reject the request.
But before the aaap generates the access-token and sends it to the requesting client, the client has to solve a challenge. This challenge is the shared secret between the aaap and the authorised client (e.g. your website):
A bad client or a bot cannot solve the challenge provided by the aaap. In this case the aaap would send an invalid access-token to the client, and the public endpoint check for the token signature would fail. The request would be rejected:
An attacker of this public endpoint would have to reverse engineer the authorised client, to find out how the challenge of the aaap can be solved. This comes with an reasonable amount of effort especially when the code of the authorised client is obfuscated.
Usage
Define your own challenge.sh & response.sh and mount them into the docker image.
- Make sure to provide a randomly unique challenge on every execution of the
challenge.sh. - Make sure to implement the
response.shto generate a deterministic response on each given input generated by thechallenge.sh
⚠️ The response must also be implemented on your client. - Define an api-key and provide it in the environement variables of the docker image.
- Define how long the token should be valid
⚠️ The token lifetime should be validated in your public endpoint, as well as the token signature.
Docker
Build your own docker image
Integrate your challenge.sh & response.sh directly in your own docker image. It is also advisable to install some more programs, for example to generate uuids which can be used for designing your custom challenge/response.
cd example
# build
docker build -t authprovider-example .
# run
docker run -p 8080:8080 -e API_KEY=your-api-key -e TOKEN_EXPIRE=3600 -e PORT=8080 authprovider-example
Mount volume
You can also mount your custom challenge.sh & response.sh.
# build
docker build -f docker/Dockerfile -t authprovider .
# run
docker run -p 8080:8080 -v `pwd`/path/to/your/own/scripts/folder:/service/scripts -e API_KEY=your-api-key -e TOKEN_EXPIRE=3600 -e PORT=8080 authprovider
Development
API_KEY=your-key go run main.go
Known Limitations
- clustering currently not possible
will be possible in the future with redis integration
