How to secure the rest endpoint about agenda-rest

[keyvan-m-sadeghi]

Hi @hosnas, @Arvant has sent a pull request, #59, that I think addresses this issue. Appreciate if you could confirm.

[sampathBlam]

@keyvan-m-sadeghi : I have added another PR #60 with a very cosmetic change regarding the Error message in case of incorrect API key.

[hosnas]

@keyvan-m-sadeghi can confirm it works as intended. Great job @Arvant and @sampathBlam 👍

I just want to say its worth mentioning it in the readme doc.

[keyvan-m-sadeghi]

Agreed, @Arvant and @sampathBlam, any help with documenting this is very much appreciated.

[sampathBlam]

The current implementation with the API key looks neat and sufficient. A more robust way to authenticate would be to handle in-house OAuth2 based authentication with Client credentials strategy. As agenda-rest might be predominantly used in machine-to-machine communications (users wont directly hit the hosted agenda-rest service), it makes sense for the clients(may be another server or an application) that interact with agenda-rest to get a client ID and secret as part of a registration process, then get an application access token and use it for any further requests. @hosnas , @keyvan-m-sadeghi , @Arvant : Your thoughts on this?

[sampathBlam]

@keyvan-m-sadeghi : Yes I agree. Adding OAuth would mean increasing unnecessary complexity and would prove a hindrance in maintaining agenda as a microservice.

[geosp]

@keyvan-m-sadeghi Thank you for accepting my suggestion. I will call the header x-agenda-signature and it will be optionally enabled via settings and a flag. While I implement this feature can you please publish and bump the version for me. I have an internal project that depends on PR #70. Thank you so much for your prompt response.

[keyvan-m-sadeghi]

@sampathBlam you're absolutely right, main use case for agenda-rest is M2M interactions. As such, I'm not clear on the reason for adding complexities like a refresh token. What's the added value? In addition, I'm very much for agenda-rest remaining a microservice, wouldn't adding this be a practice used in monoliths?

[geosp]

I think is worth considering to adopt the same strategy GitHub uses to secure web-hooks. This strategy is much more secure that passing an none encrypted key. For more documentation please take a look at this https://developer.github.com/webhooks/securing. Here is some example code that shows how to validate the request you could also implement a middle-ware using this approach:

export let validateGithubRequest = ({ secret, req }) => {
  let signature = req.headers['x-hub-signature']
  let hmac = createHmac('sha1', secret)
  let body = Buffer.from(req.rawBody)
  hmac.update(body, 'utf-8')
  return signature === `sha1=${hmac.digest('hex')}`
}
.
.
.
let preserveRawBody = (req, res, bodyBuffer) => {
  req.rawBody = bodyBuffer.toString('utf8')
}

.
.
.
  const app = express(feathers())
  app
    .configure(express.rest(rest()))
    .configure(socketio())
    .configure(prometheus)
    .use(bodyParser.json({ limit: '50mb', verify: preserveRawBody }))
.
.
.

@keyvan-m-sadeghi Let me know what you think and I can implement a PR that exemplifies what I'm proposing.

[keyvan-m-sadeghi]

@geosp seems like a fine solution, I suggest that we keep the x-api-key as it still might be the preferred method for some. I'll wait for your PR, then publish to npm and bump up the version.

[keyvan-m-sadeghi]

@geosp done 🎉