IAM (Identity and Access Management) – A Complete Guide

Uncategorized
Posted on | by rajeshkumar

There are 2 PEOPLE who wants to consume IAM

  • Human to Service
  • Service to Service

What is Identity in IAM?

In IAM, an identity represents a person, a system, or a service that needs access to resources.

Think of identity as the digital profile that IAM uses to know who is asking for access.

Examples of Identities in IAM

  • Human users → employees, admins, customers
  • Non-human users → applications, APIs, servers, bots
  • Groups / Roles → collections of users with similar permissions

Why is Identity Important in IAM?

  1. Authentication (Who are you?)
    The system checks your identity (username, certificate, API key, etc.).
    Example: Rajesh logs in with his company email + password.
  2. Authorization (What can you do?)
    Once identity is confirmed, IAM decides what resources you can access.
    Example: Rajesh can view reports but cannot delete databases.

Real-World Analogy

  • Identity = Your company badge with your name & photo.
  • Authentication = Security guard scanning the badge to confirm it’s real.
  • Authorization = Deciding which office rooms your badge can open.

👉 In short:
In IAM, identity is the digital representation of a user or service. It’s the “who” in the system, used as the foundation for authentication and authorization.

Let’s break down the main components of Identity and Access Management (IAM) in a simple and structured way.

🔑 Core Components of IAM

1. Identity

  • Definition: The digital representation of a person, group, or system.
  • Examples: Users, service accounts, roles, groups.
  • Purpose: Establishes who is trying to access resources.

2. Authentication

  • Definition: Verifying that an identity is genuine.
  • Examples: Passwords, OTP, biometrics (fingerprint, face ID), security tokens, certificates.
  • Purpose: Confirms you are who you claim to be.

3. Authorization

  • Definition: Defining what authenticated identities are allowed to do.
  • Examples: RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control), policies.
  • Purpose: Ensures you have the right permissions for the requested resource.

4. User Management & Lifecycle

  • Definition: Processes for creating, updating, disabling, and deleting user accounts.
  • Examples: Onboarding new employees, offboarding exiting staff, updating roles when someone gets promoted.
  • Purpose: Keeps access clean, secure, and up-to-date.

5. Access Management

  • Definition: Enforcing rules on how identities gain access to systems/resources.
  • Examples: Single Sign-On (SSO), MFA (Multi-Factor Authentication), Just-In-Time access.
  • Purpose: Securely manages how users log in and access multiple apps.

6. Directory Services

  • Definition: Central repositories storing identity data.
  • Examples: Active Directory (AD), LDAP directories, AWS IAM directory.
  • Purpose: Acts as the “phonebook” of users, groups, and policies.

7. Governance & Compliance

  • Definition: Policies, monitoring, and audits to ensure proper use of IAM.
  • Examples: Access reviews, role audits, segregation of duties.
  • Purpose: Ensures organizations follow regulations (GDPR, HIPAA, ISO, SOC2, etc.).

8. Monitoring & Reporting

  • Definition: Tracking and analyzing identity-related activities.
  • Examples: Audit logs, SIEM alerts, unusual login detection.
  • Purpose: Detects threats, prevents misuse, and ensures accountability.

🏗️ Quick Analogy

Imagine a secure office building:

  • Identity = Employee badge with your name.
  • Authentication = Security guard scans the badge.
  • Authorization = Badge opens only specific floors/rooms.
  • User Lifecycle = Badge created when you join, disabled when you leave.
  • Access Management = One badge works for all company doors (SSO).
  • Directory = Employee database with all roles.
  • Governance = Regular audits of who has access to which rooms.
  • Monitoring = Security cameras & logs tracking who entered where.

How Login Session Work with Flow (Human User)

🔑 Login Session Flow (Human User Using Browser)

1. User Enters Credentials

  • You type your username/email and password on the login page.
  • Sometimes extra security is added (OTP, fingerprint, etc.).

2. Website Checks Credentials

  • The website’s server looks up your identity in its database.
  • If the password (after hashing) matches, it says: ✅ You are who you claim to be.

3. Session/Token is Created

  • The server creates a session record (like a visitor badge).
  • This contains your user ID, login time, and permissions.
  • The server generates a random session ID/token that points to this record.

4. Token is Sent to Browser

  • The session ID/token is stored in your browser cookie (or local storage if it’s token-based).
  • Example: Set-Cookie: session_id=abc123; Secure; HttpOnly

5. Browser Reuses Token

  • For every new click or page you open, your browser automatically sends the token back.
  • The website checks: Is this session still valid? If yes → it lets you continue without logging in again.

6. Authorization (What You Can Do)

  • Based on your identity, the server decides:
    • Normal user → can view content
    • Admin → can also edit or delete

7. Session Timeout

  • If you stay idle too long (say 30 min), the session expires.
  • You’ll need to log in again.

8. Logout

  • When you click logout:
    • The website deletes the session from its server.
    • Your browser cookie/token is cleared.
  • Now, even if someone steals your old token, it won’t work.

🏢 Real-Life Analogy

  • Login = Showing your ID card at building security
  • Session token = Visitor badge given to you
  • Cookie in browser = You keep wearing the badge
  • Authorization = Which rooms your badge opens
  • Logout/Expire = Badge deactivated, you must check in again

👉 In short:
When you log in, the website verifies your identity, gives your browser a session token, and then uses that token to recognize you on every request until you log out or it expires.

How Service A authenticates to Service B?

Alright 👍 Let’s make it super simple — how Service A authenticates to Service B.

Step-by-Step (Simple Words)

1. Service A needs to call Service B

Example: Payment service (A) needs to call Order service (B).

2. Service A gets a “token”

  • Service A asks a trusted Identity Provider (IdP) (like Keycloak, AWS IAM, Azure AD).
  • IdP checks who Service A is (using a secret, certificate, or workload identity).
  • IdP gives Service A a token (like a signed digital badge).

3. Service A sends a request with the token

GET /orders
Host: service-b.example.com
Authorization: Bearer <token>
Code language: HTML, XML (xml)

4. Service B receives the request

  • Service B looks at the token in the request.
  • It checks:
    • Is the token real (signature valid)?
    • Is it still valid (not expired)?
    • Is it really meant for Service B (audience claim)?
    • What permissions does it give (scopes/roles)?

5. Service B decides

  • If all checks pass → Service B trusts Service A and serves the request.
  • If not → Service B rejects (401 Unauthorized).

6. Token refresh

  • Tokens usually expire quickly (5–15 min).
  • Service A must ask the IdP for a new token before calling again.

🔑 Analogy

  • Service A = Delivery driver 🚚
  • IdP = Security office 🛡️ (gives a visitor pass).
  • Token = Visitor pass 🎟️ (signed, valid for a short time).
  • Service B = Warehouse 🏭 (only lets in drivers with a valid pass).

👉 In short:
Service A proves who it is by getting a token from a trusted authority, then shows that token to Service B. Service B checks the token before allowing access.

Do you want me to explain this again with a real-life example using JWT claims (like iss, aud, exp, scope) so you see exactly what’s inside the token Service A shows to Service B?

Where Laravel/Passport concepts map (still conceptual)

Great, let’s keep it purely conceptual and Laravel-flavored with Passport as the identity server.

Think of the three apps like this:

  • ServiceA (Identity): Your Authorization Server (issues OAuth2 access/ID tokens; holds the user login session).
  • ServiceB and ServiceC: Separate Laravel apps that are both OAuth2 Clients (to ask for tokens) and Resource Servers (to protect their own APIs). They trust tokens minted by ServiceA.

Core ideas (in Passport terms)

  • One login place: Users authenticate only at ServiceA.
  • Tokens, not passwords: ServiceA issues access tokens (JWT) carrying scopes/claims.
  • Trust via keys: B and C validate those tokens using ServiceA’s public key (so they never need to know user passwords).
  • Scopes/audience: Tokens carry what the caller can do (e.g., servicec.read) and who they’re meant for (conceptually “audience = ServiceC”).
  • Sessions vs tokens:
    • Browser “logged in” = session cookie inside each app (B or C).
    • API calls between apps = Bearer token issued by A.

Q1) “User authenticates using ServiceB—how does B also get access to ServiceC?”

This is the user-delegated scenario. Flow at a high level:

  1. User hits a protected page on B.
    B sees “no user” and redirects to ServiceA (OAuth Authorization Code flow, typically with PKCE).
  2. User logs in at ServiceA.
    ServiceA now has a user session (at A). It redirects back to B with a one-time authorization code.
  3. B exchanges that code (server-side) with A for tokens:
    • ID token (who the user is),
    • Access token (what the user can access), possibly a refresh token.
      B validates and then creates a Laravel session for the browser (so page views on B don’t need to carry the access token).
  4. B needs data from C. Two clean patterns:
    • Propagate the user’s token: If the access token already contains scopes good for C (e.g., servicec.read) and C is configured to accept tokens from A, B calls C with Authorization: Bearer <that token>.
      C validates the token (signature, expiry, issuer, required scopes) and serves the request.
    • Least-privilege “retargeting” (token exchange concept): B asks A for a new access token specifically for C with only the scopes C needs (e.g., servicec.read). Then B calls C with this C-scoped token.
      (Passport doesn’t ship IETF Token Exchange out of the box; conceptually, you model this by asking A for the right scopes destined for C and having C enforce them.)
  5. C authorizes based on the token’s scopes/claims and returns data to B.

Mental model:

  • The browser talks to B with a session cookie.
  • B talks to C with a Bearer token from A.
  • C trusts only A’s tokens and its required scopes.

Q2) “How does logging in once (at ServiceA) log the user into all services?”

This is SSO via the identity server’s session:

  1. First app (say B):
    The first time the user encounters a protected page on B, B redirects them to A. The user enters credentials at A. Now A holds a login session for that browser.
  2. Second app (C):
    Later, the user visits C. C also redirects to A (same OIDC/OAuth flow). But the user is already logged in at A, so A doesn’t prompt again—it immediately issues a fresh authorization code back to C, and C exchanges it for tokens.
    Result: the user appears “auto-logged-in” at C without re-entering credentials.
  3. Local sessions per app:
    Each app (B, C) still creates its own Laravel session after receiving tokens. That’s why navigating within each app feels logged-in. The “single” part of SSO comes from the central session at A that silently re-authenticates apps on demand.
  4. Logout reality check:
    • Logging out of B clears B’s session. To make it feel like a global logout, B should also send the browser to ServiceA’s logout.
    • If A’s session is closed, the next time the user hits any app (B or C), they’ll be redirected to A and asked to log in again.
    • Without coordinated back-channel logout, already-open apps won’t instantly know the user logged out elsewhere. Most teams accept “logout at app + logout at A” as practical SSO.

Where Laravel/Passport concepts map (still conceptual)

  • ServiceA (Passport server):
    Holds users, login UI, and issues tokens. Maintains the central SSO session in the browser.
  • ServiceB/ServiceC (clients + resource servers):
    • As clients: redirect to A when unauthenticated; exchange the authorization code for tokens; create a local Laravel session.
    • As resource servers: protect APIs by validating Bearer tokens from A (signature, issuer, expiry, scopes).
  • Scopes / claims:
    Use scopes to represent permissions that C enforces (e.g., servicec.read, servicec.write). B requests only what it needs.
  • Token lifetimes:
    Keep access tokens short-lived (minutes). The browser experience remains smooth because the SSO session at A can mint fresh tokens without re-prompting the user.
  • Trust:
    B and C never share passwords or sessions with each other. They only trust tokens minted by A and their own local sessions.

Quick chooser

  • User viewing B ◀︎▶︎ B needs C’s data:
    B uses A-issued token to call C (propagate or “retarget” to least privilege).
  • User lands on C first:
    C also redirects to A; A’s existing session makes it seamless SSO.
  • Background/cron/no user:
    Use client credentials from A for B→C calls (represents B itself, not a user).

That’s the big picture: ServiceA is the single source of truth (login + tokens), B and C trust A, and SSO happens because A keeps the only real login session and reissues tokens to any app that asks.

Great question—keeping it 100% conceptual and Passport-flavored.

Who creates “clients” and where?

Short answer

  • Create all OAuth clients in ServiceA (the Identity/Authorization Server).
  • ServiceB and ServiceC do not create OAuth clients locally (unless they themselves need to call other services as a client—then they get a client entry in ServiceA too).
  • ServiceB/C just use those clients (by configuring the client_id/secret and ServiceA URLs in their app settings) and validate tokens issued by ServiceA.

What “client” entries do you need in ServiceA?

Think in terms of who needs a token from A and for what flow:

  1. Browser login to B (or C) → Authorization Code client (for each UI app)
    • Create one client for ServiceB’s web/UI in ServiceA (with B’s redirect URI).
    • If ServiceC also has a user-facing UI, create one client for ServiceC’s web/UI (with C’s redirect URI).
    • Purpose: lets each app redirect users to A and get back tokens (SSO).
  2. B calls C without a user (cron/background/webhook) → Client Credentials client (for B)
    • Create one machine client for ServiceB in ServiceA with client credentials enabled.
    • Purpose: gives B a “service identity” to fetch access tokens from A to call C.

If C ever calls something else as a backend, C gets its own client credentials client in ServiceA as well.

Where do these go (conceptually “inserted”)?

  • ServiceA (Identity)
    • You register the clients (above) in ServiceA’s Passport (i.e., entries in oauth_clients with names, secrets, and redirect URIs for UI apps).
    • You also define scopes/permissions that APIs (like C) will enforce (e.g., servicec.read, servicec.write).
    • ServiceA holds the user login session (this is what makes SSO feel “single”).
  • ServiceB / ServiceC (Apps/APIs)
    • As OAuth Clients: they configure the client_id/secret that you created in ServiceA (plus ServiceA’s auth/token endpoints and their own redirect URI). They don’t create clients locally; they just reference the ones created in A.
    • As Resource Servers: they validate Bearer tokens that came from ServiceA (signature, issuer, expiry, scopes). No “client” is created here for validation; they just trust ServiceA’s public key and enforce scopes.

How does this answer your two scenarios?

1) “User authenticates using ServiceB and also gets access to ServiceC?”

  • User hits B → B uses its Authorization Code client (in A) → user logs in at A → A issues tokens → B creates a local session.
  • When B calls C:
    • With user context: B presents a token from A that C accepts (either the same user token with proper scopes, or a token specifically “targeted” for C requested from A).
    • C trusts A, checks scopes, serves the request.
  • All the client definitions that make this possible live in A.

2) “Login with ServiceA once, then login to all services”

  • First app (B) redirects to A, user logs in, A keeps a session.
  • Second app (C) also redirects to A using its own Authorization Code client; because the user already has a session at A, A immediately issues tokens—no second password prompt.
  • Again, this works because both B and C are registered as clients in A and both redirect to the same identity session at A.

Mental checklist

  • In ServiceA (Passport):
    • Create Authorization Code client for B UI (+ redirect URI of B).
    • Create Authorization Code client for C UI (if it has UI) (+ redirect URI of C).
    • Create Client Credentials client for B (if B calls C without a user).
    • Define scopes that C will enforce.
  • In ServiceB/C apps:
    • Configure to use those clients (client_id/secret, endpoints, redirect URI).
    • Protect APIs by validating tokens from A and enforcing scopes.

That’s it: all client registrations live in ServiceA; ServiceB/C only reference them and validate A’s tokens.

Leave a Reply

Your email address will not be published. Required fields are marked *