I was trying to create my first actual microservice program and very soon I faced an issue: "How many times I should do the authentication?" In the first part, I describe the situation and in the second part, I show how should we configure the express gateway to perform the jwt authentication and pass the claims in the request to the service endpoints. Feel free to skip the first part and go straight to the second part. And if you only want the express-gateway jwt part, go to at the end of the article, there is a complete config which could be used. Adding the authenticated data to the request Problem statement! I was going to use jwt token authentication for users. I had 2 microservices, one for user authentication (sign up, sign in, sign out) and one for CURD operations on a model, we call them auth-service and curd-service. I started writing code, and developed the auth-service, as you know jwt uses a key to deal with the tokens (create them or verify them). Everything worked fine until I started to develop the curd-service. I needed to authenticate the user in the request before performing the desired curd-service operation, but how? When the request (let say GET entered the system, it didn't necessarily go through the auth-service, and it probably contains the jwt token in the header. If I wanted to verify and decrypt the token in the crud-service I needed the secure-key in the crud-service. It instantly raised the question of whether I should put the secure-key in the curd-service or not? What if there are many services which may be at the front line of a system, do all of them need to have access to the " "-key? I started to look for a solution, I wasn't the first person who had more than one service in his system. I found very good articles and learned a lot. /books/:_id) secure https://medium.com/technology-learning/how-we-solved-authentication-and-authorization-in-our-microservice-architecture-994539d1b6e6 https://stackoverflow.com/questions/49836268/how-to-deal-with-authentication-in-a-micro-services-architecture Long story short, one of the solutions is to have an API gateway, so every request goes through it. Adding an API gateway to your architecture has many benefits, it can perform rate limiting, request logging, acting as a proxy, handing CORS and also authenticating the requests. Although like anything else in life, it comes with its drawbacks, it can become a bottleneck or a single point of failure in the whole system. Anyway, I decided to use an API gateway as seemed (and still does) like a very good solution. By using API gateway, we can perform the authentication at the API gateway and only put the secret-key at the API gateway (besides the auth-service itself). I started looking for an API gateway and decided to go with . Express-Gateway Configuring Express Gateway for jwt Authentication The documentation on the Express Gateway is pretty neat and you can find almost anything where it should be. Here we are going to configure the express gateway to add the decoded authentication data ( jwt claims) to the request before passing it to our other services. As is mentioned in the , it supports different ways for handling the jwt token in the request. Here I use the default way which is having header with keyword. express gateway docs Authorization Bearer 1. Starting Point To be on the same page, let's say we have an auth-service which performs login and register under and on the host . We also have a curd-service for books which all start with and they are served at . /auth/register /auth/login auth:3003 /books books:4004 We need the api gateway to handle different requests. and need to be logged, and passed to as these request are not authenticated and thats the reason they are talking to . But for requests matching the gateway needs to make sure they are authenticated (contain a valid token) and also decrypt the token and add its content to the request before handing the request to . /auth/register /auth/login auth-service auth-service /books* curd-service 2. Create a new express gateway This is the same as it is mentioned on docs. a. Install Express Gateway npm install -g express-gateway b. Create an Express Gateway $ eg gateway create c. Answer a few questions ➜ eg gateway create ? What is the name of your Express Gateway? my-gateway ? Where would you like to install your Express Gateway? my-gateway ? What of Express Gateway you want to create? (Use arrow keys) ❯ Getting Started with Express Gateway Basic (default pipeline with proxy) type do d. For running it, go to the folder and run npm start 3. Configure the gateway to log and proxy the requests After creating a new express gateway it generates a pretty complete and runnable template for us which only needs to be configured. All of the configuration we need to do are at the . It also supports hot-reloading, so you don't need to restart the express gateway every time you change something in the config files. /config/gateway.config.yml I'm not going into details of how to configure express gateway because as I mentioned before the documentation is fine. I just mention the core concepts and also suggest that you read the docs. There are a few core concepts at express gateway, represent the endpoint of incoming requests (the ones system's users are sending, , and in our example). represent where the requests should be redirected to ( , in our example). are actually telling the express gateway how to handle the requests. tell the express gateway which tools we are going to use in the pipelines section (logging, authentication and proxy in our example). apiEndpoints /auth/register /auth/login /books* serviceEndpoints auth:3003 books:4004 pipelines principles We first define the log and proxy for /auth* Here we are telling the express gateway to listen to port 9080 for incoming requests, if they match the pattern and their HTTP method is POST, log them and redirect them to . Please note there is no authentication happening here. /auth* http://auth:3003 4. Authenticate and adding the authenticated data to the request If the requests contain a token which is generated using a secret-key, express gateway can authenticate and decrypt the token (assuming we provide it the same key) and put the authenticated data in the . We further need to add to the request before passing it to the desired serviceEndpoint. req.user req.user http: port: 9080 admin: port: 9876 host: localhost apiEndpoints: auth: path: '/auth*' methods: ['POST'] serviceEndpoints: auth: url: 'http://auth:3003' policies: - log - proxy pipelines: authPipeline: apiEndpoints: - auth policies: - log: action: message: 'auth ${req.method}' - proxy: action: serviceEndpoint: auth Please notice that you need to update the section too. And just adding the new , and is not enough. policies serviceEndpoint apiEndpoint pipeline http: port: 9080 admin: port: 9876 host: localhost apiEndpoints: auth: path: '/auth*' methods: ['POST'] books: path: '/books*' serviceEndpoints: auth: url: 'http://auth:3003' books: url: 'http://books:4004' policies: - log - proxy - jwt - request-transformer pipelines: authPipeline: apiEndpoints: - auth policies: - log: action: message: 'auth ${req.method}' - proxy: action: serviceEndpoint: auth booksPipeline: apiEndpoints: - books policies: - log: action: message: 'books ${req.method}' - jwt: action: secretOrPublicKey: 'the-secret-key' checkCredentialExistence: false - request-transformer: action: body: add: user: req.user - proxy: action: serviceEndpoint: books the new pipeline (booksPipeline) is performing the proxying and logging action in the same way authEndpoint performs it. The difference is that we are using two new policies. and . jwt request-transformer JWT is in charge of authenticating the jwt token in the header, by default it tries to locate it in the header but it's possible to define other approaches using the and properties. If express gateway doesn't find a valid token it responds to the request with a 401 error, which is great as the request won't enter the system and there is 1 less request needs to be worry about. specifies the secret-key, we could also use the . jwt Authorization jwtExtractor jwtExtractorField curd-service secretOrPublicKey secretOrPublicKeyFile By setting the as we are telling the express gateway we want it in the mode, you can read about this . Briefly, it is saying that we create and manage the tokens in another service (express gateway has the option to create the tokens through its admin API with ) checkCredentialExistence false Uncontrolled modality here Controlled Modality As the name suggests transforms the request by adding or removing different values to its header or body. If you don't add this to your pipeline, the decoded information from the token won't be available to the serviceEndpoint in which express gateway redirects the requests. This is a intentional and a secure behavior, we don't want anything to be added to or removed from our request without us knowing. request-transformer request-transformer 5. What comes next? Now, when the request enters the we are sure it's authenticated and it contains the decoded information of the token (user id, role, ....) in the . You would also have the jwt token unchanged, if you wish to remove it from the request for any reason (maybe security), you can do it by another policy which can also remove stuff. curd-service req.user request-transformer I hope this has been useful, I'd be glad to get any feedback.
