Access Management focuses on managing user authentication, authorization, and secure access to digital resources. It includes technologies and practices such as Single Sign-On (SSO), multi-factor authentication (MFA), and fine-grained access controls.
Adopt
We can clearly recommend this technology. It has been used for longer period of time at many customers and it has proven to be stable and useful.
Cloud Identity and Access Management (Cloud IAM), usually called Identity as a Service (IDaaS), is an identity provider that someone else operates: authentication, single sign-on, the user directory, provisioning and access policy, delivered as a managed service that the organization configures as a tenant instead of installing and running.
It becomes the platform the workforce, and often partners and customers, sign in through for cloud, software-as-a-service (SaaS) and on-premises applications alike. The name is easily confused with the permission system each cloud provider has for its own accounts, roles and resources, which is a different subject and the one CIEM covers. Moving to IDaaS removes the work of running identity infrastructure and replaces it with a dependence on the provider's availability, release cycle and handling of data, and the decisions that remain with the buyer follow from that dependence.
FIDO2 (FIDO: Fast IDentity Online) is an open authentication standard developed by the FIDO Alliance and W3C that enables passwordless authentication through public key cryptography. It is defined by two specifications that operate at different points in the same flow: WebAuthn, the browser API through which a relying party asks for a credential, and CTAP (Client to Authenticator Protocol), the protocol through which the client platform talks to the authenticator that holds it. Together they produce a credential that is scoped to one origin and cannot be phished, replayed against another site, or extracted as a reusable secret.
Identity Orchestration is an enterprise software control layer that unifies and coordinates identity and access management (IAM) systems across cloud, on-premises, legacy, and hybrid environments. It centralizes identity logic, decouples it from applications, and enables organizations to define authentication policy once and enforce it consistently everywhere. This orchestration layer provides connectors, workflow engines (often low-code or no-code), and an abstraction layer that eliminates the need for custom integrations or code changes in applications.
The OAuth 2.0 Step Up Authentication Challenge Protocol (RFC 9470, a final IETF standard since September 2023) lets an OAuth 2.0 API tell an application that the user's sign-in behind the current access token is too weak or too old for the request at hand, and what it requires instead, such as multi-factor authentication or a login within the last few minutes.
The application then asks the authorization server for exactly that authentication strength or recentness, so high-risk operations can demand stronger assurance without imposing it on every login.
OAuth 2.1 is the Internet Engineering Task Force (IETF) authorization framework that lets a user grant an application limited, revocable access to their resources at another service without handing over their credentials, and the delegation model behind most modern APIs and, through OpenID Connect, most web sign-in.
It consolidates OAuth 2.0 and the security practices learned since into one specification, removing the flows that proved unsafe; it is still an Internet-Draft, but its rules can already be applied to OAuth 2.0 deployments today.
OpenID Connect (OIDC) is the authentication protocol behind most modern web and mobile sign-in, built on top of OAuth 2.0 and its successor OAuth 2.1. OAuth lets an application obtain access to an API but never tells it who the user is; OIDC adds that answer, so an application can hand login to an identity provider and receive a signed statement of who authenticated and when, which is what makes single sign-on across many applications work. That statement is the ID Token, a signed JSON Web Token (JWT) carrying identity claims such as sub (user ID), iss (issuer), aud (audience), and optional profile information (email, name); further attributes come from the userinfo endpoint using scopes like openid (mandatory), profile, and email.
FIDO Passkeys are passwordless sign-in credentials built on the FIDO2 standards. They replace passwords with cryptographic credentials that are always strong and resistant to phishing, because the private key is never shared with the website and the credential is bound to the origin it was created for. Passkeys come in two forms, device-bound passkeys that stay on a single device and multidevice (synced) passkeys that a credential manager copies across a user's devices, and the choice between them is the central deployment decision, trading recoverability and reach against the number of places a credential can exist.
Single Sign-On (SSO) lets a user authenticate once with a central identity provider and then use many applications and systems without entering credentials again.
It removes password sprawl for users and gives the organization one place to enforce strong authentication and to withdraw access, at the price of making that provider and its session a single point of failure and a single target. SSO is an architecture rather than a protocol, delivered today mostly through OpenID Connect or SAML 2.0.
Third-party identity, also called federated identity, lets an application accept sign-ins from identity providers it does not run: consumer platforms for social login, or a partner organization's directory in business-to-business federation, over OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) 2.0. The application stops handling passwords, and in exchange it accepts identity statements whose strength, lifetime and continued validity another party controls. That exchange makes assurance, account linking and the loss of a provider the design questions.
Trial
We have used it with success and recommend to have a closer look at the technology in this ring. The goal of items here is to look at them more closely, with the goal to bring them to the adopt level.
Client-Initiated Backchannel Authentication (CIBA) is an OpenID Connect flow in which the application asks the authorization server to authenticate a user server-to-server, and the user approves on a separate device they registered earlier rather than through a browser redirect. It decouples the channel where something is being done from the channel where a person proves who they are, which makes authentication possible where no login screen can be presented at all: a service desk verifying a caller, a kiosk or point-of-sale transaction, a command-line tool, or an AI agent with no browser to redirect. CIBA is a final OpenID Connect specification with years of production use where a payment has to be confirmed out-of-band by the account holder, and it is now the mechanism organizations reach for when a human has to authorize an action that an autonomous process proposed.
Model Context Protocol (MCP) is the de facto standard for connecting AI models and agents to external tools, APIs, and data repositories, and its authorization model has consequently become the boundary at which most agent access to enterprise systems is actually granted or denied. MCP servers act as OAuth 2.1 resource servers and MCP clients as OAuth 2.1 clients, which means an organization exposing internal capabilities over MCP is making an authorization architecture decision rather than merely integrating a tool format. The gap between what the specification requires and what deployments do is currently the dominant risk.
OAuth 2.0 Demonstrating Proof of Possession (DPoP) is an extension to the OAuth 2.0 protocol, standardized as RFC 9449, that cryptographically binds access tokens to the client they were issued to.
An ordinary bearer token works for whoever holds it; a DPoP-bound token works only for an application that can also prove possession of the private key used to obtain it, which makes a copied token worthless on its own.
OAuth 2.0 Token Exchange (RFC 8693) and the identity chaining specifications built on it carry a user's identity and authorization context across service boundaries, so that each hop in a call chain can decide access based on who originally made the request rather than on the privileges of whichever service forwarded it. Token exchange provides the base primitive, trading one token for another, and the specifications profiled below define what belongs in the resulting token and how far it should travel. The problem predates AI agents and arises in any architecture where a service calls another service on a user's behalf, but agent workflows make it acute: a single request may traverse an orchestrator, several sub-agents, and multiple external APIs, and every hop is an opportunity to lose the original principal or silently amplify privilege.
Assess
We have tried it out and we find it promising. We recommend having a look at these items when you face a specific need for the technology in your project.
The Agent-to-Agent Protocol (A2A) standardizes how autonomous agents discover one another, describe their capabilities, and delegate tasks between themselves, addressing the coordination problem that begins where agent-to-tool protocols such as Model Context Protocol end. Where MCP answers how one agent reaches a tool, A2A answers how one agent establishes that another agent is who it claims to be and is authorized to receive a delegated task, a question that becomes pressing as soon as agents operated by different teams, or different organizations, participate in the same workflow. The protocol is governed by the Linux Foundation and reached version 1.0.0 in March 2026.
OpenID AuthZEN standardizes how an application asks a central policy service whether a user may perform an action, so that access rules can live in one governed place instead of being coded into every application. It defines the API boundary between Policy Enforcement Points (PEPs), the applications and API gateways that ask, and Policy Decision Points (PDPs), the engines that answer, as a common JSON interface. A PEP can therefore work with any compliant PDP, whatever policy language or engine it runs (XACML, OPA/Rego, Cedar, Zanzibar-style relationship engines, or plain access control lists), without custom integration for each one.
The OpenID Shared Signals Framework (SSF) is a standard for sharing security events in near real time between systems and organizations, so that a session revoked, a device fallen out of compliance or an account compromised in one place is acted on everywhere else that relies on it. It works alongside OpenID Connect and OAuth 2.1 deployments and gives them a common channel for security-relevant information across trust boundaries. Two profiles define what is sent: the Continuous Access Evaluation Profile (CAEP) for changes that should alter a live session, and Risk Incident Sharing and Coordination (RISC) for account-level incidents shared between organizations. SSF 1.0, CAEP 1.0 and RISC 1.0 have been OpenID Final Specifications since September 2025.
Device Bound Session Credentials (DBSC) is a W3C web standard that cryptographically binds browser session cookies to the specific device on which they were created, rendering stolen session cookies useless on any other device. Where passkeys and FIDO2 solve the problem of phishing-resistant authentication at login time, DBSC addresses the largely undefended phase that follows: the authenticated session itself. Infostealer malware has made mass cookie theft a lucrative industry, and DBSC directly disrupts this attack vector by requiring an attacker to also control the victim's hardware-backed cryptographic key.
The Grant Negotiation and Authorization Protocol (GNAP) is an Internet Engineering Task Force (IETF) standard (RFC 9635, October 2024) for delegating access to software, designed as a successor to OAuth 2.0 rather than an extension of it.
Where OAuth grew a separate grant type or extension for each situation, GNAP starts every request the same way and lets the client and authorization server negotiate how the user is involved, binds every request and token to a key held by the client instead of relying on bearer secrets, and can return information about the user alongside API access, which OAuth leaves to OpenID Connect.
It is not wire-compatible with OAuth, so adopting it means new client and server implementations.
GNAP supports Redirect-based Interaction, User-code Interaction, Asynchronous Authorization, Software-only Authorization, Refreshing an Expired Access Token, Requesting Subject Information Only and Cross-User Authentication.
OpenID Federation is a specification for establishing trust between many parties at once, without any two of them having exchanged configuration beforehand. OpenID Connect discovery tells a relying party where an identity provider's endpoints are but says nothing about whether that provider should be trusted, and SAML 2.0 federations answer the trust question with metadata that is either registered pairwise or aggregated and signed by an operator. OpenID Federation instead makes membership provable at request time: every participant publishes a signed statement about itself, its superior authority publishes a signed statement about it, and a verifier follows that chain of statements up to a trust anchor whose key it already holds. Trust becomes something computed from cryptographic evidence rather than something configured in advance, which is what allows a federation to reach thousands of participants without pairwise onboarding. It reached final specification status in 2026, split into OpenID Federation 1.1 for the protocol-independent trust infrastructure and OpenID Federation for OpenID Connect 1.1 for the OIDC and OAuth 2.1 bindings.
Hold
This category is a bit special. Unlike the others, we recommend to stop doing or using something. That does not mean that they are bad and it often might be ok to use them in existing projects. But we move things here if we think we shouldn't do them anymore - because we see better options or alternatives now.
Lightweight Directory Access Protocol (LDAP) is the IETF standard protocol, in its version 3, for searching and maintaining a hierarchical directory of users, groups and devices over an IP network, and for checking a password by binding to that directory as the user. For decades it was the backbone of enterprise identity in on-premises environments, used for authentication, authorization and directory lookups alike. Most applications now receive identity as a token from an identity provider instead, so LDAP survives as the store behind that provider and as the interface for hosts and legacy applications that speak nothing else.
Security Assertion Markup Language (SAML) 2.0 passes signed authentication statements in XML from an identity provider to a service provider. The identity provider authenticates the user once and issues an assertion holding their identity and attributes; each service provider consumes that assertion rather than collecting credentials itself, which is the mechanism behind most browser-based enterprise single sign-on in operation today. OASIS approved it as an OASIS Standard in March 2005 and the protocol has not changed since, so new integrations are built on OpenID Connect (OIDC) while SAML is an estate to maintain and migrate rather than one to extend.