Software Architect · Module 16
Security isn't the last gate before release. It's a set of architectural decisions about trust, permissions, and boundaries.
Threat modeling · least privilege · authn · authz · audit
Security starts with one question: who do we trust, why, and what happens if that trust is broken?
Authn and authz are different things
A passport proves who you are. A ticket proves you're allowed into the hall. They aren't the same document.
Authentication answers "who is this?" Authorization answers "what are they allowed to do?" The common mistake is to verify identity correctly and then forget to check access to the specific resource.
The architect has to define the permission model: RBAC, ABAC, ownership-based access, tenant isolation, service-to-service permissions. Most importantly, authorization belongs at the level of the business action — not just the endpoint.
Least privilege shrinks the blast radius
Your apartment key shouldn't open the whole neighbourhood. If it gets stolen, the damage has to be bounded.
Every user, service, token, and job should hold the minimum rights it needs. Secrets don't live in code. Production access is restricted, logged, and reviewed on a schedule.
A security architecture isn't only about the probability of an attack — it's about the blast radius: what an attacker can actually do once they've compromised one component.
A good security model makes the safe path the easiest path for the developer.
Example: tenant isolation in the repository
In an office building, each tenant has their own locked door — not a sign that reads "please don't come in."
All data access goes through a repository that requires tenantId from a trusted context. Query builders inject the tenant predicate automatically, and integration tests assert that cross-tenant reads are impossible.
That's better than asking every developer to remember the filter by hand.
Anti-example: an admin flag in the JWT, no resource check
A "staff" badge doesn't entitle you to open the safe, the accounting office, and the server room.
The API checks isAdmin=true and stops there — no check on workspace, role scope, or ownership of the resource. One token grants too much. If it leaks, the damage is maximal.
Authorization has to be contextual: subject, action, resource, tenant, conditions.
- Where are the trust boundaries in the system? - What happens if one service token leaks? - Where is authorization checked at the resource level? - Which actions end up in the audit log?