I approached our architect with a solution in which all of our microservices verify the auth of the user invoking the call. Basically, what I've been doing for years, on different projects. He basically said that I'm digging my own grave and proposed an infrastructural layer, a proxy, which will authorize the requests instead and if request is allowed, will forward the request to the microservice, without passing on the data about the user to the microservice (has service-to-service authentication).

Has anyone done this? What are the benefits and is it worth the effort?

  • Did he explain why you would be "digging your own grave"? Did he explain why his soultion is prefered for your specific case? Maybe, the answer to the question is rather pollitical. Maybe, he's not willing to pay the offsets of having services managing their own security layer. There could be serveral reasons for that, but only those concerning your architect are those that matter. In other words. Have you asked "why" to the architect? – Laiv Feb 10 at 20:44
  • I did. He said that is going to couple the microservice with authorization. Note that we already have a service-to-service authorization, expressed through build-time dependency. The cost also isn't (or at least should not be) the reason, since the change was cheap ( 2 man days, tops. couple of hours if i did it ). – Štef FoReal Feb 10 at 20:58
  • Then you have it. He wants a single point of failure. Also a single point of control. If all the services have the very same needs for authorization, might not worth having such logic duplicated all over the system. The economical cost it's not necessarily calculated in man/hours. Probably he's thinking in the long run, foreseeing the cost of changing the authorization protocol or tecnology. Or supporting more protocols. Hard to say, we can only guess. – Laiv Feb 10 at 21:21

Your Answer

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

Browse other questions tagged or ask your own question.