System Design

How would you build a simple version of Identity Access Management?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 11 min read

How would you build a simple version of Identity Access Management? With five parts: a user store of salted password hashes, a login endpoint issuing signed tokens, role policies, an allow-or-deny check and an audit log. The mistake that costs the point is in the check: what the system does when one policy allows a request and another denies it.

In this article

Before you start
Why interviewers ask this
Identity and access management from first principles
The Staff-level answer
The rubric
Three variants of this question
Common mistakes
Follow-up questions
Sources

Before you start

This question sits in the distributed systems interview round, where you design a small service out loud.

Why interviewers ask this

The question is open on purpose, so the first thing a weak answer shows is a list of buzzwords: "OAuth, signed tokens, roles, multi-factor login." Interviewers use it to see whether a candidate can pick the smallest design that is still safe, and whether the candidate knows where security systems fail in practice: password storage, the default when no rule matches, and tokens that cannot be taken back.

A weak answer names tools without saying what each one protects. A strong answer separates proving who someone is from deciding what they may do, stores passwords in a form that survives a stolen database, and states the default decision. A Staff-level answer also says what the simple version leaves out and which gap hurts first. Candidates report this question in system design rounds; no company is named here because no public source ties it to one.

Identity and access management from first principles

Identity and Access Management: Identity and Access Management (IAM) is a service that records who users are, checks that a caller really is that user, and decides which actions that user may perform on which resources, so every other service can rely on one source of truth.
Authentication: Authentication is the step that proves who a caller is, for example by checking a password against a stored hash, and that ends with a verified identity such as a user id.
Authorization: Authorization is the step that decides whether a verified identity may perform one action on one resource, and that ends with allow or deny.
Policy: A policy is a rule that says a set of actions on a set of resources is allowed or denied, and it is attached to a user or to a role, which is a named bundle of permissions.

In plain words

Think of an office building. At the front desk a guard checks your badge photo against a register. That is authentication. Each door then has a list of who may enter. That is authorization. The analogy breaks in one place. An office door is usually open to staff by default. In a safe IAM design every door is locked until a rule opens it.

In one precise sentence, a simple IAM stores credentials, verifies them once to issue a signed token, and then checks policies on every request. It denies unless a policy allows and no policy forbids. Each of the four steps below adds one part of that sentence, so you can build the system in the order you would explain it out loud.

Step 1: Store users and verify passwords with a slow, salted hash

The user store is a table with a user id, a login name and a password hash. The server never stores the password. It stores the output of a password hashing function plus a random value called a salt, which is unique per user. The OWASP Application Security Verification Standard (ASVS) 4.0.3, requirement V2.4.1, says passwords are salted and hashed with an approved one-way function that takes a password, a salt and a cost factor.

The cost factor makes each guess slow. For the Password-Based Key Derivation Function 2 (PBKDF2), the same standard says the iteration count should be as large as the server allows, typically at least 100,000 (ASVS V2.4.3). Input: login name and password. Output: a verified user id, or a generic failure. At login the server hashes the typed password with the stored salt and compares. You now know how identity is proved; next comes what that identity may do.

Step 2: Policies decide, and an explicit deny beats any allow

The authorization check takes three inputs, the principal (who), the action and the resource, and returns allow or deny. Policies are statements of the form effect, actions, resources, attached to roles. The rule that matters is the default. In the Amazon Web Services (AWS) IAM User Guide, by default all requests are denied, and if a single policy contains a denied action, IAM denies the whole request and stops evaluating.

Copy that model. Collect the policies that apply, return deny if any deny statement matches, return allow if an allow statement matches, and otherwise return deny. In the worked policy, an editor has allow on doc:* for doc/* and a deny on doc:delete for doc/legal/*. Reading doc/plan is allowed, deleting doc/plan is allowed, deleting doc/legal/nda is an explicit deny, and reading billing:read on invoice/7 is a default deny because no policy mentions it.¹

An explicit deny beats a matching allow, and a request no policy mentions is denied.CC BY 4.0 — source: How would you build a simple version of Identity Access Management?

Text description of the diagram

Reading doc/plan is allowed by the allow on doc:*.
Deleting doc/legal/nda is an explicit deny.
A billing request that no policy mentions is a default deny.

Step 3: Carry the identity in a signed token

After a good login the server returns a token so the user does not send a password again. The token is called JavaScript Object Notation (JSON) Web Token (JWT). A JSON Web Token is a compact, URL-safe way of representing claims to be transferred between two parties (Request for Comments (RFC) 7519), such as the user id and roles. It can be verified because it is digitally signed, with a shared secret or with a public and private key pair (jwt.io).

Signing proves who issued the token and that it was not changed. It does not hide the contents, because only the separate encrypted form keeps claims secret (RFC 7519). So put no secrets in claims. With a key pair, any service holding the public key can verify a token without calling the user store. A sample token with a user id, one role and an expiry is 216 characters when signed with the Elliptic Curve Digital Signature Algorithm (ES256) and 173 characters when signed with a keyed hash (HS256) (illustrative claims).¹ Give tokens a short expiry time.

Step 4: Write an audit log of every decision

An audit log is an append-only record of who tried which action on which resource and what the decision was. It is how you answer "who deleted this?" and how you notice a stolen account. Log the principal, action, resource, decision, the reason (explicit deny, allow, default deny) and a time. Never log passwords or full tokens.

The log is also the largest thing the simple design stores. At 1,000 requests a second and 200 bytes an entry (both illustrative), it grows by 17.28 GB a day, so decide early how long you keep it.¹ You now have the whole system. Sizing it is the habit taught in back-of-the-envelope estimation.

Identity is proved once at login, then every request is checked against policies and logged.CC BY 4.0 — source: How would you build a simple version of Identity Access Management?

Step-by-step description

Login checks a salted, slow password hash.
The access check denies by default.
A signed token carries the identity.
Every decision is written down.

Login checks the password hash in the user store.
The access check reads policies and denies by default.
A signed token carries the user identity to the check.
The check writes every decision to an audit log.

What the numbers say about capacity

Take 1,000,000 accounts (illustrative). A hash record of about 100 bytes each is 100 MB of user store, small enough for one ordinary database; see database interview questions. If 20% log in daily, that is 200,000 logins a day, about 2.31 a second on average and 23.1 at a peak ten times the average. A deliberately slow hash of 100 milliseconds (illustrative; measure your own) occupies one processor core per 10 logins a second, so peak login needs 3 cores.¹ Per-request checks are cheap because they use the token and the in-memory policies, not the password hash. That is why login capacity and request capacity are sized separately.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.