For new systems, OIDC. For workforce SSO against an existing IdP, OIDC or SAML depending on what the IdP supports: they are functionally similar at the assertion layer. For machine-to-machine authorisation (services calling services), OAuth 2.0 client credentials or token exchange, never SAML. For partner federation, OIDC Federation 1.0 is the right answer when both sides can implement it; SAML is the right answer when at least one side cannot. The protocol is the easy part. The trust relationship and the contract are the work.
Identity & Access Management Patterns
The identity provider is an architectural primitive. The federation contract is the unit of trust. The authorisation model is a documented decision, not a configuration file.
On this page
§ 01 ·
What IAM is
Identity and access management is the discipline of answering two questions for every protected resource: who is making this request, and are they allowed to? The first question is the identity problem. The second is the authorisation problem. The two are often confused, and the confusion is the source of most IAM work that has to be redone.
The identity problem is solved by an identity provider. The identity provider does one job: given a credential and a relying party, return a verifiable assertion that says "this principal authenticated with this strength at this time." The protocol (OIDC, SAML) is the wire format of the assertion; the work is the trust relationship between the provider and the relying party.
The authorisation problem is solved by an authorisation model. The authorisation model is a piece of architecture that says: given a request from principal P, requesting resource R, with context C, the decision is X. The model can be expressed as code (a policy engine), as configuration (a list of rules), or as prose (a document that an engineer reads and implements). The property that makes the model usable is that the inputs are explicit, the decision is reproducible, and the output is provable from the inputs.
The work of IAM is the work of making these two primitives reliable across the whole organisation. That is harder than it sounds.
§ 02 ·
The trust boundary
The most useful idea in IAM is the trust boundary. A trust boundary is the line across which an assertion has to be evaluated. On one side is the issuer (the identity provider, the system that authenticated the principal). On the other side is the relying party (the system that accepts the assertion). Between them is the federation contract.
The federation contract is the part of IAM that is most often skipped. Two systems exchanging assertions is not federation; it is a copy of identity data with extra steps. Federation requires a contract: what assertions are accepted, what trust relationship exists, what the conformance tests are, what happens when the issuer is down, what happens when the assertion is replayed, what happens when the principal is no longer in good standing. Without a contract, the federation is a leak waiting to be discovered.
The most useful design heuristic is: every trust boundary is an architectural decision, and every architectural decision is a document. The document is short (a page, two pages), explicit (lists the assertions, the conformance tests, the failure modes), and current (reviewed when the boundary changes). The alternative: implicit trust boundaries established by configuration that nobody has read in two years, is the single most common source of identity-related incidents.
§ 03 ·
State of the practice
3
Public OIDC federation profiles that any organisation can implement today (OpenID Connect Federation 1.0, OAuth 2.0 Token Exchange, SAML 2.0)
OpenID Foundation, IETF
5
Authorisation models in production use — RBAC, ABAC, ReBAC, PBAC, capability-based
Industry observation; no single model has won
1
Federation contract: every trust boundary needs one, and most organisations have none
NOETRONIQ engagement observation
§ 04 ·
Questions we get asked
On three properties, in order: (1) is the federation model documented, with conformance tests, and revocable per-assertion; (2) does the authorisation model it supports accept external input (risk signals, device state, context) and produce reproducible decisions; (3) is the operating model documented: who can issue, who can revoke, what the audit trail is. A provider that scores well on (1) and poorly on (2) is a vault; a provider that scores well on (2) and poorly on (1) is a leak. Both properties matter.
The one your team can keep current. RBAC is the simplest and most often wrong: roles proliferate until they encode the organisation chart and the permission model loses meaning. ABAC is more expressive but harder to test. ReBAC (relationship- based) is the right model for graph-shaped organisations. The model matters less than the operating discipline: who reviews the model, how often, against what evidence.
With the same per-request discipline as human identities, but with different signals. The "principal" is a service identity with a clear lifecycle. The "device" is the workload runtime. The "context" includes the task and the trust the user delegated. The hardest problem is the audit loop: a service account that has been used in production for three years without review is a vulnerability waiting to be discovered. Service identity lifecycle is the part of IAM that most organisations handle least well, and the part that has the highest blast radius.
In almost every case, no. A single store serving workforce, partners, customers, and machines is a design ambition that usually produces a worse outcome than a federation of fit-for-purpose providers. Different populations have different lifecycles, different regulatory contexts, and different operational requirements. Forcing them into one store produces a system that is good at none of them. The right architecture is one or two authoritative providers per population, federated with explicit contracts.
Authentication answers "who is this principal?" Authorisation answers "is this principal allowed to do this thing?" The two are often confused because they happen close together in a request. The confusion is the source of work that has to be redone. An authentication system that is asked to make authorisation decisions is a system that has been asked to encode business policy in the IdP: and the IdP is the wrong place for business policy. An authorisation system that is asked to verify identity is a system that has been asked to trust the caller, and the caller is the wrong place to verify identity.
§ 05 ·
Patterns we design our practice to avoid
Security reviews find gaps in controls. They do not produce an architecture. An organisation that runs a security review every year and an identity review never has a better picture of its identity than it had when the last review finished. Identity is architecture: the trust boundaries, the federation contracts, the authorisation model, the lifecycle. These are designed, not audited into existence.
A single store serving workforce, partners, customers, and machines is a design ambition that usually produces a worse outcome than a federation of fit-for-purpose providers. Different populations have different lifecycles and different regulatory contexts, and forcing them into one store produces a system that is good at none of them.
An authorisation decision that lives in a configuration file nobody has read in two years is folklore, not architecture. Without an explicit model of who decides what, on what basis, with what evidence, the system cannot tell a legitimate decision from a bypass.
Two systems exchanging assertions is not federation; it is a copy of identity data with extra steps. Federation requires a contract: assertions, trust relationship, conformance tests, failure modes. Or it is just a less honest integration.
If the system cannot tell whether an identity is current, no authorisation decision is reliable. Lifecycle is the part of identity work that decides whether the rest of identity work matters. Joins, moves, leaves, role changes, de-provisioning, re-attestation: every one of these is an architectural concern that decays silently.
A review that happens at the end produces a finding list, not an architecture. By the time the review runs, the contracts are implicit, the assertions are baked in, and the changes the review recommends are expensive.
An identity architecture that cannot admit it was wrong is just ideology with a directory. The ability to revise a position cleanly, on the basis of new evidence, is more valuable than the ability to defend it.
§ 06 ·
Evidence & references
Public frameworks and writing that inform our practice.
NIST, 2017 (with revisions through 2024)
The assurance-level framework (IAL / AAL / FAL) is the vocabulary we use for the trust-boundary discussion. We borrow the rigour of the assurance definitions and apply them to federation contracts, not just to single-system authentications.
OpenID Foundation, 2014 (current revision)
The protocol specification we default to for new systems. The ID token and the userinfo endpoint give us a verifiable identity assertion; the access token gives us a verifiable authorisation grant. The two should not be confused.
OAuth 2.0 in Action
Justin Richer, Manning, 2017
The clearest end-to-end treatment of the authorisation layer as a contract, not a protocol. The conformance-test approach we use is the same approach the book describes for token exchange.
OAuth 2.1 — the consolidated draft
IETF, draft in progress
The simplification of OAuth 2.0: removing implicit flows, mandating PKCE, tightening redirect handling is the same direction the paved-roads model takes the enterprise. Less to remember, fewer ways to be wrong.
API Security in Action
Neil Madden, Manning, 2020
The pattern language for token-based authorisation, key rotation, and the testability of authorisation decisions is the operational reference we lean on most often.
Working on identity architecture?
If you are weighing an identity programme, navigating a federation change, or strengthening the trust boundaries of an existing architecture, we are useful at that boundary. A short conversation is the right next step.
Learn more