Field note · · 1 min
Most SaaS auth fails after login, not at it
Teams pour effort into proving who you are. The breach is almost always in what you are allowed to do once you are in. Authentication is the door. Authorization is the building.
Teams spend their security budget on the login screen. Password rules, MFA, session handling, the OAuth dance. All of it answers one question: are you who you say you are.
Then you are inside, and a different question takes over: what are you allowed to touch. That question is where multi-tenant SaaS actually breaks.
Authentication is the door. Authorization is the building.
Most teams have a good door and an open floor plan.
The failure mode I find most often is not a missing check. It is a check that trusts the wrong input. An endpoint that reads the tenant ID from the request instead of the session. A list query that filters by a parameter the client supplies. A document fetch by ID that never confirms the document belongs to the caller’s tenant. Each one works perfectly in the demo, because in the demo there is one tenant and they own everything.
It surfaces the day two tenants share an instance and one of them is curious. Increment an ID, change a slug, and the boundary that was supposed to exist turns out to have been a convention, not a control.
Authentication you can buy. Authorization you have to mean. It is not a library you add at the edge. It is a decision the system has to make correctly on every request, against the one piece of state the client is not allowed to forge: who the session says you are.
When I open a multi-tenant system, I do not start at the login. I start one request past it, and I ask the same thing every time: if I change this ID, whose data do I get.