Hey Platform Engineering group, we’re having an internal debate that comes up times and times again and I wanted to ask your guys experience about it. We built a microservice architecture in which every microservice shares authentication code (at the moment all the services are in the same language, so that works more or less). We use JWT for authentication. As you may imagine it’s very annoying to maintain the same logic in many places. One of our engineers suggested a centralised approach, e.g a central microservice handling authentication, with all the other services relying on it. We have yet to reach consensus if this would work or not (reliability immediately springs to mind). Does someone have experience with this they would like to share?

That’s the direction that we’re headed in, by moving authn/authz (gradually) to a centralised service that hooks into our API Gateway https://www.getambassador.io/docs/emissary/latest/howtos/basic-auth/

Centralized place is how AWS IAM works and pretty typical for large scale platform, this is also how we built the internal platform here in Tencent

Is there any reason why you decided against

ngx_http_auth_jwt_module

and built a custom service instead?

Ambassador/Emissary Ingress doesn’t provide central authentication, but the mechanism to handle it. Our service (built out of existing authn/authz code from the monolith) handles allow/deny and (re)builds headers to downstream services

What would you do in event of failure? Even iff unlikely, if your authentication service fails, the entire platform comes to a halt

High-availability for the service where possible, similar to the API Gateway itself and other potential single-point-of-failures. Certainly not saying it’s the best/optimal solution, just 1 of many 🙂

+1 for looking at API Gateways. I work for tyk.io, if you are interested to explore this option, you might want to take a look our open source gateway: https://github.com/TykTechnologies/tyk

@Andrew Kirkpatrick we also looked at Emissary. Wondering if youre on AWS and compared AWS API Gateway. Were going down this route now of figuring out our API gateway solution. @Ross Hendrickson might be able to chime in he was heavily involved there.

We’re on GCP so we never investigated, although we looked at Tyk, Kong and Traefik also. Am unsure with AWS API Gateway if you can manage users outside of Cognito? (our Auth service is fully standalone with domain-specific logic)

PM me @Andrew Kirkpatrick, there are many options for solving this problem. Happy to help

What about using a sidecar approach , and route all traffic to this sidecar( that could be a docker container running with the auth part, in any language ) and this sidecar calls to your api on localhost at other port ?

Again one huge single point of failure