Authentication, authorization, administration, and federation: learn what the 4 pillars of IAM are, how they work together, and how to implement each.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
The four pillars of IAM define the complete scope of what an identity and access management system has to do, and getting any one of them wrong creates compounding security and operational risk across the others. Search this phrase and you'll find two competing frameworks talked about as if they're the same thing. They aren't, but neither is wrong.
Auditing an existing IAM stack? The four pillars give you a structured way to find gaps. Building a new one from the ground up? They give you a checklist that's hard to miss anything from. Either way, each pillar here is treated as both a concept and a concrete engineering decision.
Identity and Access Management (IAM) is the set of policies, processes, and technologies that ensure only the right identities have the right access to the right resources, at the right time, for the right reasons. That's a lot of "rights" in one sentence, but each one is a real engineering decision that has to be made and re-made as the system evolves.
The four-pillar framework exists because IAM is too broad to think about as one system. Engineers and architects need a structured way to audit what they have, identify gaps, and make build-versus-buy decisions for each layer independently. Without the framework, "we need to fix our IAM" turns into a project that never ends. With it, the conversation becomes "we need to fix our authorization pillar before Q3," and that's a project that can actually be scoped.
Walk through the SERP and you'll see two frameworks. Enterprise-vendor sources (One Identity, miniOrange) use IGA, AM, PAM, and AD Mgmt because they're mapping the market categories their products serve. Foundational sources (IBM, Snowflake) use Authentication, Authorization, Administration, and Auditing because they're describing what IAM does conceptually. Neither is wrong. They're describing the same discipline from different angles. This article uses the foundational model with a small adaptation (Federation/SSO replacing Auditing as the fourth pillar) because it maps directly to the technical layers engineers actually build and manage in production.
IAM traditionally refers to workforce identity: employees, contractors, partners. CIAM (Customer IAM) applies the same four pillars to external users and customers. The distinction matters for product-led companies building consumer-facing products, where the authentication pillar has to optimize for conversion as much as for security and the federation pillar has to include social login. The pillars are the same. The constraints are different. For the full picture on this, see Ory's customer identity and access management hub.
Authentication is the process of verifying that a user, device, or service is who or what it claims to be, typically by validating a credential such as a password, MFA code, passkey, or certificate.
The methods sit on a spectrum from "what most teams still use" to "what most teams are moving toward."
Passwords remain the most widely deployed credential and the most attacked. MFA (TOTP, push notifications, hardware tokens) adds a second factor and dramatically reduces credential-compromise risk. Passkeys and WebAuthn use public-key cryptography bound to a device or biometric and are phishing-resistant by design. SSO lets a user authenticate once and access many apps (covered in Pillar 4). Biometrics can stand alone or pair with another factor depending on the platform.
The industry shift toward passwordless isn't marketing. Credential theft has been the dominant attack vector for years, and passkeys remove the shared secret entirely. For CIAM specifically, passwordless is also a conversion lever, not just a security one.
Once authentication succeeds, the system has to issue a session or token that downstream systems can trust. The session is the artifact that proves authentication happened. Everything in the authorization pillar consumes it. This is also where Pillar 1 hands off to Pillar 4, because the session or token is what gets federated across system boundaries.
The constraints diverge here. Workforce IAM can demand strong security, managed devices, and acceptable login friction (employees aren't going to abandon a sign-in because it takes ten seconds). CIAM has to balance security against conversion. Social login is expected. SSO via the user's existing identity provider is expected. Passkeys aren't a bonus, they're becoming table stakes. The authentication requirements are different for each user population, even though the underlying pillar is the same.
Security doesn't have to be a bottleneck for growth. By implementing Ory’s 'one-tap' social login in less than 48 hours, we saw a 8-10% increase in our visitor-to-signup numbers.
— Raunak Kathuria, VP of Engineering, Deriv
For the authentication pillar, Ory Kratos is an identity management system that handles the full authentication layer (user registration, MFA, passkeys, social login, and session management) without requiring a proprietary vendor platform or building the flows from scratch.
Explore Ory Kratos for authentication and identity administration
Authorization is the process of determining whether an authenticated identity is permitted to perform a specific action or access a specific resource, enforcing the policies that define what each user can do, not just who they are.
Authentication is "you are who you say you are." Authorization is "here is what you are allowed to do." A developer authenticated into an internal tool may be authorized to read logs but not delete records. The distinction collapses in many systems, and when it does, the result is over-privileged accounts and broken access control vulnerabilities. This is the OWASP A01 failure mode, and it's been the most common web application security flaw for years running.
Three models dominate. RBAC (Role-Based Access Control) assigns permissions to roles and users to roles. Simple, auditable, the right default for most stable hierarchies. ABAC (Attribute-Based Access Control) evaluates attributes of the user, resource, action, and environment to make dynamic decisions. The right choice for regulated industries and context-driven access. ReBAC (Relationship-Based Access Control) defines permissions through relationships between entities ("user is editor of this document"). The model behind Google Drive, GitHub, and Ory Keto.
Least privilege means granting only the minimum permissions required for each task. Zero trust extends this to require continuous verification rather than assumed trust once a user is inside the perimeter. The authorization pillar is where least privilege gets technically enforced, which is why misconfigurations here matter so much: an over-privileged role is the operational equivalent of leaving a door unlocked at the office.
For the authorization pillar, Ory Keto is an authorization server built on Google's Zanzibar relationship-based access control model, designed to evaluate permissions at the speed and scale that production APIs require.
Explore Ory Keto for authorization
Identity administration, also called Identity Lifecycle Management, is the process of creating, maintaining, and securely deprovisioning digital identities throughout a user's relationship with an organization or application.
The lifecycle has three phases and every one of them is where compliance lives or dies.
A central user store (directory, database, LDAP) is the source of truth for all identity data. What it contains: attributes, credentials, access rights, and the history of each. Centralizing the user store is what makes audit and compliance tractable. Fragmented user stores (auth in one place, profile data in another, group membership in a third) are how organizations end up unable to answer "what does this user have access to?" in a reasonable timeframe.
Manual provisioning and deprovisioning create risk. SCIM (System for Cross-domain Identity Management) is the standard for automating lifecycle events across connected systems. When a user is added in your IdP, SCIM pushes that to every connected app. When they're removed, SCIM revokes everywhere. Manual approaches always lag. SCIM doesn't, and for compliance-driven orgs, that lag is the difference between passing and failing an audit. For implementation depth on this, see directory synchronization and SCIM.
Ory Kratos also handles the identity administration layer (user profiles, self-service flows, credential management, and account lifecycle), making it the implementation point for two pillars rather than one.
Explore Ory Kratos for identity administration
Federation and SSO allow a user's authenticated identity to be trusted and accepted across multiple systems and organizational boundaries, so they can log in once and access everything they're authorized to use without re-entering credentials.
Federation establishes a trust relationship between an identity provider (IdP) and one or more service providers (SPs). When a user authenticates with the IdP, that authentication is accepted by all federated SPs. This is what makes enterprise SSO work across dozens of third-party applications: one login at Okta, access everywhere Okta is federated.
OAuth 2.0 with OIDC is the modern, API-first choice: lightweight, mobile-friendly, developer-native. SAML is the established enterprise standard: XML-based, deeply supported by existing IdPs, required for many legacy and regulated-industry integrations. Most mature stacks run both. For the full comparison, our OAuth/OIDC vs SAML for federation guide breaks down when each one is the right fit.
In customer-facing applications, federation means letting users authenticate with their existing identity from Google, Apple, or a social provider. This is a conversion-critical feature: registration friction drops, security stays intact, and the user doesn't need to remember another password. For Ory's CIAM customers, social login isn't optional. It's expected.
For teams managing the OAuth 2.0 and OIDC federation layer, Ory Hydra is an authorization server that handles token issuance, validation, and the full OAuth 2.0 grant flow without coupling identity management to authorization.
For organizations that need enterprise SAML SSO (federating workforce identity across existing IdPs like Azure AD or Okta), Ory Polis is an enterprise SSO solution that supports SAML-based federation alongside modern OIDC flows.
Explore Ory Hydra for authorization via OAuth 2.0 and OIDC
Explore Ory Polis for SAML SSO
The four IAM pillars are interdependent: identity administration creates the digital identity first, authentication verifies it at login, authorization enforces what that identity is permitted to do, and federation extends the verified identity across multiple systems without requiring re-authentication.
Walk through the lifecycle of a new employee. IT provisions their identity (Pillar 3: administration). They log in with MFA (Pillar 1: authentication). They're granted role-appropriate access to their tools (Pillar 2: authorization). They use SSO to access cloud applications without re-entering credentials (Pillar 4: federation). Each pillar fires in sequence, every working day, for every employee. That sequence is the whole IAM stack in motion.
A failure-mode view per pillar is the most useful audit framework most teams can adopt. If you can answer "where would we break first?" for each pillar, you've already done more than most organizations.
In modern cloud-native and zero-trust architectures, the four IAM pillars operate without a trusted perimeter: every authentication has to be verified, every authorization has to be evaluated at request time, identity administration has to include non-human identities, and federation has to extend to APIs and machine-to-machine flows.
Zero trust removes the implicit trust of "inside the network." Authentication becomes continuous rather than one-time. Authorization has to be evaluated at every request, not assumed from role alone. Identity administration has to handle devices and workloads, not just users. Federation has to cover cross-cloud access without VPN dependency. The pillars don't change. Their operating conditions do. For depth on this, see implementing zero trust API security.
CIAM applies the same four pillars to external users. Authentication prioritizes low-friction flows (social login, passkeys). Authorization controls feature access and data visibility (often tied to subscription tiers). Administration handles self-service registration and profile management. Federation enables sign-in with existing consumer identity providers. The shape of the pillar is the same. The success metric (conversion alongside security) changes. The customer identity and access management hub covers this in depth.
AI agents, service accounts, and machine identities require IAM treatment across all four pillars. Authentication for agents uses client credentials and certificates rather than passwords. Authorization for agents has to be scoped tightly under least privilege. Administration has to provision and deprovision agent identities as services are deployed or retired. Federation enables agents to call APIs on behalf of users via OAuth delegation. This space is moving quickly, and the pillars are how you keep up without losing the plot.
Each of the four IAM pillars can be implemented with commercial or open source tooling from Ory. Teams don't need a monolithic vendor platform, but they do need to ensure the tools they choose cover all four pillars and integrate cleanly across them.
| IAM Pillar | Ory Product | What It Covers |
|---|---|---|
| Authentication | Ory Kratos | Registration, login flows, MFA, passkeys, session management |
| Authorization | Ory Keto | ReBAC / RBAC policy enforcement, permission checks, access control |
| Identity Administration | Ory Kratos | User provisioning, profile management, self-service flows, account lifecycle |
| Federation / SSO (OIDC) | Ory Hydra | OAuth 2.0 and OIDC authorization server, access token issuance and validation |
| Federation / SSO (SAML) | Ory Polis | Enterprise SAML SSO, IdP federation, workforce single sign-on |
Three questions determine whether each pillar gets built in-house or delegated to purpose-built tooling. Does your team have the capacity to build and maintain each pillar from scratch? Most teams underestimate the long-tail security maintenance cost of this. Does your compliance posture require auditability that homegrown solutions can't easily provide? Regulated industries usually answer yes. Do your scaling requirements demand infrastructure-grade reliability? If you're heading toward millions of identities, the answer is almost always yes.
Teams that answer no, yes, or yes to any of these questions should delegate to purpose-built open source tooling. The maintenance burden of running each pillar yourself is real, and the security and compliance cost of running them poorly is bigger.
See how Ory's stack covers all four pillars
The four pillars aren't an academic framework. They're the operating layout of every modern identity stack, whether the team building it knows the framework by name or not. Treating each pillar as a real engineering concern (with its own decisions, its own tooling, and its own failure modes) is what separates IAM that scales from IAM that breaks. The good news: each pillar has a clean open source implementation available today, and they're designed to integrate. The harder news: getting all four right is more work than any single product page suggests, which is why audits keep finding gaps.
