Menu

1 / 4

Part 1 — Why we built an Auth Gateway instead of putting auth in every service

DEV Community·Akarshan Gandotra·6 months ago
#hO9LzKZX
#nginx#kubernetes#auth#service#tenant
Reading 0:00
15s threshold

If you've been on a platform team long enough, you've probably watched this slow-motion failure:

You ship an auth library. Three services adopt it. Six months later, two of them are still on v1.0 , one forked it to add a custom claim, and a fourth service rolled its own because the library "didn't fit their use case." A CVE drops. Now you're hunting through repos to find every place that decodes a JWT.

We've been running a multi-tenant platform on Kubernetes for a while, and we kept ending up there. So a couple of years ago we made a call: stop trying to protect every service and start making the decision once — at the edge.

This is the first post in a 10-part series about that gateway. The actual gateway is two pieces:

NGINX , packaged as a Helm chart, that fronts every authenticated route.

Auth Service , a small Go service that exposes a single POST /auth endpoint. NGINX hits it as a subrequest on every protected request.

I'll skip the marketing in this series.…

Continue reading — create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.