Authentication & Authorization Architecture

“How would you design access control for a multi-tenant SaaS platform?”

When IAM (Identity and Access Management) design questions like these come up, interviewers want to see if you can build identity systems that are secure, scalable, and user-friendly. They're testing whether you understand the critical distinction between proving who someone is and controlling what they can do.

Strong candidates demonstrate four key abilities:

1. Differentiate authentication from authorization and apply each appropriately
2. Design identity systems that work for users, services, and APIs at scale
3. Explain access control models (RBAC, ABAC, PBAC) and when to use each
4. Balance usability with security without sacrificing compliance or governance

The goal is showing you can secure both human and machine identities while keeping operations simple.

Authentication vs. authorization

Before diving into architecture, you need to understand the fundamental difference:

Authentication answers: "Who are you?"

• Verifies identity through credentials, tokens, or biometrics
• Happens once at the start of a session
• Example: User logs in with username/password + MFA

Authorization answers: "What can you do?"

• Enforces permissions based on verified identity
• Happens continuously as users attempt actions
• Example: User tries to delete a resource and system checks if they have permission

Authentication fundamentals

Authentication must be secure, consistent, and resistant to replay or phishing attacks. Here are the core components:

Key authentication patterns

For human users:

• Centralize identity through an IdP with SSO
• Enforce MFA for privileged access and sensitive operations
• Use session tokens with appropriate expiration (15-30 minutes for sensitive apps)

For services and APIs:

• Use short-lived access tokens (OAuth 2.0 client credentials flow)
• Implement mutual TLS (mTLS) for service-to-service authentication
• Rotate credentials automatically (e.g., AWS IAM roles, Kubernetes service accounts)

Authorization fundamentals

Authorization enforces what actions a verified identity can perform. The model you choose depends on your complexity and scale requirements.

Access control models

Core authorization principles

Least privilege:

• Grant only the minimum permissions needed to complete a task
• Time-bound elevated access (e.g., temporary admin access for deployments)
• Regularly review and revoke unused permissions

Separation of duties:

• Split high-risk operations across multiple roles
• Example: One person deploys code, another approves production changes
• Prevents single points of compromise

Visibility:

• Log every access decision (approved and denied)
• Track privilege escalations and role changes
• Enable audit trails for compliance

Key design principles

When discussing IAM architecture, always connect back to these principles:

Example

Prompt: "Design an authentication and authorization architecture for an enterprise web application that supports employees, contractors, and third-party integrations."

Here's how to structure your response with SALT:

Scope

Define what needs authentication and authorization.

"I'm designing IAM for three distinct identity types:

• Internal employees: Full-time staff with varying access levels
• Contractors: Temporary workers with limited, time-bound access
• Third-party integrations: External services that need programmatic API access

The system needs to handle both interactive user authentication and non-interactive service-to-service authorization. I'll assume we need audit logging for compliance (SOC 2, ISO 27001)."

Why this matters: Different identity types require different authentication mechanisms and authorization models.

Assets

Identify what you're protecting.

"The critical assets are:

1. User credentials and sessions: Passwords, MFA tokens, and session cookies that grant access
2. Access tokens: Short-lived bearer tokens used by services to authenticate API calls
3. Sensitive APIs and data: Customer PII, financial records, and internal business logic
4. Administrative functions: User provisioning, role assignments, and permission changes

The highest priority is protecting credentials and ensuring only authorized identities can access sensitive data or administrative functions."

Why this matters: Knowing what you're protecting shapes your authentication strength requirements and authorization granularity.

Layers

Apply IAM principles across identity, policy, and monitoring layers. Walk through each layer systematically:

1. Identity & Access layer (Authentication)

• Centralize identity through SSO (SAML or OIDC) to reduce credential sprawl and simplify lifecycle management.
• Require MFA for all privileged and sensitive accounts, using phishing-resistant factors (e.g., FIDO2, WebAuthn).
• Issue short-lived tokens or session credentials for both users and services to minimize exposure if compromised.

2. Identity & access layer (Authorization)

• Use RBAC for employees to assign predictable, role-based permissions (e.g., admin, developer, analyst).
• Apply ABAC for external services or integrations, evaluating access based on identity, resource type, and environment context.
• Enforce least privilege. Grant minimal access by default and expire elevated permissions automatically.

3. Network Layer

• Encrypt all authentication and API traffic with TLS 1.3.
• Restrict access through IP allowlisting and API gateway checks.
• Apply rate limits per identity to prevent abuse and credential stuffing.

4. Data Layer

• Protect stored credentials and tokens using strong hashing (bcrypt/Argon2) and encryption at rest.
• Combine IAM with data-level controls (e.g., row-level permissions, masking sensitive fields).
• Rotate encryption keys regularly to limit long-term exposure.

5. Monitoring & Detection Layer

• Log all authentication and authorization events, including MFA challenges and policy updates.
• Alert on anomalies such as repeated login failures, impossible travel, or privilege escalation.
• Centralize logs in a SIEM for visibility, compliance, and periodic access reviews.

Tradeoffs

• Federation simplifies user management by centralizing authentication, but introduces dependency on the Identity Provider (IdP). If the IdP is unavailable or misconfigured, it can disrupt access across systems.
• Token rotation enhances security by limiting the impact of stolen credentials, but adds operational overhead. Services must securely refresh, distribute, and store new tokens without causing downtime.

Closing summary

“Centralized identity, layered access controls, and strong logging achieve both security and usability across multiple user types.”