Difference between Authentication and Authorization in LLD | System Design

When building computer programs, especially when designing complex systems, it’s super important to understand two key things: authentication and authorization. Even though these words sound similar, they do different jobs to keep our systems safe.

1. What is Authentication?

Authentication is a process used in system design to verify and confirm the identity of users or entities trying to access a computer system, application, or network. It ensures that only authorized individuals or systems are granted access, protecting sensitive information and resources from unauthorized use.

2. User Authentication in Low Level Design (LLD)

Here are the steps involved in planning or designing the authentication process:

Below is the explanation of the steps mentioned above:

1. Authentication Section: Create a special part of the system just for checking if users are who they say they are.
2. User Information: Decide where and how the software will keep things like usernames and passwords.
3. Password Safety: Figure out how to keep passwords safe using special techniques.
4. Login Management: Plan how the software will handle users logging in, including how long they can stay logged in.
5. Extra Security Steps: Decide how to include extra security layers, like using a code sent to a user’s phone.
6. Dealing with Mistakes: Plan what happens if someone tries to log in and makes a mistake, like limiting their attempts.
7. Special Cases: If users forget their passwords, design a secure way for them to reset it.
8. Connecting to Other Systems: If your system needs to work with other systems for login, decide how they will talk to each other.
9. Protecting Against Attacks: Plan how to stop different types of attacks, like someone trying lots of passwords.
10. Testing Everything: Create tests to make sure the login system works correctly and is secure.

3. Authentication Methods

3.1. Password-based Authentication:

• Description: The most common form of authentication, users provide a unique password to verify their identity.
• Considerations: Passwords should be complex, stored securely, and users should be encouraged to use unique passwords.

3.2. Multi-Factor Authentication (MFA):

• Description: Requires users to provide multiple forms of identification, such as a password and a temporary code sent to their mobile device.
• Advantages: Enhances security by adding an extra layer of verification, even if one factor is compromised.

3.3. Biometric Authentication:

• Description: Involves using unique physical or behavioral characteristics for identification, like fingerprints, facial recognition, or voice recognition.
• Considerations: Biometric data should be securely stored and processed to prevent unauthorized access.

3.4. Token-based Authentication:

• Description: Users are given a physical or digital token (like a security key or smart card) for authentication.
• Advantages: Provides an additional physical element that needs to be present for authentication.

3.5. OAuth Connect:

• Description: Protocols used for authentication and authorization in the context of web applications and APIs.
• Use Cases: Commonly used for delegated authorization, allowing third-party applications to access user data.

4. How authentication information is passed between components in a low-level design

In a low-level design, authentication information is typically passed between components through various mechanisms. The exact method may depend on the architecture, technology stack, and specific requirements of the system. Here are common approaches:

• HTTP Headers:
  • Description: Authentication tokens or credentials are often included in HTTP headers.
  • Example: Authorization header in HTTP requests, commonly using the “Bearer” token for token-based authentication.
• Cookies:
  • Description: Authentication tokens or session identifiers are stored in cookies.
  • Example: A session ID stored in a cookie, which is sent with each HTTP request.
• URL Parameters:
  • Description: Authentication information is included as parameters in the URL.
  • Example: https://example.com/resource?token=abc123
• Request Payload (Body):
  • Description: Authentication details are included in the body of the request.
  • Example: Sending a JSON object with user credentials in the request body.
• Certificates and Keys:
  • Description: Public and private key pairs, certificates, or client certificates may be used for authentication.
  • Example: SSL/TLS certificates in secure communication.
• Session Tokens:
  • Description: Session tokens are often used for maintaining authenticated sessions.
  • Example: Sending a session token in a header or as a cookie.
• OAuth Tokens:
  • Description: OAuth tokens are commonly used for third-party authentication.
  • Example: Including an OAuth token in the Authorization header.
• JSON Web Tokens (JWT):
  • Description: Compact, URL-safe means of representing claims between two parties.
  • Example: Including a JWT in the Authorization header.

5. Encryption in Authentication Processes

Encryption plays a crucial role in securing information during transmission and storage.

5.1. Secure Sockets Layer (SSL) / Transport Layer Security (TLS):

• Use Case: Encrypts data transmitted between a user’s browser and a web server (HTTPS).
• Purpose: Prevents eavesdropping and man-in-the-middle attacks by securing the communication channel.

5.2. End-to-End Encryption:

• Use Case: Ensures that data is encrypted from the sender to the recipient, preventing intermediaries from accessing the content.
• Purpose: Protects sensitive information, particularly in messaging and communication applications.

6. Hashing in Authentication Processes:

Hashing is used to protect passwords and sensitive data by converting them into irreversible, fixed-length values.

6.1. Password Hashing:

• Use Case: Instead of storing actual passwords, systems store hashed versions of passwords.
• Purpose: Enhances security by preventing exposure of actual passwords even if the database is compromised.

6.2. Salting:

• Use Case: Involves adding a unique random value (salt) to each password before hashing.
• Purpose: Mitigates the risk of rainbow table attacks, where precomputed hashes are used to crack passwords.

6.3. Checksums and Message Digests:

• Use Case: Verifying data integrity by comparing hash values before and after transmission or storage.
• Purpose: Ensures that the data has not been altered or corrupted.

7. What is Authorization?

Authorization is the process of determining what actions or operations a user, system, or entity is allowed to perform within a software system or a network. It is a crucial aspect of security that ensures only authorized individuals or entities have access to specific resources, functionalities, or information.

8. User authorization in Low Level Design (LLD)

When implementing authorization in the Low-Level Design (LLD) phase of software development, you’re basically figuring out how the system decides who can do what. Here’s how you do it:

Below is the explanation of the steps mentioned above:

1. Create an Authorization Module: Design a special part of the system that handles who gets permission to do certain things.
2. Decide on Permission Structure: Figure out how permissions are structured—like who can access what—and how users or roles get these permissions.
3. Choose Access Control Method: Decide whether you’re using Access Control Lists (ACLs) or Role-Based Access Control (RBAC) to manage access.
4. Protect Resources: Plan how to safeguard important stuff (data, functions) based on who is allowed to access it.
5. Context and Conditions: If needed, think about situations where access might change based on specific conditions, like the time of day or user location.
6. Hierarchy and Roles: If applicable, design a system where higher-ups have control over permissions for those lower down in the hierarchy.
7. Dynamic Changes: Plan for situations where permissions might change while the system is running.
8. Keep Track of Actions: Design a way to keep a record of who accessed what, especially for security monitoring.
9. Connect with Authentication: Make sure that the authorization part works closely with the authentication (login) system.
10. Handle Errors: Decide what happens when someone tries to do something they’re not allowed to do—how does the system respond?
11. Check Everything Works: Test the authorization system thoroughly to make sure it allows the right people to do the right things.

9. Authorization Models

After the authentication step, users want access to specific data to do their tasks. For this, they need authorization. Here are some common authorization methods:

9.1. Role-Based Access Control (RBAC):

• What it is: Assigning roles to users or groups, letting them access only what their role requires.
• Example: HR personnel can access HR data but not finance information.

9.2. Security Assertion Markup Language (SAML):

• What it is: Using an XML-based protocol for Single Sign-On, allowing admins to control resource access.
• Example: Access permissions are communicated through digitally signed documents.

9.3. OpenID Authorization:

• What it is: Checking a user’s identity through OpenID standards, ensuring consistency across systems.
• Example: Standardised authorization based on authentication from an authorization server.

9.4. OAuth Authorization:

• What it is: It allows secure access within applications using permission tokens.
• Example: Users grant access to their information to certain apps without sharing their password.

9.5. Device Permissions:

• What it is: Granting access based on the device trying to connect to a resource.
• Example: Only approved devices can establish a connection.

9.6. Location Permissions:

• What it is: Allowing or denying access based on the user or entity’s location.
• Example: Access permissions may vary depending on whether the user is in the office or working remotely.

9.7. Mandatory Access Control (MAC):

• What it is: It’s about controlling permissions at a deep level in the computer system, usually managed by an admin.
• Example: Only an admin can decide who can access certain files or memory.

10. Key Differences between Authentication and Authorization

Authentication	Authorization
In the authentication process, the identity of users are checked for providing the access to the system.	While in authorization process, a the person’s or user’s authorities are checked for accessing the resources.
In the authentication process, users or persons are verified.	While in this process, users or persons are validated.
It is done before the authorization process.	While this process is done after the authentication process.
It needs usually the user’s login details.	While it needs the user’s privilege or security levels.
Authentication determines whether the person is user or not.	While it determines What permission does the user have?
Generally, transmit information through an ID Token.	Generally, transmit information through an Access Token.
The OpenID Connect (OIDC) protocol is an authentication protocol that is generally in charge of user authentication process.	The OAuth 2.0 protocol governs the overall system of user authorization process.
Popular Authentication Techniques- Password-Based Authentication Passwordless Authentication 2FA/MFA (Two-Factor Authentication / Multi-Factor Authentication) Single sign-on (SSO) Social authentication	Popular  Authorization Techniques- Role-Based Access Controls (RBAC) JSON web token (JWT) Authorization SAML Authorization OpenID Authorization OAuth 2.0 Authorization
The authentication credentials can be changed in part as and when required by the user.	The authorization permissions cannot be changed by user as these are granted by the owner of the system and only he/she has the access to change it.
The user authentication is visible at user end.	The user authorization is not visible at the user end.
The user authentication is identified with username, password, face recognition, retina scan, fingerprints, etc.	The user authorization is carried out through the access rights to resources by using roles that have been pre-defined.

11. Security challenges and best practices related to authentication and authorization

11.1. Authentication challenges and best practices:

• Password Weakness:
  • Challenge: Users often choose weak passwords.
  • Best Practice: Enforce strong password policies and encourage the use of multi-factor authentication (MFA).
• Credential Theft:
  • Challenge: Credentials can be stolen through phishing attacks or malware.
  • Best Practice: Educate users on phishing awareness, use encrypted connections (HTTPS), and regularly update antivirus software.
• Biometric Vulnerabilities:
  • Challenge: Biometric authentication methods may have vulnerabilities.
  • Best Practice: Implement additional layers of authentication and keep biometric data secure through encryption.
• Identity Spoofing:
  • Challenge: Attackers may impersonate legitimate users.
  • Best Practice: Utilise advanced authentication methods such as device recognition, IP geolocation, and behaviour analytics.

11.2. Authorization challenges and best practices:

• Excessive Privileges:
  • Challenge: Users often have more permissions than necessary.
  • Best Practice: Follow the principle of least privilege and regularly audit and review user permissions.
• Inadequate Access Controls:
  • Challenge: Improperly configured access controls may lead to unauthorized access.
  • Best Practice: Implement proper role-based access control (RBAC) and conduct regular access control assessments.
• Session Management:
  • Challenge: Insecure session management can lead to session hijacking.
  • Best Practice: Use secure session tokens, implement session timeouts, and employ secure session handling practices.
• Dynamic Authorization:
  • Challenge: Static authorization models may not adapt to changing user roles.
  • Best Practice: Implement dynamic authorization solutions that adapt to evolving user privileges and roles.

12. Impact of Authentication and Authorization on System Scalability and Performance

12.1. Authentication

• Positive Impact
  • Scalability: Efficient authentication helps the system handle more users smoothly.
  • Performance: Fast and reliable authentication improves user experience.
• Negative Impact
  • Scalability: Complex or slow authentication can slow down the system and limit scalability.
  • Performance: Slow or resource-intensive authentication processes frustrate users and harm system performance.

12.2. Authorization

• Positive Impact
  • Scalability: Effective authorization supports efficient resource use and scalability.
  • Performance: Well-optimized authorization enhances system efficiency.
• Negative Impact
  • Scalability: Poorly implemented authorization, with rigid or complex rules, adapting to a growing user base becomes challenging.
  • Performance: Inefficient authorization processes can slow down response times and harm overall performance.

12.3. Balancing Act

• Striking a balance between strong security and system efficiency is crucial.
• Using caching mechanisms can reduce the need for repeated authentication or authorization checks, improving performance.

13. Conclusion

When you’re designing a system, it’s super important to understand two big things: authentication and authorization.

• Authentication is like checking someone’s ID to make sure they really are who they say they are.
• Authorization, on the other hand, is making sure that once someone is confirmed to be who they say they are, they only get access to the stuff they’re supposed to.

By paying attention to these details when building a system, developers can make sure it’s not just good at confirming identities but also good at controlling who gets access to what. This helps a lot in preventing unauthorized actions and keeping data safe.