3.2 Security

Security is not an afterthought; it's a critical aspect that must be integrated into the design of any system from the beginning. For a system design interview, you're not expected to be a deep cryptography expert, but you must demonstrate an understanding of core security principles and how to apply them.

We'll cover:

  • 3.2.a Authentication and Authorization
  • 3.2.b Encryption
  • 3.2.c Common Security Threats

Let's start with the fundamental concepts of identity and permissions.

3.2.a Authentication and Authorization

These two terms are often used together but mean very different things. It's crucial to distinguish between them.

Authentication ("Who are you?")

Authentication is the process of verifying the identity of a user, service, or device. It's about proving that you are who you claim to be.

  • Common Authentication Factors:
    • Something you know: Password, PIN, security questions.
    • Something you have: A physical device like a phone (for SMS OTP), an authenticator app (TOTP), or a hardware security key (U2F/WebAuthn).
    • Something you are: Biometrics like a fingerprint or face scan.
  • Multi-Factor Authentication (MFA): A highly recommended practice that combines two or more of the above factors to significantly increase security.
  • Protocols and Standards:
    • OAuth 2.0: An open standard for delegated authorization. It allows a user to grant a third-party application limited access to their resources on another service, without exposing their credentials. It's the framework behind "Log in with Google/Facebook."
    • OpenID Connect (OIDC): A simple identity layer built on top of OAuth 2.0. While OAuth 2.0 is about authorization, OIDC is what handles the actual authentication part—verifying the user's identity and obtaining basic profile information in a standard way.
    • JWT (JSON Web Token): A compact, self-contained token that is often used to represent a user's identity and session after they have successfully authenticated. The server creates a JWT and sends it to the client. The client then includes this token in the Authorization header of subsequent requests. Since the token is digitally signed by the server, the server can verify its authenticity without needing to look up session data in a database, making it great for stateless architectures.

Authorization ("What are you allowed to do?")

Authorization is the process of determining if an authenticated entity has the necessary permissions to access a specific resource or perform a particular action. This step always happens after successful authentication.

  • Common Authorization Models:
    • Role-Based Access Control (RBAC): This is a very common and effective model. Permissions are associated with roles (e.g., admin, editor, viewer), and users are assigned one or more roles. The system checks the user's role to see if they have permission for an action.
    • Access Control Lists (ACLs): A list of permissions is attached to each resource (e.g., a file or a document). The list specifies which users or groups are granted access and what operations they are allowed to perform.
    • Attribute-Based Access Control (ABAC): A more fine-grained and powerful model where access rights are granted based on attributes of the user, the resource, the environment (e.g., time of day, location), and the requested action.

Summary for an Interview

  • Clearly distinguish: Authentication is about identity, Authorization is about permissions.
  • For user login, mention using an industry standard like OIDC with OAuth 2.0.
  • Propose using JWTs for managing user sessions between the client and server.
  • For controlling access, suggest a common model like RBAC for its manageability.
  • State that authorization logic can often be centralized in the API Gateway, which checks a user's role/permissions before forwarding a request to a backend service.
Advertisement