Skip to content

Repository navigation

Security: owais34/system-design

Security

security.md

Security:

Auth architecture revolution

Single server cookie based auth

Auth version 1

Multi server sticky session based auth

  • Cons:
    • Sticky session binds a session to a server. If the server goes down or needs to be maintained.
    • Sticky session needs to store session data in load balancer.
  • Possible solutions:
    1. Session synchronization by replicating across web servers
    2. Store session data completely inside users' browser
      • Cons: Limited size of cookie
    3. Store session data in a shared storage

Sticky session

Auth Service and token

  • Pros:
    • Encapsulate everything related with token issuing
    • Introduce the concept of token, which could be passed around between services
  • Cons:
    • Services need to implement the logic to validate the token.
    • All services need to talk to authSvc, which might become a performance bottleneck.
    • All requests need to be verified via auth service.

Auth service and token

Gateway and token

  • Pros:
    • Gateway centralizes the logic of parsing userInfo. Only gateway need to validate the token with auth service.
  • Cons:
    • All requests need to be verified via auth service. Auth service needs to be maintained and scaled in a manageable way.

Gateway and token

Gateway and JWT

  • Pros:
    • Compact and lightweight
    • Low pressure on Auth server
    • Simplify the implementation of auth server
  • Cons:
    • Could not invalidate a JWT token if it has been leaked
    • JWT might become big

Gateway and token

JWT

Motivation
  • JWT is a type of by value token which does not need to be verified at the authorization server.
    • Def for by reference token: Randomly generated string value. Upon receiving the token, resource server needs to verify it against OAuth authorization server to obtain information such as claims/scopes.
    • Def for by value token: A token which contains key value pair of (issuer, audience, scope, claims). It could be verified locally and does not need to be verified against authorization server.
Types of JWT
  • HMAC JWT

Gateway and token

  • RSA JWT

Gateway and token

OAuth2

Simple guide

Roles

  • Third party client app: it needs to access users' protected resource
  • Resource server: a web server which expose users' protected resource to outside users
  • Authorization server: issue access token to client app after resource owner grant the permission
  • Resource owner: the owner of a resource who wants to share it with third party apps.

Types of token

Access token

  • Used to access target resource.

Refresh token

  • Used to exchange for a refreshed token

Authorization code token

  • Only used for authorization token, used for obtaining access token and refresh token.

Bearer token

  • It is like cash. Whoever has the token could access target resource.

Proof of possession token

  • Could verify whether client has ownership for the token.

OAuth 2 modes

Choose between

Authorization code mode

Authorization code mode

Simplified mode

simplified mode

Password mode

password mode

Refresh token mode

refresh token mode

OpenID Connect

  • The authentication layer on top of OAuth2

Microservices security architecture

External access token internal JWT token

  • Cons: Still rely on gateway to switch access token with JWT token.

first arch

Encrypted JWT token

  • Pros: Stateless token

second arch

External access token internal JWT token with token cache

  • Most widely used in practice

third arch

There aren't any published security advisories