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.

Practice

1. Which of the following best describes authentication in system design?

easy

A. Encrypting user data

B. Granting access to resources

C. Logging user activities

D. Verifying the identity of a user

Solution

1. Step 1: Understand authentication purpose

   Authentication is the process of confirming who the user is by checking credentials like username and password.

2. Step 2: Differentiate from authorization

   Authorization controls what the user can do after identity is confirmed, not the identity check itself.

3. Final Answer:

   Verifying the identity of a user -> Option D

4. Quick Check:

   Authentication = Verifying identity [OK]

Hint: Authentication = Who you are, Authorization = What you can do [OK]

Common Mistakes:

• Confusing authentication with authorization
• Thinking authentication controls permissions
• Mixing identity verification with data encryption

2. Which of the following is a correct example of an authorization check in code?

easy

A. if user.password == input_password:

B. if user.session_token is not None:

C. if user.role == 'admin':

D. if user.email_verified:

Solution

1. Step 1: Identify authorization logic

   Authorization checks what actions a user can perform, often by checking roles or permissions like user.role == 'admin'.

2. Step 2: Differentiate from authentication checks

   Authentication checks credentials like passwords or tokens, not roles.

3. Final Answer:

   if user.role == 'admin': -> Option C

4. Quick Check:

   Authorization checks roles/permissions [OK]

Hint: Authorization checks roles or permissions, not passwords [OK]

Common Mistakes:

• Using password checks as authorization
• Confusing session token presence with authorization
• Checking email verification as authorization

3. Consider this code snippet:

def access_resource(user):
    if not user.is_authenticated:
        return "Access Denied"
    if user.permission != 'read':
        return "Permission Denied"
    return "Resource Content"

What will be the output if user.is_authenticated is True but user.permission is 'write'?

medium

A. "Permission Denied"

B. "Resource Content"

C. "Access Denied"

D. Error due to missing permission

Solution

1. Step 1: Check authentication condition

   The user is authenticated (True), so the first if condition fails and does not return "Access Denied".

2. Step 2: Check authorization condition

   The user's permission is 'write', which is not equal to 'read', so the second if returns "Permission Denied".

3. Final Answer:

   "Permission Denied" -> Option A

4. Quick Check:

   Authenticated but wrong permission = Permission Denied [OK]

Hint: Authenticated? Check permission next for authorization [OK]

Common Mistakes:

• Ignoring permission check and returning resource
• Confusing authentication failure with permission failure
• Assuming 'write' permission equals 'read'

4. A developer wrote this code to check access:

if user.is_authorized:
    print("Access granted")
else:
    print("Access denied")

But the system always denies access even for valid users. What is the likely issue?

medium

A. The variable is_authorized is misspelled

B. The code checks authorization without authenticating the user first

C. The print statements are reversed

D. The user object is not defined

Solution

1. Step 1: Analyze authentication and authorization order

   Authorization should only be checked after confirming the user is authenticated. Skipping authentication can cause authorization to fail.

2. Step 2: Understand why access is always denied

   If is_authorized depends on authentication, but authentication is missing, it will always be false or unset, denying access.

3. Final Answer:

   The code checks authorization without authenticating the user first -> Option B

4. Quick Check:

   Authenticate before authorizing [OK]

Hint: Always authenticate before authorization checks [OK]

Common Mistakes:

• Checking authorization without authentication
• Assuming authorization implies authentication
• Ignoring user object initialization

5. In designing a secure web service, which approach correctly applies authentication and authorization to protect user data?

hard

A. Authenticate users with passwords, then authorize access based on roles before serving data

B. Authorize users first, then authenticate them before data access

C. Allow data access after authentication without any authorization checks

D. Skip authentication if the user has a valid session token

Solution

1. Step 1: Understand correct security flow

   First, confirm user identity by authentication (e.g., passwords). Then, check what the user is allowed to do by authorization (e.g., roles).

2. Step 2: Evaluate options for security best practice

   Authenticate users with passwords, then authorize access based on roles before serving data follows the correct order: authenticate then authorize. Other options either reverse order, skip authorization, or skip authentication improperly.

3. Final Answer:

   Authenticate users with passwords, then authorize access based on roles before serving data -> Option A

4. Quick Check:

   Authenticate first, then authorize [OK]

Hint: Authenticate identity first, then authorize actions [OK]

Common Mistakes:

• Reversing authentication and authorization order
• Skipping authorization after authentication
• Trusting session tokens without authentication