Ok. If you’ve ever Googled “IAM architecture,” you’ve seen the diagram. Twelve vendor logos in boxes, arrows going everywhere, and a cloud labeled “Zero Trust” floating over the whole thing like it means something.
The problem tends to be that those diagrams are useless marketing fluff. It shows you products, not what reflects a real enterprise environment.
Before we go into this, there’s a few things we should get stright.
- The only rule in identity is that there’s an exemption to every rule.
- In my opinion, the best way to look at identity architecture isn’t through tools. It’s through questions.
- See rule 1.
This set of questions your organization has to answer doesn’t ( or at least shouldn’t) come out of the blue. It’s usually based off of some sort of framework. Think NIST, CIS-18, HIPAA, SOX, FedRamp, etc. These lay the foundations for what you build off of. Becasue every organization is different, not 2 architectures sre the same. If you stary by getting the questions straight, the tools sort themselves out. Start with the tools and you’ll spend three years untangling a mess (ask me how I know).
Bias check: I work at Okta, so I live in this world daily. I’m going to stay vendor-neutral here, because the concepts are the same whichever logo you end up buying.
Every IAM Architecture Answers Four Questions
Strip away the marketing and every IAM program, from a 20-person startup to a bank, starts by answering the same four questions:
- Who are you? Identity. Somewhere, there’s a record that says this person or thing exists.
- Prove it. Authentication. Show me something that proves you are that record.
- What are you allowed to do? Authorization. Now that I know who you are, what can you do?
- Who’s keeping score? Governance. Is that access still right, and can we prove it to an auditor?
That’s it. Those are your four basic layers. Everything else, every acronym you’ll ever see, lives inside one of them.
The mistake beginners make is collapsing them. “We have SSO, so we’re done with IAM.” No. You answered question two. Congrats, but there are three more.
Layer 1: Pick a Source of Truth (and Freaking Mean It)
Before anyone logs into anything, you need to know who exists. That sounds obvious, but it is not, in fact, obvious.
In most companies, the real source of truth for employees is or should be the HR system (Workday, SuccessFactors, whatever payroll runs on). This is because HR knows first when someone is hired, when they change departments, and when they leave. Your identity architecture should always listen to HR.
From there, identities usually flow into some sort of a directory: e.g. Active Directory, Entra ID, an LDAP server, or some other user store. The directory should only hold the attributes everything downstream cares about like name, email, department, manager, employment status, etc.
The flow you’re designing here actually has a name. We call it your JML flow or joiner, mover, leaver.
- Joiner: New hire shows up in HR, an account gets created automatically.
- Mover: Someone changes roles, their attributes update and their access should follow.
- Leaver: Someone leaves, their accounts get disabled. Today. Not next quarter.
From the directory, there’s a few ways to push the changes out to applications. The simplified way (depending on your application, IdP, and a myriad of other things) is via a connector. Outside of that, the industry largely relies on something called SCIM (System for Cross-domain Identity Management). SCIM is a provisioning standard, so in short it creates, updates, and deactivates accounts in downstream apps. Note that it is not an authentication protocol, and it doesn’t log anyone in, it just creates, modifies, and deletes accounts.
My personal take here is that if you can’t answer “where does this identity come from?” in one sentence, stop buying tools and fix this first. Every other layer will inherit your data quality problems. This is your foundation that you build on, so it’s best to get it right the first time.
Layer 2: Authentication Lives In One Centralized Place
The single most important architectural decision in Workforce IAM: applications should not check passwords. This is the entire idea behind SSO.
So. Your apps should not verify credentials, they instead should hand the user off to the IdP. The IdP does the hard work (password, MFA, device checks, risk signals, etc), then the IdP hands back something that says “yep, this is Sarah, and here’s how sure I am.”
The key here is trust. The app trusts the IdP, the IdP trusts the directory. That chain of trust is what we call federation, and it’s the reason Single Sign-On works.
Two protocols do 99% of the federation work you’ll see:
- SAML 2.0: XML-based, older, but still everywhere in enterprise SaaS. It’s not going anywhere, no matter how many people want it gone.
- OpenID Connect (OIDC): JSON and JWT-based, built on top of OAuth 2.0. This is what you’ll usually use for anything modern: web apps, mobile apps, APIs.
Inside the IdP is where you set up all your MFA policies, SSO policies, user directory connectors, flows, etc..
The beginner trap here is thinking authentication is the whole job. Authentication just tells you who someone is. It says nothing about what they should be allowed to do once they’re in.
Layer 3: Authorization Is Where It Starts To Get Hard
Authorization happens at two altitudes:
- Coarse-grained: Can Sarah open the finance app at all? Usually decided at the IdP or gateway, often from group membership.
- Fine-grained: Can Sarah approve this invoice, over this amount, for this cost center? Decided inside or right next to the application.
You tend to hear three models for making those decisions:
- RBAC (role-based): Access comes from roles. “Finance Analyst” gets these permissions. Simple, auditable, and prone to role explosion once you have 4,000 roles nobody understands.
- ABAC (attribute-based): Access comes from attributes and rules. Department, location, time of day, data classification. More flexible, but harder to reason about.
- ReBAC (relationship-based): Access comes from relationships. You can edit this doc because you own the folder it’s in. This is the Google Zanzibar model that is driving the dynamic authorization of Ai agents all over the world right now. hint hint. Look up OpenFGA.
Which one you use depends largely on the organizations risk apetite and the data they’re trying to protect in that system. That being the case, you usually see a mix of all 3 in most organizations.
The architectural pattern worth learning early if you want to impress your peers with your ‘super deep’ knowledge of authorization architecture is to separate the Policy Decision Point (PDP, the thing that decides yes or no) from the Policy Enforcement Point (PEP, the thing that actually blocks or allows the request).
The reason I recommend this is that when every app hardcodes its own permission logic, you can’t change policy without a new code deployment and you can’t answer “who can access what” without reading source code. If you pull the decision out now, your future self will thank you. The PDP in large and scaleable organizations tends to be the IdP, while the PEP lives in the application.
Layer 4: Governance, or Why Access Rots
Access doesn’t stay correct forever, it tends to drift.
Some of the more common examples I see are someone moving from support to sales and keeping their support admin rights, a contractor’s project ended and nobody told IT and three freaking years later that account is still active and has never been reviewed.
I like to call this is the Jurassic Park problem. Dennis Nedry had access to everything, nobody was checking, and one disgruntled insider took the whole park offline. (Also, you know, the dinosaurs. But mostly the access model.)
Governance is the layer that catches drift:
- Access reviews (certifications): Managers periodically confirm their people still need what they have. Yes, everyone hates them. Until there’s a better way to do them, do them anyway, and make them smaller and smarter instead of a 900-line spreadsheet people just rubber-stamp. (We call this approval fatigue btw.)
- Least privilege: Grant the minimum access needed and prefer just-in-time (JIT) access that expires over standing access that lives forever.
- Privileged access management (PAM): Admin and root-level accounts get extra scrutiny by way of vaulted credentials, session recording, and approval workflows.
- Audit logging: Every authentication and authorization decision gets logged somewhere and seen by the SOC.
This layer is where IAM meets compliance (SOX, HIPAA, SOC 2, and friends). It’s also the layer beginners skip, because it’s complex and can be a pain to maintain of not architected properly. Don’t skip it.
Putting It Together: One Employee, Start to Finish
Concepts are nice, but it helps to put it all together to see how a good architecture would actually work.
- Day -60-0. Sarah is hired. HR creates her record and sets a start date. On the start date, the directory picks it up and creates her identity with her department and manager.
- Day 1. SCIM provisions her accounts in Slack, email, and the finance app. Nobody has to file a ticket.
- Day 1, 9:02am. Sarah opens the finance app. It redirects her to the IdP. She signs in with a passkey, the IdP sends back an OIDC token, and she’s in.
- Day 1, 9:05am. She tries to approve an invoice, so the app asks the policy engine. Answer: go pound sand, she’s an analyst, not an approver.
- Day 180. Her manager gets an access review. They confirm her access is still correct.
- Day 400. Sarah moves to marketing. HR updates her department, the finance access is removed and the marketing access is added automatically.
- Day 900. Sarah leaves, so HR marks her terminated. Her IdP session is revoked and every downstream account is deactivated within seconds.
Every step maps to a layer. If any step in your organization involves a spreadsheet, an email to IT, or the phrase “we’ll get to it,” you’ve found where your architecture needs work.