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 (IAM), often referred to as Identity as a Service (IDaaS), represents a paradigm shift in how organizations manage user identities and control access to their resources.
These cloud-native platforms provide centralized capabilities for authentication, authorization, lifecycle management, and policy enforcement across cloud and hybrid environments. Traditionally, businesses relied on self-maintained solutions hosted on-premises to handle identity and access management. However, the evolution towards cloud computing has paved the way for a more dynamic and scalable approach.
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 and authorization policies once and enforce them 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 is a mechanism that OAuth 2.0 resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them.
This protocol also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request.
OAuth 2.1 is an authorization framework that enables secure and delegated access to protected resources on behalf of a resource owner.
It provides a standardized protocol for authorization and allows users to grant limited access to their resources to third-party applications without revealing their credentials.
OpenID Connect (OIDC) is an authentication protocol built on top of OAuth 2.1, adding standardized identity verification to OAuth's authorization framework. While OAuth 2.1 handles authorization, OIDC introduces the ID Token (typically a JWT) containing user identity claims such as sub (user ID), iss (issuer), aud (audience), and optional profile information (email, name). Applications retrieve additional user attributes via the userinfo endpoint using scopes like openid (mandatory), profile, and email.
FIDO Passkeys are a modern passwordless authentication standard based on FIDO2 technology. They replace passwords with cryptographic credentials that are always strong and inherently resistant to phishing, because the private key never leaves the user's authenticator and the credential is bound to the origin it was created for. Passkeys come in two forms — device-bound passkeys, which stay on a single device, and multidevice passkeys, which sync across a user's platforms through a credential manager — 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) is an authentication mechanism that enables users to securely access multiple applications and systems using a single set of login credentials.
With SSO, users authenticate once and gain access to multiple resources without the need to repeatedly enter their username and password.
Third-Party Identity, also known as Federated Identity or Social Login, refers to the use of external identity providers (IdPs) to manage user identities and authentication for applications and services using protocols like OAuth 2.1 and OpenID Connect (OIDC). Instead of maintaining their own user identity repositories, organizations configure their applications as Relying Parties (RP) or Service Providers (SP) that trust external IdPs such as popular consumer identity platforms or enterprise identity systems. This approach enables applications to support multiple IdPs, allowing users to choose their preferred authentication method while the application delegates identity management to established providers.
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 that provides a mechanism for cryptographically binding access tokens to a particular client when they are issued.
This technique is one of many attempts at improving the security of Bearer Tokens by requiring the application using the token to prove possession of the same private key that was used to obtain the token.
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 — trade 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 (Authorization Exchange) standardizes the API boundary between Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs), enabling applications and API gateways to request authorization decisions through a common JSON interface. This standardization means a PEP can work with any compliant PDP—whether powered by XACML/ALFA, OPA/Rego, Cedar, Zanzibar-style engines, or ACLs—without custom integration for each policy engine.
The OpenID Shared Signaling Framework (SSF), previously known as Shared Signals and Events Framework, is a standardized framework that enables real-time sharing of security events and signals between different systems and organizations. Built on the foundation of OpenID Connect and OAuth 2.1 protocols, SSF provides a common infrastructure for transmitting security-relevant information across trust boundaries. The framework supports specialized profiles including Continuous Access Evaluation Profile (CAEP) for dynamic access control and Risk Incident Sharing and Coordination (RISC) for coordinated security incident response.
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 / FIDO2 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 emerging authorization and authentication protocol.
The GNAP specification effectively consolidates all the different variations of OAuth that have evolved over the last decade, and addresses several security issues.
It takes everything the industry has learned from OAuth 2.0 and OpenID Connect over the years and consolidates them into a uniform pattern.
This reduces reliance on less-secure communications channels and builds in flexibility in a consistent way.
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.
LDAP, or Lightweight Directory Access Protocol, has historically been the backbone of enterprise identity management, providing a widely-used application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. For decades, it served as the foundation for managing identities within organizations, enabling authentication, authorization, and directory lookups in on-premises environments.
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.