Bird
Raised Fist0
HLDsystem_design~10 mins

Authentication vs authorization in HLD - Scaling Approaches Compared

Choose your learning style10 modes available
Scalability Analysis - Authentication vs authorization
Growth Table: Authentication vs Authorization
UsersAuthentication LoadAuthorization LoadSystem Changes
100 usersSimple login checks, single auth serverBasic role checks, simple permission storeMonolithic auth service, in-memory session store
10,000 usersIncreased login requests, session managementMore roles and permissions, caching neededIntroduce load balancer, distributed session cache
1,000,000 usersHigh concurrent logins, token issuanceComplex policies, attribute-based access controlHorizontal scaling of auth servers, token-based auth (JWT), distributed permission store
100,000,000 usersMassive login traffic, multi-factor authDynamic authorization, fine-grained policiesGlobal distributed auth clusters, CDN for static auth assets, real-time policy evaluation services
First Bottleneck

The first bottleneck is usually the authentication service during peak login bursts. This is because it must verify credentials, generate tokens, and manage sessions, which are CPU and I/O intensive operations. Authorization checks are generally lighter and cached, so they become bottlenecks later as policies grow complex.

Scaling Solutions
  • Authentication: Use horizontal scaling with load balancers to handle login requests. Implement token-based authentication (e.g., JWT) to reduce session state. Use caching for session validation.
  • Authorization: Cache permission data to reduce database hits. Use distributed caches like Redis. For complex policies, use policy evaluation engines that scale horizontally.
  • General: Employ CDNs for static auth assets (e.g., login pages). Use rate limiting and throttling to protect auth endpoints.
Back-of-Envelope Cost Analysis

Assuming 1 million users with 10% logging in daily:

  • Login requests per second: ~1,000,000 * 10% / (24*3600) ≈ 1.2 QPS
  • Authorization checks per second: ~1,000,000 * 10 / (24*3600) ≈ 116 QPS
  • Storage: User credentials and tokens ~100MB - 1GB depending on retention
  • Bandwidth: Login requests small (~1KB), authorization checks smaller (~0.5KB), total ~10-20 MB/s
Interview Tip

Start by clearly defining authentication and authorization. Discuss their differences and dependencies. Then explain how each scales differently. Highlight bottlenecks and propose targeted solutions. Use real numbers and simple analogies like "authentication is like checking ID at a door, authorization is like checking if you can enter a room inside." Keep answers structured and focused.

Self Check

Your authentication database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Introduce horizontal scaling by adding more authentication servers behind a load balancer and implement token-based stateless authentication (e.g., JWT) to reduce database load. Also, add caching layers for session validation to reduce repeated DB hits.

Key Result
Authentication services become bottlenecks first due to login verification load; scaling requires horizontal servers, token-based stateless sessions, and caching, while authorization scales with caching and distributed policy evaluation.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard