Authentication vs authorization in HLD - Design Approaches Compared

Design: Authentication and Authorization System

Design covers user identity verification and access control mechanisms. Does not cover user registration or password recovery flows.

Functional Requirements

FR1: Allow users to securely prove their identity (authentication).

FR2: Control user access to resources based on permissions (authorization).

FR3: Support multiple authentication methods (e.g., password, OAuth).

FR4: Support role-based access control for authorization.

FR5: Provide secure token issuance for session management.

FR6: Log authentication and authorization events for auditing.

Non-Functional Requirements

NFR1: Handle 10,000 concurrent login requests.

NFR2: API response latency p99 < 200ms for authentication and authorization checks.

NFR3: Ensure 99.9% uptime for authentication services.

NFR4: Protect user credentials and tokens with encryption and secure storage.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Authentication service

Authorization service

User database

Token service (e.g., JWT issuer)

API gateway or middleware for access control

Audit logging system

Design Patterns

Role-Based Access Control (RBAC)

OAuth 2.0 / OpenID Connect

Token-based authentication (JWT)

Session management

Zero Trust security model

Reference Architecture

  +-------------+       +----------------+       +--------------+
  |             |       |                |       |              |
  |   Client    +------>+ Authentication +------>+ Token Service|
  |             |       |    Service     |       |  (JWT Issuer)|
  +-------------+       +----------------+       +--------------+
         |                      |                        |
         |                      |                        v
         |                      |                +---------------+
         |                      |                | Authorization |
         |                      |                |    Service    |
         |                      |                +---------------+
         |                      |                        |
         |                      |                        v
         |                      |                +---------------+
         |                      |                | User Database |
         |                      |                +---------------+
         |                      |                        |
         |                      |                        v
         |                      |                +---------------+
         |                      |                | Audit Logging |
         |                      |                +---------------+

Components

Authentication Service

Node.js/Java/Python REST API

Verify user identity using credentials or external providers.

Token Service

JWT library

Issue signed tokens after successful authentication for session management.

Authorization Service

Microservice with RBAC logic

Check user permissions and roles to allow or deny resource access.

User Database

PostgreSQL or NoSQL

Store user credentials, roles, and permissions securely.

API Gateway / Middleware

Nginx/Envoy or custom middleware

Intercept requests to enforce authentication and authorization.

Audit Logging System

Elastic Stack or Cloud Logging

Record authentication and authorization events for security audits.

Request Flow

1. Client sends login request with credentials to Authentication Service.

2. Authentication Service verifies credentials against User Database.

3. If valid, Token Service issues a signed JWT token to client.

4. Client includes JWT token in subsequent requests to API Gateway.

5. API Gateway extracts token and calls Authorization Service to check permissions.

6. Authorization Service verifies token and user roles from User Database.

7. If authorized, request proceeds to target resource; else denied.

8. All authentication and authorization events are logged in Audit Logging System.

Database Schema

Entities: - User: id (PK), username, password_hash, email - Role: id (PK), name - Permission: id (PK), name, description - UserRole: user_id (FK), role_id (FK) - RolePermission: role_id (FK), permission_id (FK) Relationships: - User to Role is many-to-many via UserRole - Role to Permission is many-to-many via RolePermission This schema supports RBAC authorization and secure credential storage.

Scaling Discussion

Bottlenecks

Authentication Service CPU and memory under high login load.

Token Service signing tokens can become a bottleneck.

Authorization Service latency increases with complex permission checks.

User Database read/write load spikes.

Audit Logging storage and query performance.

Solutions

Scale Authentication Service horizontally behind load balancer.

Use efficient JWT libraries and cache public keys for token verification.

Cache user roles and permissions in Authorization Service to reduce DB calls.

Use read replicas and sharding for User Database.

Implement log aggregation with retention policies and indexing for Audit Logging.

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Clearly differentiate authentication (identity verification) and authorization (access control).

Explain choice of token-based authentication for stateless sessions.

Discuss RBAC for manageable authorization.

Highlight security best practices like encryption and audit logging.

Address scalability by caching and horizontal scaling.