Currently working on a project where we have multiple services that all need to consume the same authorization service when their endpoints are hit. Right now we have the authorization boilerplate code copied into all of our services, but we're looking for a way to make things more reusable. The idea we're considering is to just pull out the authorization code into its own library and just reuse this. It will definitely work, but there is some reservation about creating a small library to save a couple hundred lines of repeated code. I'm not sure myself if this is really good design or not. I can see that it might be introducing a new dependency for minimal gain and it makes me wonder how important the DRY principle is across microservices. What are best practices for handling something like this?

Diagram of the system: enter image description here

2 Answers 2


One option is to have an "application gateway"

Essentially you do the authentication redirection and token checking in a software router such as nginx and have the services with no auth hidden behind it.

  • Unfortunately I don't have the ability to spin up new services; I have to deal within the confines of the existing architecture. I may add a diagram to the question if it helps.
    – Astrum
    Feb 3 at 18:16
  • Updated the question with a diagram. Only thing I can touch is the cluster of services that consume the data + authorization API. Authorization is being done in the downstream service as well, but we must also authorize before we send a call.
    – Astrum
    Feb 3 at 18:33
  • @Astrum Have you communicated the need to spin up the new service? The risk of not doing so? Please don't avoid a better design simply because you didn't want to talk to people. Feb 3 at 19:08
  • @candied_orange I've talked to people about it and there's nothing we can really do. Our architects are all-powerful and incompetent.
    – Astrum
    Feb 3 at 19:39
  • 1
    @Astrum I'm very confused. You say you're not allowed "to put the authorization in the data API" yet your diagram shows a label that reads "Data + Authorization Service". Feb 3 at 20:11

Avoid helper libraries.

The danger here is that you move what is essentially configuration code out to a library which isn't generic enough to handle all the options that it wraps.

A shared helper lib will lock you into a single approach and because all your other project depend on it, making a change to that library will become harder and harder as time goes on.

  • That's definitely a compelling argument against that approach. So what is an alternative? Just duplicating the code for each service we spin up?
    – Astrum
    Feb 3 at 18:48
  • yeah the balance between DRY and WET philosophies. obvs you have to see the actual code to make a call
    – Ewan
    Feb 4 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.