How to split out shared authorization logic across spring microservices

Question

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

• S.D.: 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/…

Answer 1

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.

Answer 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.

• Astrum: 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: 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.
• candied_orange: @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.
• Astrum: @candied_orange I've talked to people about it and there's nothing we can really do. Our architects are all-powerful and incompetent.
• candied_orange: @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".

Answer 3

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.

• Astrum: That's definitely a compelling argument against that approach. So what is an alternative? Just duplicating the code for each service we spin up?
• Ewan: yeah the balance between DRY and WET philosophies. obvs you have to see the actual code to make a call
• Stefan Rendevski: 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?
• Ewan: You have to make the call in each case. Deduplication is an obvious plus, but beware the less obvious negatives