Inspired by: https://hackernoon.com/improve-the-security-of-api-keys-v5kp3wdu
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 "Anonymous 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.
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.sh
to 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.
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
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
API_KEY=your-key go run main.go
- clustering currently not possible
will be possible in the future with redis integration