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

  • You don't necessarily need to write authentication yourself. Have an independent OAuth2 service that hands out JWTs, to authorized clients. For all your spring based services, just use spring-security's in-built JWT based authentication configured to OAuth services well known URL. Ref: docs.spring.io/spring-security/reference/servlet/oauth2/…
    – S.D.
    Mar 31, 2023 at 14:49

3 Answers 3


Currently working on a project where we have multiple services that all need to consume the same authorization service when their endpoints are hit.

Here is the smell as far as I am concerned. Your services should not hit the auth service for any call in the first place. JWTs exist for just that reason. If services need the data from the user they should have it saved in their own database.


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, 2022 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, 2022 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, 2022 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, 2022 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, 2022 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, 2022 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, 2022 at 17:25
  • Wouldn’t duplicating the code result in an even more difficult change, since now one would have to go through every service, and manually change the code? Aug 3, 2022 at 4:54
  • You have to make the call in each case. Deduplication is an obvious plus, but beware the less obvious negatives
    – Ewan
    Aug 3, 2022 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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