Identity and Access Management (IAM)

Concept · Chapter 11

What It Is

IAM = policies and tools for managing digital identities and controlling access to information and functionality. Two fundamentals: authentication and authorization.

Authentication

• Determining that a subject (user, service, computer, application) is who/what it claims to be — validating identity.
• Historically each app kept its own user profiles (identifier + password).

Multi-factor authentication (MFA)

Requires two or more authentication factors (exactly two = 2FA):

Factor	Meaning	Examples
Knowledge	Something you know	Password, PIN
Possession	Something you have	Phone receiving a code, swipe card
Inherence	Something you are	Fingerprint, retina/palm scan, biometrics

MFA forces an attacker to compromise multiple factors (e.g. password and the user’s phone).

Authorization

• Determining what an authenticated subject may do and which resources it may access.
• Consider privilege granularity: coarse-grained privileges grant too much; split into fine-grained privileges for better access control (see least privilege).

Password Storage — Evolution

Approach	Verdict
Plaintext	Anti-pattern — any DB breach exposes all passwords.
Encrypted	Reversible; if the key or a decrypted value leaks, passwords are compromised. Don’t use encryption for passwords.
Hashed	One-way (see cryptographic hash functions); must use an unbroken function. But bare hashes fall to dictionary attacks and rainbow tables.
Salted hash	Hash password + a per-password random salt (e.g. 64-bit) with a slow function (Argon2, scrypt, bcrypt, PBKDF2). Defeats rainbow tables. Still common today.

Salted-hash flow: at registration, hash(password + salt) and store it; at login, hash the entered password with the salt and compare.

Centralizing Authentication

• Domain authentication — enterprises centralize auth in a domain controller (DC) + directory service (e.g. Active Directory). Works well for intranet apps within one network.
• Centralized identity provider (IdP) — modern apps call APIs across domains, so domain auth isn’t enough. An IdP grants cross-application access without sharing login credentials, and removes auth responsibility from each app. Registration, password policies/changes, and lockouts live in one reusable, maintainable place.

OAuth 2 / OpenID Connect (OIDC)

• OAuth 2 — open standard for authorization; lets an app be granted access to another app’s resources.
• OIDC — an identity layer on top of OAuth 2 to verify an end-user’s identity.

OAuth 2 roles

• Resource owner — owns the resource whose access is controlled.
• Resource server — hosts the resources (e.g. an API).
• Client — the app requesting the resource.
• Authorization server — authorizes the client (can be the same as the resource server; separate for larger apps).

Authentication flow (relying party)

The client (the relying party) redirects to the authorization server’s authorization endpoint; if the user authenticates, the IdP redirects back with an authorization code and an identity token (a JWT), stored in web storage or a cookie.

JSON Web Token (JWT)

Open standard for representing claims between two parties; lightweight. Three dot-separated parts:

• Header — token type and hashing algorithm (e.g. HMAC SHA256); Base64Url encoded.
• Payload — the claims (statements about the subject), Base64Url encoded. Three claim types:
  • Registered — predefined, optional: iss (issuer), sub (subject), aud (audience), jti (token id), iat (issued at), exp (expiration).
  • Public — self-defined, should use a namespaced URI to avoid collisions.
  • Private — custom claims two parties agree on.
• Signature — hash of encoded header + encoded payload + secret key, using the header’s algorithm; guarantees the token wasn’t altered and (with a secret key) verifies the sender.

Authorization flow

After authentication, the client sends a token request (client ID + client secret + authorization code) to the token endpoint and receives an access token (commonly a JWT). Access tokens can be revoked, scoped, and time-limited. The client uses it to request the resource; the resource server validates it and returns data.

Related

• Weak auth/session handling appears as broken authentication.
• Cross-domain identity is common in microservice architectures.

Citations

• Software Architect’s Handbook (Packt, 2018), Ch.11 “Identity and access management (IAM)”, pp. 874-891.