https://platformengineering.org logo
Title
l

Lennard Berger

10/18/2022, 12:45 PM
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?
a

Andrew Kirkpatrick

10/18/2022, 1:29 PM
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/
s

Sean Wang

10/18/2022, 1:31 PM
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
l

Lennard Berger

10/18/2022, 1:31 PM
Is there any reason why you decided against
ngx_http_auth_jwt_module
and built a custom service instead?
it looks to me like Ambassador would fill exactly the same set of functionality
a

Andrew Kirkpatrick

10/18/2022, 1:37 PM
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
(note that we’re not building net-new centralised authn/authz, but moving existing code from 2-3 services to a single service that will sit in-front of n services in the future)
l

Lennard Berger

10/18/2022, 1:39 PM
What would you do in event of failure? Even iff unlikely, if your authentication service fails, the entire platform comes to a halt
Where JWT tokens are decentralised. You need the secret for the checksums, and thats it
a

Andrew Kirkpatrick

10/18/2022, 1:41 PM
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 🙂
s

Sonja Chevre

10/19/2022, 8:21 AM
+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
a

Andre Marcelo-Tanner

10/20/2022, 12:14 PM
@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.
a

Andrew Kirkpatrick

10/20/2022, 1:32 PM
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)
Would be curious of the performance/limitations of the Lambda authorizers if anyone has experience? https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
r

Ross Hendrickson

10/20/2022, 4:02 PM
PM me @Andrew Kirkpatrick, there are many options for solving this problem. Happy to help
r

Rodrigo Amaro

10/21/2022, 4:40 AM
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 ?
l

Lennard Berger

10/21/2022, 5:32 PM
Again one huge single point of failure