Archived... please refer to the new repo auth-service
- execute
npm install
to install dependencies - execute
node index
to run the server, it will listen on port 6010
- execute
npm install
to install dependencies - execute
INTERFACE=grpc node index
to run the server, it will listen to port 6010
- build the project using
docker build -t authservice:latest .
- once build is successful, execute
docker run -it -p 6010:6010 -d authservice:latest
- to use the gRPC interface, add the line
ENV INTERFACE grpc
to the Dockerfile or usedocker run -it -e INTERFACE=grpc -p 6010:6010 -d authservice:latest
- to run integration, test execute
npm test:integration
- to run unit test, execute
npm test:unit
- to run both, execute
npm test
GET /check
response
{
status: true
}
POST /register
request body
{
"username": "user1",
"password": "password,
}
response body
{
"token": "alkaljv"
"refreshToken: "asdasdasd"
}
POST /login
request body
{
"username": "user1",
"password": "password,
}
sample response
{
"success": true
}
gRPC .register
params
{
"username": "user1",
"password": "password"
}
response
{
"status": 201,
"message": "success"
}
gRPC .login
params
{
"username": "user1",
"password": "password"
}
response
{
"status": 200,
"token": "kajlkjfldajfb",
"refreshToken": "apjapvjp"
}
There are 2 settings that can be configured by supplying ENV vars:
- PORT: port where the app listens to (default: 6010). note: you have to change the
EXPOSE
on the Dockerfile. - INTERFACE: rest or grpc (default: rest)
example: executing PORT=3001 INTERFACE=grpc node index
will make the app listen to port 3001 and use the grpc interface
Prerequisites:
- kubernetes cluster
- a running ambassador instance
execute kubectl apply -f ./deploy/deploy.yml
. you should be able to access the api endpoints with http://${AMBASSADOR_IP}/auth/
example: GET http://localhost/auth/check would let you check if server is running.
- To make it simple, I did not add configuration files. If I need to add it, I would probably use
dotenv
. - This uses
registry pattern
to inject the db. - I used rsa256 auth type for jwt, where there is a private key to sign the issued token and a public key to verify its signature.
- I know it is not a good practice to upload the key files to the repo but this is the easiest way as of the moment.
- There are a lot of ways to manage this key file, a way I used before is aws ssm, another way could be using hashi corp vault.
- Separating unit and integration my seem trivial in this repo, but in production it makes more sense because there will be more files (even on microservices, it won't be this small).