Low Level Design: Identity Service – Tech Interview Dot Org

What Is an Identity Service?

An Identity Service handles authentication and authorization: it answers the questions “who are you?” (authn) and “what are you allowed to do?” (authz). It manages credentials, issues tokens, and enforces session policy. It is deliberately separate from the User Profile Service, which stores descriptive data, and from downstream services, which enforce business rules. Keeping identity isolated limits the blast radius of a credential compromise.

Data Model / Schema

TABLE identities (
  identity_id    UUID          PRIMARY KEY,
  user_id        UUID          NOT NULL,        -- FK to profile service
  provider       ENUM('local','google','github','saml') NOT NULL,
  provider_uid   VARCHAR(256)  NOT NULL,        -- external subject ID
  email          VARCHAR(256)  NOT NULL,
  pw_hash        VARCHAR(256),                  -- bcrypt, local only
  mfa_secret     TEXT,                          -- TOTP seed, encrypted
  status         ENUM('active','locked','disabled') DEFAULT 'active',
  last_login_at  TIMESTAMP,
  created_at     TIMESTAMP     NOT NULL DEFAULT NOW(),
  UNIQUE (provider, provider_uid)
);

TABLE refresh_tokens (
  token_hash     VARCHAR(128)  PRIMARY KEY,     -- SHA-256 of raw token
  user_id        UUID          NOT NULL,
  device_id      VARCHAR(128),
  issued_at      TIMESTAMP     NOT NULL DEFAULT NOW(),
  expires_at     TIMESTAMP     NOT NULL,
  revoked        BOOLEAN       DEFAULT FALSE
);

TABLE login_attempts (
  id             BIGSERIAL     PRIMARY KEY,
  identity_id    UUID,
  ip_address     INET,
  user_agent     TEXT,
  success        BOOLEAN,
  attempted_at   TIMESTAMP     DEFAULT NOW()
);

Core Algorithm: Authentication Flow

login(email, password, mfa_code):
  identity = db.query("SELECT * FROM identities WHERE email = ? AND provider = 'local'", email)
  if not identity OR identity.status != 'active':
    log_attempt(identity, success=false)
    return 401

  if rate_limit_exceeded(identity.identity_id, ip):
    return 429

  if not bcrypt.verify(password, identity.pw_hash):
    log_attempt(identity, success=false)
    increment_lockout_counter(identity.identity_id)
    return 401

  if identity.mfa_secret:
    if not totp.verify(mfa_code, identity.mfa_secret):
      return 401

  access_token  = jwt.sign({sub: identity.user_id, exp: now+15m}, private_key)
  refresh_token = crypto.random_bytes(32)
  store_refresh_token(hash(refresh_token), identity.user_id)
  log_attempt(identity, success=true)
  return {access_token, refresh_token}

Access tokens are short-lived (15 minutes) and stateless JWTs signed with RS256. Refresh tokens are long-lived (30 days), stored hashed in the DB, and rotated on each use (refresh token rotation).

OAuth / SSO Flow

For social login, the service acts as an OAuth 2.0 relying party. On callback, it exchanges the authorization code for an ID token, validates the token signature against the provider's JWKS endpoint, extracts the sub claim as provider_uid, and upserts a row in identities. If the email matches an existing local identity, the accounts are linked.

Privacy, Security, and Compliance

Password hashing: bcrypt with cost factor 12. Never store plaintext or reversible hashes.
MFA seed encryption: TOTP seeds are encrypted with a KMS-managed key before storage. The service decrypts on demand; the seed never leaves the service boundary.
Brute-force protection: After 5 consecutive failed attempts, the identity is soft-locked for 15 minutes. Persistent failures trigger admin review.
Token revocation: Refresh tokens are stored hashed. Logout and password-change flows mark all tokens for a user as revoked. Access tokens are stateless but short-lived, limiting the revocation gap.
Audit trail: All login attempts (success and failure) are appended to login_attempts. This table is write-once from the service role.

Scalability Considerations

Stateless access tokens: JWTs allow downstream services to validate tokens without calling the identity service on every request, eliminating a synchronous bottleneck.
Read scaling: Token validation is fully distributed. Only token issuance and refresh require a DB write.
JWKS caching: Downstream services cache the public key set and refresh it periodically, avoiding per-request key fetches.
Session store: If revocation must be near-real-time, maintain a Redis revocation list keyed by token JTI. Check this list on validation for sensitive operations.

Summary

An Identity Service is security-critical infrastructure. The critical design choices are: short-lived stateless JWTs for scalable authz, hashed refresh tokens with rotation for session security, bcrypt for credential storage, and a full audit log for compliance. In interviews, be ready to discuss the tradeoff between access token TTL (shorter is more secure, longer reduces token refresh traffic) and real-time revocation strategies.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “What does an Identity Service do in a distributed system?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “An Identity Service handles authentication and authorization across a distributed system. It issues and validates tokens such as JWTs or OAuth 2.0 access tokens, manages sessions, and provides a centralized mechanism for verifying who a user is and what they are permitted to do.”
}
},
{
“@type”: “Question”,
“name”: “How do you design an Identity Service for high availability?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “High availability for an Identity Service is achieved by deploying stateless token-validation nodes behind a load balancer, replicating the credential store across multiple availability zones, using distributed caches for session lookup, and implementing circuit breakers to prevent cascading failures when the service is under load.”
}
},
{
“@type”: “Question”,
“name”: “What is the difference between authentication and authorization in an Identity Service?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Authentication verifies the identity of a user, typically via credentials, biometrics, or SSO tokens. Authorization determines what resources or actions that verified identity is allowed to access, usually enforced through role-based access control (RBAC) or attribute-based access control (ABAC) policies managed by the Identity Service.”
}
},
{
“@type”: “Question”,
“name”: “How is an Identity Service evaluated in system design interviews at Google or Amazon?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Interviewers at Google and Amazon assess an Identity Service design on token lifecycle management (issuance, refresh, revocation), secure storage of credentials, support for multi-factor authentication, integration with federated identity providers via SAML or OIDC, and the latency impact of auth checks on downstream services.”
}
}
]
}