Authentication vs Authorization: Architecture Patterns for Web Apps

These two get conflated constantly, and the conflation is where security bugs live. A user being logged in (authenticated) says nothing about which records, actions, or accounts they should be able to touch (authorization).

Where each one happens

Common authentication patterns

• Password + secure hashing — still standard, requires proper hashing (bcrypt/argon2), rate limiting, and breach-aware validation
• Magic links / one-time codes — removes password management, good fit for low-friction B2B and portal logins
• OAuth / SSO — delegates identity to a trusted provider (Google, Microsoft, an enterprise IdP); reduces password sprawl for B2B software
• Multi-factor authentication (MFA) — an added factor beyond something you know; standard for admin and financial access

Common authorization patterns

• Role-based access control (RBAC) — permissions attached to roles, roles attached to users; scales well for internal tools and B2B products
• Attribute-based access control (ABAC) — permissions computed from attributes (department, region, project) rather than fixed roles; more flexible, more complex
• Ownership-based checks — a user can act on a resource only if they own it or belong to its account; the default pattern for client portals and multi-tenant SaaS

// Wrong: trusts an ID supplied by the client
async function getInvoice(invoiceId: string, accountId: string) {
  return db.invoice.findFirst({ where: { id: invoiceId, accountId } });
}

// Right: derives the account from the authenticated session
async function getInvoice(invoiceId: string, session: Session) {
  return db.invoice.findFirst({
    where: { id: invoiceId, accountId: session.accountId },
  });
}

A practical checklist

1. Separate the two concerns in code

   Authentication middleware confirms identity and attaches a session. Authorization checks run explicitly per resource, never assumed from a role alone.

2. Scope every query by the authenticated session

   Never accept an account, tenant, or owner ID from client input for access control decisions.

3. Choose RBAC first, add ABAC only when roles stop fitting

   Most products never outgrow roles. Attribute-based rules add real complexity; earn it before adding it.

4. Log authorization failures

   Repeated authorization failures from one account are a signal worth alerting on, not silently ignoring.

FAQ