Introduction

In the modern digital ecosystem, identity has become the primary perimeter. As organizations transition from centralized offices to distributed, cloud-native environments, the ability to securely verify and manage identities across a vast array of applications, devices, and users is no longer just a technical requirement—it is a business imperative.

Historically, identity management was siloed, with each application maintaining its own user database and authentication logic. This fragmentation created significant security gaps, poor user experiences, and immense operational overhead. To solve these challenges, the industry moved toward standardization.

Identity and Access Management (IAM) standards and protocols provide the common language that allows disparate systems to communicate securely. By adopting these universal frameworks, organizations can achieve:

• Interoperability: Seamlessly connecting internal systems with third-party software-as-a-service (SaaS) providers and partner networks

• User Experience: Enabling Single Sign-On (SSO) to eliminate “password fatigue” and streamline digital workflows

• Security Posture: Implementing consistent, audited security controls that reduce the attack surface and prevent unauthorized access

• Compliance: Meeting rigorous global data protection and privacy regulations through standardized logging and attribute sharing

This document explores the landscape of these essential standards, categorizing them by their functional capabilities and technical roles. By understanding the strengths and limitations of each, architects and security leaders can build a cohesive identity strategy that supports both current operations and future growth.

The IAM Functional Framework

While the business goal of IAM is clear—secure, seamless access—the technical execution requires a multi-layered approach. Standards do not exist in a vacuum; they are purpose-built to solve specific parts of the identity lifecycle. To navigate this landscape, it is helpful to view these standards and protocols through the lens of the primary “jobs” they perform:

• Authentication (Who are you?): Standards that prove a user or machine is who they claim to be, often moving beyond passwords to cryptographic keys and biometrics
• Authorization (What can you do?): Protocols that define the boundaries of access, ensuring that once an identity is verified, it only touches the resources it is permitted to use
• Provisioning and Governance (How do you get there?): The “plumbing” of IAM that automates the creation, maintenance, and deletion of accounts across disparate systems to ensure the right people have the right access at the right time

By categorizing standards this way, we can evaluate their suitability for specific use cases—whether you are securing a mobile app, managing a multi-cloud infrastructure, or retiring a legacy on-premises directory. The following sections break down these protocols by their core capabilities, starting with the foundational methods of verifying identity.

Authentication

Authentication is the process of verifying the identity of a person, device, or system to ensure they are who they claim to be. It can be performed using traditional methods, such as usernames and passwords, or modern passwordless approaches like passkeys. Authentication is a foundational cybersecurity control and the first step in protecting systems and sensitive data.

Modern authentication relies on IAM protocols that reduce the need for applications to store credentials directly. Instead, identity providers use federated, token-based authentication to verify users and issue tokens asserting identity and assurance. Common protocols based on open standards include OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) for authentication and OAuth 2.0 for delegated authorization, enabling secure, standardized identity verification across systems.

Multifactor authentication (MFA) strengthens authentication by requiring two or more independent factors, such as something you know, have, or are, thereby mitigating the risk of credential-based attacks. MFA also serves as a foundational enabler for Zero Trust by ensuring that identity is continuously verified through multiple independent signals rather than relying on static credentials.

For high-risk situations, step-up authentication may require users to re-authenticate with stronger methods before performing sensitive actions such as changing account settings or accessing healthcare or financial data. Separately, adaptive or risk-based MFA looks at context, such as device, location, or unusual behavior to decide whether to prompt for extra security steps. Strong controls must balance user experience with security, including options for legitimate account recovery.

Single Sign-On

SSO is an authentication process that enables users to securely access various applications using one set of credentials. SSO allows users to authenticate once with an identity provider (which may be cloud-based or on-premises) and then access multiple connected applications or systems without re-entering credentials. By centralizing authentication, SSO improves user experience, enhances productivity, enables centralized authentication enforcement and policy control, and reduces password fatigue.

How It Works

SSO relies on a trusted Identity Provider (IdP) to authenticate users and issue identity assertions or tokens:

1. Initial Authentication: User logs in once to the IdP with their credentials.

2. Token/Assertion Issuance: IdP validates credentials and generates a signed authentication token or assertion.

3. Service Access: When the user accesses a connected application, a Service Provider (SP), the application redirects to the IdP.

4. Token Verification: IdP confirms the user already has an active session and generates an assertion or token for the Service Provider.

5. Access Granted: Service Provider validates the token and grants access without requiring the user to log in again.

This process relies on trust relationships between the IdP and Service Providers, established before SSO occurs, through shared certificates, metadata exchange, or federation agreements.

Pros

• Streamlined access and convenience as user needs to log in only once

• Reduces the number of credentials users must manage, lowering the attack surface and making centralized monitoring and password hygiene easier

• Reduced password resets requests, easing the workload on IT Helpdesk/Service Desk

• Security policies can be applied across enterprise level, and any changes in policy are easy to deploy

• Centralized authentication allows for consolidated logging, monitoring, and anomaly detection, which strengthens incident response capabilities

• Enables federation of identities, instead of maintaining users in multiple applications

Cons

• Single point of failure as compromised IdP or user credentials may grant attackers unauthorized access to all relying applications/systems

• Heavy dependence on the IdP as non-availability of IdP makes all relying systems inaccessible

• Could become complex to implement depending on protocols used or integrations needed

• Universal application/service logout sync may not be applied consistently, especially on legacy services (e.g., user sessions may remain active if logout events are not propagated)

• Token replay risk as someone can reuse a stolen login token to access accounts if protections are weak

• IdP misconfiguration (SSO) can let the wrong users log in or bypass security checks

Supporting Protocols

Protocol	Definition	Use
SAML/SAML 2.0	XML-based identity federation protocol.	Securely exchange authentication data (assertions) between an IdP and SP to confirm the user’s identity. IdP authenticates the user and issues a digitally signed (and optionally encrypted) assertion that conveys verified identity information to the SP, enabling secure SSO and federated access.
OIDC	Modern authentication protocol.	Allows apps to verify user identities via a trusted IdP. Data is exchanged between IdP and SP using digitally signed and optionally encrypted JWT after successful authentication.
Kerberos	Network authentication protocol.	Kerberos is an authentication protocol that enables secure communication between trusted systems over an untrusted network by using tickets issued by a trusted Key Distribution Center (KDC). It relies on symmetric cryptography to encrypt these tickets and to generate session keys. After a user is authenticated, a ticket is provided to verify their identity to services, and a session key is used to securely handle the communication between the client and the service without repeatedly transmitting passwords. Note: Kerberos PKINIT uses asymmetric keys only for the initial authentication; all subsequent Kerberos tickets and session communications still use symmetric keys.
Smart Card Authentication	Physical smart card with an embedded chip that stores cryptographic credentials to securely verify a user’s identity.	Uses embedded X.509 certificates to perform public key cryptography (PKI). In SSO, the card interacts with the OS (e.g., via Kerberos PKINIT) or browser (via mutual mTLS or mTLS) to authenticate the user once for session access.
Derived Credentials in Smartphones (Use in Personal Identity Verification (PIV) Credentials)	Derived credential module. A collection of objects (e.g., certificates, keys) that provide derived smart card functionality in a derived smart card application or other device.	The maintenance activities for a PKI-based derived PIV credential are the same as for other X.509 public key certificates. Certificate re-key is typically used to replace a certificate that is nearing expiration. Certificate modification replaces a certificate if information about the subscriber that appears on the certificate (e.g., their name) needs to be changed.
WS-Federation (via Claims)	Legacy Microsoft protocol that supports federated identity as part of SSO, supporting protocols. Supported for backward compatibility but largely superseded by OIDC and SAML.	Enables federated identity and SSO across trusted domains using SOAP and XML-based assertions and are typically transported via SOAP or HTTP bindings.
Service-Ticket–Based SSO	An SSO method that uses temporary tickets instead of passwords.	User logs in once, gets a ticket, and presents it to multiple apps to prove identity without re-entering credentials.

Table 1: Supporting Protocols for Single Sign-On

Real-World Application

SSO is widely used in enterprises that require users to be granted access to multiple services. For example, a new hire in a company may need access to Workday for payroll, ticketing systems like Jira to contact IT, email, and collaboration tools like Zoom or Slack. Instead of creating separate credentials for each service, implementing SSO will streamline access with a single credential, reducing IT provisioning time from hours to minutes. SSO allows users to access all applications without repeatedly entering credentials.

• Enterprise and Corporate Access: Employees log in once to access email, HR tools, project management, and intranet. Example: Accessing Microsoft 365, Salesforce, or Workday via authenticating with Microsoft Entra ID

• Unified Enterprise and Cloud Access: Entra ID can also be integrated with other cloud IAMs (e.g., AWS IAM, Google IAM) to provide unified access with corporate and cloud accounts. This allows users to log into AWS, Google, or Azure using their Entra credentials. This facilitates role-based access control (RBAC) support by enabling the mapping of corporate user accounts to cloud roles

• Cross-Company Collaboration: External partners or vendors use their own IdP credentials to access shared company resources safely. Example: B2B federated SSO implemented by SAML, OIDC, or WS-Federation

• Social Login: E-commerce services (e.g., Amazon, Etsy, Shopify) let customers sign in with OIDC/OAuth flows powered by Google, Facebook, or Apple. Example: OAuth 2.0 + OIDC for Amazon, Etsy, or Shopify

References

• OASIS. (2008). “Security Assertion Markup Language (SAML) V2.0 Technical Overview.” Available at: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

• OpenID Foundation. (2014). “OpenID Connect Core 1.0.” Available at: https://openid.net/specs/openid-connect-core-1_0.html
• Neuman, C., et al. (2005). “The Kerberos Network Authentication Service (V5).” RFC 4120. Available at: https://tools.ietf.org/html/rfc4120

Business to Customer/Customer Identity and Access Management

Business to Customer (B2C), often called Customer Identity and Access Management (CIAM), supports authentication and authorization for customers at internet scale (e.g., Entra External ID, AWS Cognito, Auth0, PingOne), where user experience and security are critical. Unlike workforce IAM, B2C typically requires self-service flows and strong protections against account takeover.

How It Works

Common CIAM patterns include:

• Registration and account recovery (self-service sign-up, email/phone verification, secure reset)
• Social login often using OIDC on top of OAuth
• Consent-driven access where users approve what an application can access (e.g., scopes, claims)
• Risk-based setup for high risk actions (e.g., payment, data export) using strong authentication (e.g., MFA, biometrics)

In B2C, OIDC/OAuth are commonly preferred due to their mobile/API friendliness and wide ecosystem support, while strong authentication methods (e.g., FIDO2/WebAuthn) reduce phishing and credential stuffing.

Pros

• Improved user experience
• Better security
• Faster to build apps
• Reduced credential risk
• Fine-grained consent and access control
• Centralized identity services
• Helps follow privacy laws

Cons

• Greater exposure to broad attack surface and internet-based threats
• Identity assurance variability
• Operational complexity at scale
• Privacy considerations are challenging

Multifactor Authentication

Multifactor authentication (MFA) is a method that requires two or more authentication factors to ensure stronger identity verification. MFA can help to protect sensitive data from breaches caused by compromised credentials.

Two-factor authentication (2FA) is a subset of MFA that requires exactly two different authentication factors. MFA, more broadly, refers to any authentication mechanism requiring two or more independent factors.

How It Works

MFA relies on users to provide multiple independent credentials to verify their identity before granting access to services. These factors typically involve a distinct combination of the following:

Factor Type	Description	Example	Security Strength
Knowledge (Something you know)	Information only known to the user	Passwords, PIN, passphrase	Low to Medium:Susceptible to phishing, shoulder surfing, brute force, credential reuse
Possession (Something you have)	Tangible object in the user’s possession	Hardware token (e.g., YubiKey), authenticator app, SMS to phone	Varies:Hardware tokens (High), Authenticator apps (Medium to High), SMS due to vulnerability of SIM swapping, interception risk (Low)
Inherence (Something you are)	Biometric attribute(s)	Facial and/or voice recognition, fingerprint	Medium to High:Depends on implementation quality; some biometrics can be spoofed

Table 2: Factors for Multifactor Authentication

MFA implementations should align with assurance levels defined in National Institute of Standards and Technology (NIST) SP 800-63B. Higher authenticator assurance levels (AAL) (e.g., AAL2, AAL3) require stronger authenticator types, with phishing-resistant methods such as FIDO2-based authenticators mandated for higher-risk environments. Organizations should select MFA mechanisms based not only on usability but also on the assurance level required for the protected resource.

Types of MFA

• Standard MFA: Requires the same authentication factors for every login attempt, regardless of context (e.g., always password + SMS code, always password + authenticator app)

• Adaptive MFA (Risk-Based Authentication): Dynamically adjusts authentication requirements based on real-time risk assessment. Users may face different authentication challenges depending on contextual factors such as:

  • Login location (e.g., office vs. foreign country)
  • Unrealistic travel (e.g., simultaneous logins from two continents within minutes)
  • Device recognition (e.g., known vs. new device, company issued device vs. personal device)
  • Device posture (e.g., presence of updated antivirus signatures, patch updates)
  • Time of access (e.g., business hours vs. midnight)
  • Network security posture (e.g., corporate network vs. public Wi-Fi)
  • Behavioral patterns (e.g., typing speed, mouse movements)
  • Risk score from threat intelligence

  This approach helps reduce MFA fatigue by avoiding unnecessary prompts, so users don’t get overwhelmed and start approving requests blindly. For example, if a user logs in from their usual office location on a trusted device, they might be able to sign in with a simpler method. But if the same user tries to log in from a different country on an unfamiliar device, the system will step up security and ask for stronger verification, like a fingerprint or a hardware token. This is how adaptive MFA works; it adjusts the level of security based on the risk of the login attempt

• Step-Up Authentication: Prompts for additional authentication only when accessing high-risk resources or performing sensitive actions (e.g., viewing financial data, changing security settings, approving large transactions). Unlike adaptive MFA, which is risk-driven, step-up authentication is triggered by predefined policy rules based on the resource or action being attempted

Pros

• MFA significantly reduces the risk of account compromise in the event of leaked passwords, though it doesn’t completely remove the risk of session hijacking, device compromise, or real-time adversary-in-the-middle attacks

• Adaptive MFA improves security and user experience by dynamically adjusting authentication requirements based on real-time risk factors, such as a user’s location, device health, or login patterns, ensuring that extra friction is only applied when a threat is actually suspected

• Strong MFA options are less susceptible to brute force attacks (e.g., passkeys, hardware FIDO2 tokens that use device-bound asymmetric cryptography instead of guessable shared secrets)

Cons

• MFA is vulnerable if not implemented correctly. Less secure MFA options (e.g., SMS OTP, software-based tokens) can be exploited. SMS for MFA is not recommended based on guidance from NIST, the Cybersecurity and Infrastructure Security Agency (CISA), and the Federal Bureau of Investigations (FBI)

• Users can be locked out if MFA is unavailable or inaccessible and no backup method is configured

• Can cause user fatigue by adding extra authentication steps, particularly in high-frequency or time-sensitive access scenarios

• Adds account recovery complexity as secure recovery processes are needed when users lose MFA devices

• MFA is designed for interactive human authentication, so NHIs require alternative controls such as certificates, workload identity, or token-based authentication

Real-World Application

Password leaks or compromises are becoming increasingly common as users tend to reuse the same password for multiple services, such as reusing a social media account password for an internal company service. With increasing complex social engineering and phishing attempts, a company’s employees may lack protection from compromising critical internal services if they practice poor password hygiene. MFA helps protect the user accounts in such cases by challenging additional verification for every login attempt.

Companies relying on SaaS or cloud-hosted systems can implement MFA as an additional layer of protection to safeguard against vendor breaches:

• Banking Apps: Use login plus biometrics to secure financial transactions

• Healthcare Information Systems/Apps: Implement MFA to safeguard sensitive patient data, comply with privacy regulations, or meet cyber insurance requirements. Doctors and other healthcare providers are often required to use an ID badge plus an additional factor (login or biometric)

• Cloud Platforms (e.g., AWS, Azure): Require MFA for privileged account access to prevent unauthorized changes, typically login and an SMS/App OTP or a physical security token (e.g., Yubikey)

MFA factors of varying strength can be implemented based on the criticality of the systems. For very sensitive systems, phishing-resistant tokens like FIDO2 security keys offer the best protection:

• Adaptive or behavior-based MFA policies can be configured to re-authenticate a user accessing a system from a new location. This can help identify whether the user’s account has been compromised or if the user was traveling legitimately. This differs from step-up authentication, as adaptive MFA is dynamic and triggered by risk context, whereas step-up authentication is triggered by predefined actions/ rules

• Phishing-resistant hardware tokens can be used as an effective defense against MFA fatigue. MFA fatigue, also known as prompt bombing, occurs when an attacker attempts to overwhelm the user by repeatedly sending push notifications, prompting the user to approve access

References

• https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
• https://pages.nist.gov/800-63-3/sp800-63b.html
• https://www.cisa.gov/sites/default/files/2024-12/joint-guidance-mobile-communications-best-practices_v2.pdf
• OpenID Foundation. Shared Signals and Events A Secure Webhooks Framework. https://openid.net/specs/openid-sharedsignals-framework-1_0.html
• OpenID Foundation. Continuous Access Evaluation Profile (CAEP) 1.0
  https://openid.net/specs/openid-caep-specification-1_0.html

Identity Proofing

Identity proofing involves verifying a person’s identity to ensure they are who they claim to be before granting them access to systems, services, or data. This prevents unauthorized access, ensures that only verified users can be granted access, and supports Zero Trust and compliance.

How It Works

Identity proofing follows a three-step process defined by NIST SP 800-63A (Revision 4):

1. Resolution (Identity Uniqueness): Establish that the claimed identity corresponds to a unique, real person. This involves collecting identity attributes (e.g., name, date of birth, address) and ensuring they uniquely identify one individual, not multiple people with similar information. Example: Collecting full name, date of birth, and last four digits of a social security number (SSN) to distinguish between individuals

2. Validation (Evidence Authenticity): Verify that the identity evidence provided (e.g., government-issued ID, birth certificate, utility bill) is genuine, authentic, and hasn’t been tampered with or forged. This may involve:

   1. Checking security features (e.g., holograms, UV markings)
   2. Verifying with issuing authorities or databases
   3. Using document authentication technology (e.g., OCR, pattern recognition)

   Example: Scanning a driver’s license and verifying it against state DMV databases

3. Verification (Binding to Real Person): Confirm that the person presenting the evidence is the actual owner of that identity, not an imposter. Methods include:

   1. Biometric matching (e.g., facial recognition, fingerprint)
   2. Knowledge-based verification (e.g., answering questions only the real person would know)
   3. Live video interaction with trained operators

   Example: Taking a selfie and comparing it to the photo on the submitted government ID using facial recognition

Identity Assurance Levels (IALs)

Identity proofing follows NIST SP 800-63A-Final, July 2025, which defines three Identity Assurance Levels (IAL) based on the rigor of identity verification:

• IAL1 (Low Assurance):

  • Self-asserted identity with minimal verification
  • No identity proofing required
  • Example: Basic email or username registration

• IAL2 (Substantial Assurance):

  • IAL2 requires identity evidence to be validated
  • Remote or in-person identity proofing
  • Requires identity resolution, validation of government-issued ID, and verification that applicant is the person claimed
  • Example: Opening a bank account remotely with ID upload and selfie verification

• IAL3 (High Assurance):

  • In-person identity proofing with trained operator
  • Requires strongest evidence validation and biometric verification
  • Example: TSA PreCheck enrollment, passport application, high-security clearance

Each level increases the strength of identity resolution, evidence validation, and identity verification to match the risk level of the application.

Pros

• Enhances security by preventing identity fraud and unauthorized access
• Supports regulatory compliance (e.g., KYC, AML, GDPR, CCPA, DORA, eIDAS)
• Builds trust for online accounts and remote sign-ups
• Enables automation and scalability in identity management

Cons

• It can make the user experience slower or more difficult if there are too many steps
• Raises privacy worries about personal and biometric data
• Vulnerable to AI-driven spoofing, deepfakes, or social engineering if not well designed
• Advanced systems can be expensive to build and run

Real-World Application

Example 1: Remote Banking Account Opening (IAL2)
A user wants to open a bank account online. The bank’s identity proofing process requires:

1. Resolution: User enters name, date of birth, SSN, and address.
2. Validation: User uploads driver’s license, and system verifies authenticity using document verification technology and checks against DMV databases.
3. Verification: User takes a selfie, and facial recognition compares it to the license photo.

This IAL2 process allows remote account opening while meeting Know Your Customer (KYC) and Anti-Money Laundering (AML) compliance requirements.

Example 2: TSA PreCheck Enrollment (IAL3)
Applicants must appear in person at an enrollment center where a trained operator:

1. Verifies government-issued ID and supporting documents.
2. Captures fingerprints.
3. Conducts in-person interview.
4. Performs background check.

This IAL3 process provides high assurance for security-sensitive applications like expedited airport screening.

References

• NIST. (2025). “Digital Identity Guidelines.” NIST Special Publication 800-63-4. Available at: https://pages.nist.gov/800-63-4/
• NIST. (2025). “Digital Identity Guidelines: Enrollment and Identity Proofing.” NIST Special Publication 800-63A Revision 4. Available at: https://pages.nist.gov/800-63-4/sp800-63a.html

Federation

Federation is a mechanism that allows users to access multiple systems or applications across different organizations or independent domains (e.g., between partner companies, contractors, or between cloud and on-premises apps) using a single identity. It enables trust relationships between IdPs such as Microsoft Entra ID (formerly Azure AD), Google Workspace, or even Active Directory (AD) or LDAP, and SPs like AWS and Salesforce. Some use cases for federation include securing access for vendors and partners, as well as managing user access during company mergers and acquisitions.

How It Works

Federation relies on a trust relationship between an IdP and one or more SPs. When a user attempts to access a service, the SP redirects the user’s authentication request to the trusted IdP. The user authenticates with their IdP credentials and, upon successful verification, the IdP generates a cryptographically signed security token or assertion. This assertion contains information about the user, including their identity, roles, and attributes. The IdP then sends this token back to the SP, which validates the token’s authenticity and grants the user access to the requested resource without requiring them to re-enter their credentials.

Continuous Access Evaluation Profile (CAEP)

Traditional federation validates a user’s identity only at the time of login. Once a session is established, access typically remains valid until the session expires, even if the user’s security posture changes (e.g., user’s device becomes compromised, user’s credentials are stolen). To address this limitation, the Shared Signals Framework (SSF) introduces real-time security event sharing between systems. Within SSF, the Continuous Access Evaluation Profile (CAEP) enables IdPs to immediately notify relying applications when a critical security event occurs, such as account compromise, password reset, device risk detection, or policy violation.

Pros

• Users can access multiple applications across different organizations with a single set of credentials, eliminating the need to manage multiple accounts and passwords

• Centralized identity management simplifies user provisioning and deprovisioning, as administrators only need to manage accounts in the IdP, not in every individual SP

• Federation reduces the attack surface by eliminating password proliferation and credential sharing, as users do not need to create new accounts for each application. It also enables organizations to enforce consistent security policies, like MFA, at a central location. Additionally, federation can help companies meet compliance requirements, as centralized controls and logging are easier to manage and audit

• Federation enables seamless integration with new partners or applications, eliminating the need for complex and time-consuming manual account creation processes

Cons

• A compromised IdP puts all federated services at risk and could lead to unauthorized access across multiple interconnected services

• Establishing the trust relationship and configuring federation between the IdP and various SPs can be complex and requires careful planning and coordination

• Different standards, versions (e.g., SAML 2.0 vs. 1.1, OIDC variants), and vendor quirks often cause compatibility headaches, especially for legacy systems

Supporting Protocols

Protocol	Definition	Use
SAML/SAML 2.0	XML-based open standard for exchanging authentication and authorization data.	It is the most common protocol for enterprise federation, securely exchanging authentication and authorization data (assertions) between an IdP and SPs.
OAuth 2.0/OIDC	OIDC is an identity layer on top of the OAuth 2.0 authorization framework.	OIDC is a modern, lightweight, and API-friendly protocol often used for federation, especially in consumer-facing and mobile applications.
WS-Federation	A standard for federated identity management developed by Microsoft.	Used primarily in environments that rely on Microsoft technologies (e.g., Active Directory Federation Services).

Table 3: Supporting Protocols for Federation

Real-World Application

• Federation allows for secure access for vendors and partners. Businesses can grant their partners and vendors access to specific applications and resources using their own corporate credentials, without needing to create new user accounts in their systems

• During a company merger or acquisition, federation allows all employees to continue accessing necessary applications with their existing credentials, avoiding the need for immediate, large-scale identity migrations

• A company can use federation to provide employees with seamless access to various SaaS applications like Salesforce, AWS, or Zoom using their on-premises Active Directory or cloud-based IdP

• Secretless cross-cloud resources access/provisioning via workload identity federation. Modern multi-cloud architectures utilize OIDC-based workload identity federation to enable secure, keyless communication between different cloud providers. For instance, workloads running in one cloud (e.g., AWS) can provision/access resources in another cloud (e.g., GCP) through exchange of a native identity token for a short-lived access token (e.g., workload identity pool service account impersonation)

References

• https://csrc.nist.gov/pubs/sp/800/63/c/4/final
• https://www.okta.com/identity-101/what-is-sso/
• https://www.onelogin.com/learn/what-is-federation
• https://openid.net/specs/openid-sharedsignals-framework-1_0.html

Machine-to-Machine Authentication

Machine-to-machine (M2M) or non-interactive authentication is the process of securely verifying the identities of servers, devices, and automated systems without any human involvement. This ensures only authorized machines communicate and access resources across networks, supporting secure automation in cloud, DevOps, IoT, and enterprise environments, but it still requires a secure way for a machine to obtain its first credential, which is difficult and adds complexity.

In M2M authentication, it is important to distinguish machine identity from credentials. A machine identity uniquely identifies a workload, service, device, or agent (e.g., SPIFFE ID, cloud instance principal, service account). Credentials are what the machine presents to prove who it is (e.g., certificate, cryptographic token, API key).

How It Works

Modern M2M authentication often uses secretless mechanisms, where systems dynamically obtain or generate credentials on demand (e.g., cloud workload identities), reducing the risk of accidental exposure to humans. In other cases, machines (e.g., CI/CD pipeline agent or a monitoring service) use credentials like API keys, mutual TLS certificates (mTLS/X.509), OAuth 2.0 client credentials, or service account tokens to authenticate to remote systems or APIs. Upon successful authentication, the server issues tokens—often JWTs—that encode identity and authorization claims. These are used to request and enforce access, with permissions mapped to the machine’s identity, workload type, or configured policy.

Unlike human authentication, non-interactive authentication does not rely on MFA. Instead, security is achieved through strong binding to a workload identity using mechanisms such as mTLS or SPIFFE-based identities, where cryptographic proof is tied to the machine’s runtime identity and environment.

Typical mechanisms include:

• Certificates (mTLS/X.509): Machines authenticate by exchanging cryptographically signed certificates
• OAuth 2.0 Client Credentials: Services obtain and use access tokens from an authorization server, scoped to required resources
• API Keys and Service Account Tokens: Machines use shared secrets or managed identity tokens provisioned for non-human access
• JSON Web Tokens: JWTs carry claims and permissions related to the machine or workload for authorization decisions

Authentication is integrated with authorization systems, ensuring each machine’s identity is verified and authorized for specific actions, often using enforced policies and short-lived tokens.

Pros

• Enables secure, seamless, unattended operation of CI/CD pipelines, monitoring agents, microservices, and device networks
• Supports strong cryptographic controls, rotation of credentials, and granular permissions enforcement
• Centralized identity management and logging for compliance and incident response
• Streamlines onboarding, offboarding, and lifecycle management for large machine fleets and workloads
• Supports automated, centralized credentials and permissions management, thereby reducing risks from manual processes

Cons

• Proper lifecycle management (provisioning, rotation, revocation) can be operationally intensive, especially as environments scale and the number of machine identities grows.
• Client-side update friction can occur during server identity rotation. In large-scale multi-tenant cloud environments, replacing a deprecated server’s identity requires discovering and updating all distributed downstream clients that rely on specific mTLS certificates, which is operationally prohibitive without an advanced control plane or service mesh to manage identity abstraction
• Excess poorly managed credentials increase attack surface
• Stolen tokens or certificates can be replayed until they are expired
• Traditional M2M authentication lacks runtime adaptive access controls, requiring augmentation for risk-based or contextual policies
• Bridging identity systems and token formats across cloud environments and vendors is a complex task

Supporting Protocols

The backbone of M2M authentication relies on established identity and access management protocols:

• mTLS/X.509 Certificates: Mutual TLS allows machines to authenticate by exchanging cryptographically signed certificates
• OAuth 2.0 (RFC 6749) + Security BCP (RFC 9700) and OIDC: Used for delegated authorization and scoped token issuance

Note: OAuth 2.1 is in draft and consolidates OAuth 2.0 with modern security best practices.

For M2M scenarios, OAuth 2.0 Client Credentials flow is the primary standard for workload-to-workload authorization:

• Kerberos and LDAP: Enterprise integration standards for domain authentication and attribute retrieval

• SPIFFE/SPIRE: Provide standardized, platform-agnostic workload identities based on runtime attestation and enable mutual authentication across distributed systems

• API Keys and Service Account Tokens: Lightweight but less secure; still standard in legacy or low-sensitivity use cases

Beyond classical protocols, modern identity frameworks for autonomous agents integrate advanced cryptographic primitives:

• Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs): Enable persistent, portable, and cryptographically verifiable agent identities, with VCs attesting to attributes such as role, capability, or compliance

• Zero-Knowledge Proofs (ZKPs): Allow agents to prove possession of an attribute or compliance with a policy without exposing sensitive details, supporting privacy-preserving verification

Real-World Application

• CI/CD agents deploy code into production environments
• Monitoring and observability services ingesting telemetry with scoped permissions
• Workloads in Kubernetes clusters are authenticating to cloud APIs, databases, or internal services using service account tokens, SPIFFE identities, or short-lived credentials
• Autonomous financial agents are executing trades with signed, auditable credentials
• Healthcare AI systems verifying regulatory attestation credentials (e.g., HIPAA compliance) before accessing sensitive patient data
• Supply chain automation bots interacting securely with logistics, customs, and enterprise resource planning (ERP) APIs.

References

• Oauth 2.1: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13
• Kerberos: https://datatracker.ietf.org/doc/html/rfc4120
• SPIFFE/SPIRE: https://spiffe.io/
• ZKPs: https://doi.org/10.1137/0218012
• Agentic AI Identity & Access Management Whitepaper: https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach
• Identity Management for Agentic AI: https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf
• The OAuth2.1 Authorization Framework (The draft-ietf-oauth-v2-1-14) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
• Cloud Security Alliance. (2024). State of Non-Human Identity Security Survey Report. https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report

API Security

APIs utilize both human and machine identities. They are programmable interfaces between systems. Securing them means controlling who can access what, how, and under what conditions.

How it works

Users, applications, and systems authenticate themselves before accessing an API. Once verified, they are given credentials or tokens that define what they are allowed to do. The API checks these credentials with every request and applies access rules before sharing data or services. This helps ensure that only authorized users and systems can access the API.

Pros

• Granular Control: Enables precise access management for system-to-system communication
• Stronger Protection: Helps prevent unauthorized access, data leaks, and misuse of sensitive services.
• Easy monitoring: Makes it easier to track, audit, and detect unusual or suspicious API activity.

Cons

• Secret Sprawl: Managing thousands of API keys and client secrets increases the attack surface if not centralized
• Complexity: Requires specialized gateways to handle token validation and rate limiting

Supporting Protocols

Authentication Standards	Protocols	Description	Use Case
OAuth 2.0	RFC 6749 (Base)	Authorization framework for delegated access.	Modern web/mobile apps, SaaS integrations, SSO, etc.
OpenID Connect Core 1.0	Base protocol OAuth 2.0 for authentication	SSO, identity federation.	Secure user login across apps.
Mutual TLS (mTLS)	OAuth 2.0 + TLS	Certificate-based trust between client and server.	B2B API integrations, financial services, Zero Trust networks.
JSON Web Tokens (JWT)	Signed tokens carrying identity and claims.	Signed tokens for stateless identity across services.	Microservices communication, session tokens.
API Keys	Headers or query parameters (HTTP)	Basic static credentials, server-to-server communication.	Internal services, low-sensitivity API execution.
FAPI 2.0	OpenID Foundation Security Profile	Mandates PAR + DPoP/mTLS + PKCE for financial-grade and high-assurance API access .	Open banking, fast healthcare interoperability resources (FHIR) APIs, government portals requiring strong client authentication.

Table 4: Supporting Protocols for API Security

Note: Modern best practices favor short-lived OAuth 2.0 tokens, mTLS-backed mutual trust, or SPIFFE-based workload identity for secure, auditable workflows. Avoid static API keys for public or critical APIs whenever possible.

Real-World Application

In the healthcare system, a mobile health app wants to access a patient’s medical records from a hospital’s electronic health records (EHR) system. The app requests user authentication and consent using OIDC. Once the patient approves, the app receives an OAuth 2.0 access token (a JWT with specific scopes, like reading lab results). The app presents this token to the hospital’s FHIR API, which verifies the token’s authenticity and grants access as allowed by the user’s consent and token scope.

References

• OWASP Foundation. 2023. https://owasp.org/API-Security/editions/2023/en/0x11-t10/
• OWASP Foundation. 2025. https://owasp.org/www-project-api-security/
• OpenID Foundation. 2024. https://openid.net/specs/fapi-security-profile-2_0.html
• API Security from Concepts to Components. Okta. 2023. https://www.okta.com/resources/whitepaper-api-security-from-concepts-to-components-wpr/

How M2M Authentication and API Security Work Together

While M2M authentication and API security are closely related and are typically deployed together in NHI scenarios, understanding how they complement each other is important when designing secure programmatic access.

M2M authentication is concerned with verifying the identity of the caller. In other words, it proves that the workload, service, or device initiating the request is who it claims to be. This is achieved through mechanisms such as mTLS certificates, OAuth 2.0 Client Credentials, SPIFFE identities, or service account tokens. Without this layer, there is no reliable way to establish trust in the source of a request.

API security is concerned with controlling what an authenticated caller is permitted to do. It enforces access policies on the resource or endpoint being called. This is achieved through scoped OAuth 2.0 access tokens, JWT claim-based authorization, API gateway policies, or fine-grained permission rules. Without this layer, even a verified caller could access resources or perform actions beyond its intended scope.

In practice, these two layers operate sequentially. A service or workload first authenticates its identity through M2M authentication, and the receiving API then evaluates whether that authenticated identity is authorized to perform the requested action through API security. Several protocols, most notably OAuth 2.0, mTLS, and JWTs, appear in both contexts, but they serve different roles depending on the stage of the interaction. For example, mTLS may be used to establish mutual trust between two services during authentication, while OAuth 2.0 Client Credentials may then be used to obtain a scoped access token that governs what the authenticated service is permitted to access.

When determining which approach applies to a given scenario, consider the following: If the primary concern is proving the identity of the caller, refer to the Machine-to-Machine Authentication section. If the primary concern is controlling what an authenticated caller can access or do, refer to the API Security section. In most production environments, both concerns apply simultaneously, and both sections should be considered together when designing non-human identity and access controls.

Passwordless Authentication

Passwordless authentication in an enterprise context denotes authentication mechanisms that eliminate knowledge-based secrets (passwords) and instead rely on device-bound cryptographic credentials, biometric verification, or physical authenticators managed through standards such as FIDO2 and passkeys. Unlike legacy methods, such as single-factor passwords or passwords augmented by SMS/OTP, which are vulnerable to phishing, credential stuffing, replay attacks, and heavy administrative overhead, passwordless approaches place asymmetric keys or platform-bound secrets under user or device control, reducing centralized secret storage and thus attack surface. Enterprise deployments additionally integrate with IAM systems, conditional access policies, and compliance requirements (e.g., NIST SP 800-63 guidance), enabling stronger assurance levels while simplifying lifecycle tasks like provisioning, rotation, and revocation.

How It Works

Passwordless authentication workflows typically employ public-key cryptography where a relying party registers a public key while a private key remains on a user device or hardware authenticator (e.g., security keys, trusted platform module (TPM)-backed platform authenticators). During authentication, the server issues a challenge that the authenticator signs with the private key after local user verification (e.g., PIN, biometric, device unlock), and the server verifies the signature using the stored public key, establishing strong, phishing-resistant proof of possession. Federated and enterprise flows enhance this by incorporating device attestation, policy checks, and credential management via standards (e.g., FIDO2/WebAuthn, CTAP, and passkeys), enabling cross-device recovery, centralized policy enforcement, and alignment with NIST assurance levels, while minimizing reliance on shared secrets and reducing operational risk.

Pros

• Reduced phishing risk due to the use of asymmetric keys and device-bound authenticators instead of shared secrets
• Lower operational overhead by reducing password resets and simplifying credential lifecycle management
• Enhanced user experience and adoption by eliminating password friction and enabling fast, intuitive sign-ins across devices, while still leveraging phishing‑resistant, passwordless authentication (e.g., passkeys)
• Improved compliance alignment with NIST SP 800-63 recommendations for authenticators and multifactor assurance
• Stronger cryptographic assurance and phishing-resistant authentication through FIDO2/passkey standards and hardware-backed keys

Cons

• Device dependency and broken/stolen device recovery complexity is increased because secure, user-friendly credential recovery and cross-device sync (passkeys) introduce additional operational and security challenges
• Legacy integration challenges when connecting passwordless flows to older enterprise applications that expect passwords or SSO-unfriendly protocols
• Deployment and user training costs for procuring authenticators, updating IAM infrastructure, and upskilling administrators and users
• Potential vendor and platform lock-in risks tied to specific passkey sync ecosystems or proprietary authenticator implementations

Supporting Protocols

Protocol	Definition	Use
FIDO2/WebAuthn	Open authentication standard using public-key cryptography for web and native apps.	Registers and authenticates platform or roaming authenticators (e.g., passkeys, security keys) via public-key credentials and signed challenges.
OAuth 2.0	Authorization framework for delegated access to resources.	Issues access tokens after passwordless authentication (via WebAuthn or SSO) to allow apps/services to access APIs without passwords.
OIDC	Identity layer on top of OAuth 2.0 providing authentication and ID tokens.	Brokers user identity after passwordless proof (e.g., WebAuthn) to enable SSO, session creation, and federated access across enterprise apps.
SAML	XML-based federation protocol for exchanging authentication/authorization assertions.	Accepts assertions from an IdP that performed passwordless authentication to grant SSO into legacy enterprise applications.
Private Key Storage APIs (e.g., TPM / PKCS#11 )	Hardware-backed key storage and cryptographic APIs (e.g., TPM, smart cards, HSMs, PKCS#11).	Protects and performs private-key operations for authenticators or enterprise-managed credentials, enabling secure, attested passwordless operations.

Table 5: Supporting Protocols for Passwordless Authentication

Real-World Application

Rising phishing, credential stuffing, and ransomware campaigns have prompted enterprises to adopt passwordless controls that reduce exposed secrets and enhance resilience against account-compromise attacks. Two industry use cases that would benefit from the adoption of passwordless authentication are found in finance and healthcare:

• A global financial services firm replaced legacy VPN and remote-access passwords with FIDO2-based hardware keys and device attestation to mitigate phishing, meet NIST AAL2/AAL3 requirements, and simplify cross-border compliance reporting

• A large healthcare network implemented platform passkeys and centralized OIDC brokering for clinician SSO to EHRs and cloud labs, reducing password resets, enabling biometric local verification, and ensuring hardware-backed keys align with audit and patient-data protection policies, minimizing password fatigue and supporting compliance with healthcare audit standards

References

• https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work
• Your Guide to FIDO2 Passwordless Authentication (source: PingIdentity)
• FIDO2 passwordless authentication (source: Yubico)
• Passkeys (source: FIDO Alliance)
• NIST SP 800-63 Digital Identity Guidelines (source: NIST)
• NIST Password Guidelines: 2025 Updates & Best Practices (source: StrongDM)
• OpenID Foundation. (2024). Financial-grade API Security Profile 2.0 — Part 1: Baseline. https://openid.net/specs/fapi-2_0-security-02.html

Biometric Authentication

Biometric authentication uses unique physical traits (e.g., fingerprints, face, voice) or behavioral traits (e.g., keystroke dynamics, touchscreen gestures, mouse movement patterns) to verify identity. Biometrics are most often used as a second factor in MFA or to unlock passwordless credentials on devices.

How It Works

Biometric authentication relies on the user’s unique biometric identification features like fingerprints, iris, retina, and facial or voice patterns. When the user authenticates using biometrics, the system captures a live sample of the features and compares it against the stored template registered upon initial login. Biometric login can combine multiple features, such as fingerprint and retina scan (multimodal) for improved accuracy and security, or use a single feature, like facial recognition. In addition to multimodal verification, challenge responses for liveness detection can act as a deterrent against biometric fraud from static or spoofed samples.

Pros

• Less overhead and faster login in many cases
• Easy to use as users cannot forget biometrics like they can forget a password

Cons

• Not fully compatible with all systems, especially legacy systems
• Biometrics are non-rotatable, so once compromised they are compromised forever
• If not implemented correctly, high false positives and negatives
• Not suitable for machine identity and authentication
• Exploits or vulnerabilities with the IdP implementation can allow authentication to bypass, especially when a biometric is used as a single factor
• Improper storage of biometric data can pose a security risk and violate privacy laws and regulations
• Deepfake videos and photos can potentially pass for facial recognition

Supporting Protocols

Protocol	Definition	Use
FIDO 2.0/WebAuthn	Passwordless authentication standard.	FIDO2/WebAuthn uses public key cryptography with device-bound credentials. A private key is securely stored on the user’s device, and local user verification (e.g., fingerprint, face) unlocks the key. The device signs a server-provided authentication challenge, and only the signed response is sent to the server, which verifies it using the registered public key. Biometric data never leaves the device.
Secure Remote Biometric Authentication (SRBA)	A research-oriented remote authentication protocol that uses encrypted biometric templates and a challenge–response mechanism.	It ensures secure remote access, protecting against replay and man-in-the-middle attacks.
Fuzzy Vault or Fuzzy Commitment	Cryptographic protocol that locks a key with a biometric features; only correct biometric unlocks the key.	Biometric unlocks a cryptographic key, which acts as one factor in MFA, and another one combined with a device or password factor (e.g, secure access systems using iris or fingerprint templates to encrypt cryptographic keys).

Table 6: Supporting Protocols for Biometric Authentication

Real-World Application

Companies allowing access to internal applications on mobile phones can mandate the requirement of biometrics on user’s devices. This adds a layer of protection to prevent unauthorized access.

A good example is FIDO2/WebAuthn, used by Google, Microsoft, and banks to log in with fingerprint or face ID. A user’s biometric unlocks a device-stored private key to verify their identity, and the raw data never leaves the device, keeping it very secure. This is a passwordless, device-based protocol.

Another example is Fuzzy Vault, used in government systems and research labs to protect cryptographic keys with iris or fingerprint scans. Only the correct biometric can unlock the key, which can then serve as a factor in MFA. This protocol focuses on cryptographic biometric template protection.

References

• https://support.apple.com/en-us/102381

Identity for AI Agents

Identity for AI Agents refers to the secure authentication, authorization, and lifecycle management of “Agentic AI” autonomous software entities that make decisions, execute workflows, and call APIs with minimal human intervention. Unlike traditional software that executes predetermined instructions, AI agents exhibit flexible, non-deterministic behavior. Assigning distinct, cryptographically verifiable identities to these agents ensures that they do not simply impersonate human users, enabling organizations to maintain strict accountability, least-privilege access, and governance over autonomous actions.

How It Works

AI agents are provisioned with their own dedicated identities within an organization’s IdP. When an agent needs to perform an action on behalf of a human user, it does not use the human’s password or full access token. Instead, it utilizes delegation protocols such as OAuth 2.0 Token Exchange (RFC 8693). The agent authenticates itself and requests a delegated token that represents the user, subject to policy controls enforced by the authorization server.

Crucially, this token undergoes scope attenuation, meaning its permissions are restricted (down-scoped) to only the exact tasks the agent is authorized to perform. For interactions with external tools and data sources, agents may rely on the Model Context Protocol (MCP), which can leverage standard OAuth 2.x authorization flows to establish secure, authorized connections. To reduce the risk of token replay if exfiltrated, tokens can be sender-constrained using cryptographic mechanisms such as Demonstrating Proof-of-Possession (DPoP) or mTLS, binding the token to the agent’s key material.

Pros

• Enforces Least Privilege: Scope attenuation ensures that even if an AI agent hallucinates or is compromised, its blast radius is limited strictly to its assigned permissions

• Clear Auditability: Because agents have distinct identities, security teams can differentiate between human activity and automated agent activity in access logs

• Human-in-the-Loop Security: High-risk actions can trigger step-up or out-of-band authentication (for example, a confirmation from the human user) before the agent is allowed to proceed

Cons

• Delegation Complexity: Tracking the chain of authority from a human down through multiple layers of autonomous sub-agents is technically complex

• Lifecycle Management Overhead: AI agents can be instantiated and terminated dynamically, creating a high volume of NHIs that may result in orphaned credentials if not governed properly

• Legacy Incompatibility: Older systems may not support delegated tokens, token exchange, or sender-constrained access tokens, limiting interoperability

Supporting Protocols

Protocol	Definition	Use
OAuth 2.0 Token Exchange (RFC 8693)	Delegation framework	Allows an agent to exchange one security token for another (e.g., its own token for a delegated, down-scoped token) to act on behalf of a user or another principal, subject to authorization server policy.
Model Context Protocol (MCP)	Open standard for AI tool integration	Defines a structured interface for connecting LLM-based agents to external tools and APIs; authorization is typically handled using OAuth 2.x or equivalent mechanisms supported by the target system.
Demonstrating Proof-of-Possession (DPoP)	Sender-constraining mechanism for OAuth tokens	Cryptographically binds an access token to the agent’s private key, reducing the risk of replay by an attacker in possession of a stolen token.
Continuous Access Evaluation Profile (CAEP)	Event-based session revocation framework	Enables near real-time notification from identity systems to relying parties so that an AI agent’s session or token can be revoked or re-evaluated in response to risk events.

Table 7: Supporting Protocols for Identity for AI Agents

Real-World Application

• Executive Assistant Agent: An enterprise AI agent is tasked with reading an executive’s emails and scheduling meetings. Instead of holding the executive’s password, the agent uses OAuth 2.0 Token Exchange to receive a token limited strictly to calendar.write and email.read scopes. If the agent attempts to delete a file in a shared drive outside its granted scopes, the system denies the request, preventing unauthorized data modification

• Automated Customer Support: A customer service AI agent resolves user tickets autonomously. It is registered in the directory as a unique NHI. When it interacts with a customer relationship management (CRM) system via an MCP-compatible integration, every API call is logged under the agent’s distinct identity, allowing security teams to reconstruct its activity trail for compliance and forensic purposes

References

• OpenID Foundation. (2025). “Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world.” Available at: https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf

• Anthropic. “Model Context Protocol (MCP) Authorization.” Available at: https://modelcontextprotocol.io/docs/tutorials/security/authorization

• Cloud Security Alliance. (2025). “Agentic AI Identity and Access Management: A New Approach.” Available at: https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach

Authorization

Authorization refers to the act of granting or denying access to an action or resource according to an organization’s or system’s defined permissions or policies. After a user’s identity has been verified, authorization determines what resources or actions a user can access, modify, or execute.

This section covers details on the most common authorization models (e.g., RBAC, ABAC, ReBAC, PBAC) and the protocols, frameworks, or standards used to implement them.

Role-Based Access Control

RBAC, or role-based access control, is a prevalent security practice that organizes access permissions by users’ roles within an organization. Rather than granting individual access rights, RBAC associates permissions with pre-established roles, and users are assigned to these roles based on their job functions. This approach centralizes and simplifies the management of access policies, offering consistency and control over who can do what across systems and applications.

RBAC is built on four fundamental elements:

• Users: Individuals who need access to systems and resources (e.g., employees, contractors, partners)

• Roles: Named collections of permissions that represent job functions within the organization (e.g., Administrator, HR Manager, Analyst, Engineer). Roles serve as the bridge between users and permissions

• Permissions: Specific access rights to resources or operations (e.g., read employee records, approve purchase orders, modify configuration settings, delete files)

• Assignments: There are two types of mappings that define the RBAC model:

  • User-Role Assignment: Links users to roles based on their job responsibilities
  • Permission-Role Assignment: Defines which permissions each role possesses

When a user is assigned to a role, they automatically inherit all permissions associated with that role. Changing a user’s assigned role(s) instantly updates their access, making onboarding, offboarding, and duty changes simple to manage. This centralized approach simplifies administration; modifying a role’s permissions instantly affects all users assigned to that role.

RBAC has certain advantages for organizations with well-defined job functions and hierarchical structures. It makes granting and revoking access privileges on a per-user basis easier, reduces administrative overhead, and applies least privilege uniformly. Moreover, it is easy to audit access by auditing role definitions. However, RBAC becomes rigid and cumbersome in dynamic environments where user needs change frequently. One common pitfall is “role explosion,” in which too many roles are created to provide every possible set of permissions, diminishing the ease of administration that RBAC seeks to provide. RBAC does not accommodate context-awareness either; it cannot take into account dynamic factors such as time of access or device type without augmentation by other models.

While RBAC is commonly described using four core elements—users, roles, permissions, and assignments—practical implementations often include additional components such as role hierarchies, groups, constraints, and separation-of-duty policies.

How It Works

RBAC functions by establishing roles that reflect organizational activities (e.g., administrator, analyst, HR manager) and assigning specific permissions to each of the roles. The users inherit the permissions of the roles to which they belong. For instance, an “HR Manager” role may have access to employee files, while a “Recruiter” role may have access to only job candidates. The access decisions are made solely based on the roles and their pre-established permissions, thus making the model simple to audit, manage, and enforce.

RBAC is most effective when user lifecycle management—onboarding, role changes, and offboarding—is fully automated. For instance, an automated system would grant Employee X access to Role Y upon joining a new team. Later, if the employee is promoted or transfers, the system would automatically revoke Role Y and assign Role Z, which corresponds to the new function. Finally, when the employee leaves the company, all access roles are automatically removed as part of the HR offboarding process.

A critical security principle enforced through RBAC is a Separation of Duties (SoD), which ensures that no single user can complete a sensitive transaction alone. SoD prevents fraud and errors by requiring multiple people to participate in critical processes.

For example:

• One role can create purchase orders, while a different role must approve them
• A “Developer” role is allowed to write code, but only a “Release Manager” is allowed to deploy to production
• An “Accountant” role can record transactions, but only an “Auditor” can approve financial reports

RBAC enforces SoD by designing mutually exclusive roles, so users cannot be assigned to conflicting roles simultaneously. Organizations define “toxic combinations” (incompatible role pairs) that the system prevents, such as assigning someone both “Purchase Order Creator” and “Purchase Order Approver” roles.

Pros

• Simplicity: RBAC enables easy assignment of permissions through role mappings, making it ideal for offboarding and onboarding

• Auditability: Fewer, central definitions of access enable security teams to audit who is accessing what more simply

• Consistency: Roles ensure consistent access permissions across all users for a given function, removing the risk of human error

• Maintainability: Modifying access for a group of users is as simple as altering the role’s permissions rather than altering each user individually

• Compliance: RBAC facilitates regulatory compliance by restricting access to sensitive resources and simplifying access reviews

Cons

• Role Explosion: As organizations grow, the number of roles can multiply rapidly, making the system difficult to manage and maintain

• Lack of Flexibility: RBAC struggles to adapt to dynamic environments where access decisions depend on attributes like time, location, or device posture

• Administrative Overhead: Continuous monitoring, updating, and reviewing of roles are necessary to keep up with organizational changes

• Conflicting Roles: Assigning multiple roles to users can lead to conflicting permissions or toxic combinations, increasing security risk

Supporting Protocols

Protocol	Definition	Use
LDAP	Lightweight Directory Access Protocol for querying directory services	Stores and retrieves user-role mappings. Applications query LDAP to determine user roles.
SAML 2.0	XML-based federated identity protocol	Encodes user roles as attributes in SAML assertions passed to SPs.
OAuth 2.0/OIDC	Token-based authorization and identity protocols	ID and access tokens include role claims to determine permissions at the application level.
JWT	JSON-based token format used to carry claims	Roles are embedded in claims, such as “roles”: [“admin”] and are evaluated during authorization.
SCIM	System for Cross-Domain Identity Management	Automates provisioning of users and roles across multiple systems.

Table 8: Supporting Protocols for RBAC

Real-World Application

Organizations that successfully apply RBAC typically operate in environments where job roles are clearly defined, stable, and aligned with least-privilege principles. Access is centrally managed and often supported by automation across the user lifecycle, providing visibility into what roles exist, the permissions associated with them, and which users hold those roles. These characteristics make RBAC well suited for predictable access patterns where permissions map directly to organizational responsibilities and change infrequently.

Examples of RBAC use cases include:

• Access Control to Business Applications: For access to applications such as Microsoft 365 or Google Workspace, employees, managers, and HR personnel are assigned permissions based on predefined roles and responsibilities. For instance, the HR department may have access to employees’ files, and engineers require access to the repository. Because access needs correspond directly to organizational jobs and do not frequently change, RBAC simplifies administration and auditing. It is most effective when the company prioritizes clarity, manageability, and compliance with regulations over fine-grained flexibility. In such cases, implementing other authorization methods (e.g., ABAC, PBAC) would be unnecessarily complex

• Cloud Storage Management: In this scenario, users are assigned roles such as “Storage Admin” or “Storage User.” A Storage Admin can create and delete storage buckets, manage user permissions, and configure backup settings, ensuring they have full control over the environment. In contrast, a Storage User is limited to uploading, downloading, and viewing files within specific buckets assigned to them, with no ability to alter permissions or bucket configurations. This separation of roles helps prevent accidental or unauthorized changes to critical infrastructure, while still enabling users to perform their day-to-day tasks efficiently.

References

• https://csrc.nist.gov/projects/role-based-access-control
• https://idpro.org/a-taxonomy-of-modern-authorization-models/
• Sandhu et al., 1996 – “Role-Based Access Control Models” Title: Role-Based Access Control Models – IEEE Computer DOI: 10.1109/2.485845
• https://www.cl.cam.ac.uk/~rja14/book.html

Attribute-Based Access Control

Attribute-based access control (ABAC) is a fine-grained authorization model that makes access decisions by evaluating attributes associated with users, resources, actions, and environmental conditions. Unlike role-based models that rely solely on static job functions, ABAC evaluates multiple dynamic factors such as time of day, location, device security posture, and data sensitivity to determine access rights at runtime. This attribute-driven approach enables organizations to create highly precise, context-aware security policies that adapt to changing conditions and requirements. ABAC is especially suited for large, dynamic organizations or industries with heavy compliance needs.

ABAC evaluates access requests using several key elements:

• Subject Attributes: Characteristics of the user or entity requesting access (e.g., job title, department, security clearance, role, employee ID)

• Resource Attributes: Properties of the item being accessed (e.g., classification level, owner, creation date, document type, sensitivity label)

• Action: The operation being requested (e.g., read, write, delete, share, download)

• Environment Attributes: Contextual conditions at the time of access (e.g., time of day, location, IP address, device type, current threat level)

• Policies: Rules that combine these attributes to make access decisions (e.g., “Allow if subject.department = ‘Finance’ AND resource.type = ‘Financial Report’ AND environment.location = ‘Corporate Network’”)

• Policy Decision Point (PDP): The engine that evaluates policies against attributes and makes access decisions

• Policy Enforcement Point (PEP): The component that enforces the PDP’s decision by granting or denying access

• Policy Information Point (PIP): Attribute service that gathers information about user, resource, and environment so that PDP can make necessary decisions

• Policy Administration Point (PAP): The service that manages create, read, update, delete—collectively known as CRUD—and publish operations on access policies

• Policy Retrieval Point (PRP): The service that indexes policies to quickly identify what access policies apply for a given service or request context

How It Works

To approve or deny access, ABAC policies are evaluated in real time based on the latest values of all relevant attributes. For example, a request from a manager in the finance department to download a spreadsheet at 2 a.m. from a personal laptop could be denied even if the same request at 10 a.m. from a corporate laptop would succeed. Governance is essential: attributes must be trustworthy, regularly updated, and kept free from unneeded or outdated entries.

Attributes are the core of ABAC, and they could be classified into four main types:

• Identity: Identity attributes (e.g., name, organization, job title, security clearance) and system identity

• Resource: Resource properties such as owner, creation date, or file type

• Environment: Environmental specifics such as time of day, location of access, and threat levels

• Action: Operation the user wants to perform on a resource (e.g., read, write, delete, edit, approve)

ABAC operates through six core capabilities that align with industry-standard architecture:

• Policy Creation and Management: Policy owners create access control policies based on attributes of identities (e.g., employees, applications), resources (e.g., data, tables, APIs), actions, and environmental factors (e.g., region, application environment). Policies can be created through visual interfaces, code editors, or API calls and can protect resources at both broad levels (entire tables) or granular levels (specific columns and rows)

• Attribute Management: Attributes form the foundation of ABAC and fall into four categories: identity, resource, environment, and action attributes. Policy owners can use standard attributes already available from existing systems (e.g., job level, location, user role) or integrate their own custom attributes (e.g., patient appointments) by connecting to their attribute providers. A centralized registry manages resource schemas and data classifications, ingesting classifications from data governance platforms and providing verification interfaces for data owners to confirm classification tags. For large-scale systems where row-level tagging isn’t feasible, the system enables dynamic classification through column and schema-level rules evaluated at runtime

• Service Integration: Service owners register their services and select from multiple authorization engine options, including local libraries for various programming languages, remote authorization services, or unified authentication layers. Modern integration approaches have reduced onboarding efforts from 2 days to approximately 3 hours

• Policy Deployment and Testing: Policies are grouped into bundles and deployed to service environments through staged deployment pipelines or direct-to-host mechanisms. Before deployment, policy owners can test evaluation decisions by simulating requests in a testing environment. The system checks for policy conflicts and allows users to resolve them by setting precedence rules. New policy bundles can be deployed in shadow mode to test behavior with existing traffic without enforcement, while analytics capture decisions for impact reporting

• Authorization Engine: The evaluation engine provides authorization decisions with configurable caching for latency-sensitive services and centralized services for remote authorization. It supports multiple authorization patterns: individual authorization decisions with detailed permissions, batch authorization for iterative processes, and listing all accessible resources for a given user

• Compliance Programs: Compliance programs reduce implementation and maintenance effort for data governance initiatives. These programs ingest all classified datasets from data governance platforms, trigger verification processes with dataset owners when data types fall within program scope, and ensure planned controls are deployed to services handling in-scope data, creating a closed-loop system for data handling compliance

ABAC makes it possible for organizations to implement extremely granular yet flexible security policies that can be implemented across a wide variety of resources. Not only does this make security policies adaptable to changing business requirements, but it keeps security tight with the ability to add or modify policies as needs arise.

The granularity of ABAC policies means that it takes significant time and resources to create and apply attributes to users and resources. Likewise, maintaining that level of detail is also challenging for administrators of large, growing, or dynamically changing teams.

By evaluating attributes of both subjects and resources, ABAC allows for more flexibility in policy creation and enforcement. With ABAC, access is dynamic. Decisions can be made according to context and risk at runtime. ABAC policies can be enforced on servers, databases, clusters, and a host of other resources.

Pros

• Granularity: Because it uses attributes rather than roles to specify relationships between users and resources, administrators can create precisely targeted rules without needing to create additional roles

• Control: With ABAC, data teams can restrict access to personally identifiable information (PII) using tags. In the healthcare field, for example, administrators can connect tags to HIPAA privacy standards to automatically separate those who have access from those who don’t

• Flexibility: ABAC policies are easy to adapt as resources and users change. Rather than modifying rules or creating new roles, admins need only assign the relevant attributes to new users or resources

• Adaptability: ABAC makes adding and revoking permissions easier by allowing admins to modify attributes. This simplifies onboarding and offboarding as well as the temporary provisioning of contractors and external partners

• Security: ABAC allows admins to create context-sensitive rules as security needs arise so they can more easily protect user privacy and adhere to compliance requirements—without requiring a high degree of technical knowledge

Cons

• Resource Intensive: ABAC may require more expensive tools and greater administrative overhead compared to simpler models like RBAC

• High Complexity: Designing and implementing ABAC policies are more complex due to the need to define and manage a wide range of attributes for users, resources, and environments

• Scalability Challenges: As the users, resources, and attributes grow, managing and updating attributes and policies becomes increasingly difficult

• Attribute Governance Challenges:

  • Attribute Sprawl: Accumulation of unused or redundant attributes over time
  • Attribute Quality: Ensuring attributes are accurate, current, and trustworthy
  • Attribute Sources: Managing attributes from multiple systems (e.g., HR, IT, security)
  • Attribute Lifecycle: Keeping attributes synchronized as users and resources change
  • Attribute Standards: Establishing consistent naming and format conventions

Supporting Protocols

Protocol	Definition	Use
XACML	XML-based standard for access control policy language and decision requests	Evaluates policies based on user, resource, and environment attributes.
SAML 2.0	XML-based identity federation protocol	Attributes (e.g., department, clearance level) are included in assertions for policy checks.
OAuth 2.0/OIDC	Token-based protocols for authorization and identity	Tokens carry user and session attributes for fine-grained access control.
JWT	Token format with embedded claims	Attributes in claims are used in authorization decisions (e.g., “clearance”: “high”).
SCIM	Provisioning protocol for identities and attributes	Ensures identity attributes used in policies are synchronized and up to date.

Table 9: Supporting Protocols for ABAC

Real-World Application

ABAC is paramount in environments where decisions about access are made based on numerous dynamic attributes. A good example is a university’s Learning Management System (LMS). Users such as students, instructors, and assistants would likely require access based on course enrollment, semester, or academic department. This would quickly lead to a roles explosion when administering with RBAC, rendering policy management unmanageable. ABAC facilitates this process by evaluating user, resource, and environment attributes at runtime. It applies in sectors like education, healthcare, and finance where access requirements change continuously and are circumstance-dependent. ABAC is scalable and adaptable, although it requires robust attribute governance.

On cloud platforms, ABAC enables organizations to control access to resources such as storage buckets or virtual machines by evaluating a wide array of attributes. For example, a user’s ability to access a particular storage bucket could depend on their department (e.g., marketing, finance), the specific project they are assigned to, and their current location. A marketing analyst working on a campaign may be allowed to upload and view files only if they are connected from a company-approved device and are physically located within the United States. If the analyst attempts access from an unapproved device or an overseas location, the system automatically denies access. This level of granularity makes ABAC especially valuable in large, distributed organizations where access needs change frequently and must be tightly controlled.

References

• NIST Special Publication 800-162 (2014). “Guide to Attribute-Based Access Control (ABAC) Definition and Considerations.” Available at: https://csrc.nist.gov/publications/detail/sp/800-162/final
• Hu, V. C., et al. (2014). “Guide to Attribute-Based Access Control (ABAC) Definition and Considerations.” NIST SP 800-162. DOI: 10.6028/NIST.SP.800-162
• https://www.strongdm.com/what-is/attribute-based-access-control-abac
• https://rosettadigital.com/rbac-vs-abac-vs-pbac-2/

Relationship-Based Access Control

Relationship-based access control (ReBAC) is an authorization model that determines access based on the relationships between entities such as users, resources, and groups. Instead of relying on predefined roles or static attributes, ReBAC evaluates how entities are connected to one another. This makes it well-suited for environments where access depends on ownership, collaboration, or social connections that change frequently.

For example, in a social network, a user may share a photo visible only to “friends of friends.” In a business setting, an employee may access reports owned by their direct reports or collaborate on files shared within their project team. These types of relationship-driven rules are difficult to express with traditional RBAC or ABAC models but are a natural fit for ReBAC.

ReBAC operates on a graph-based model, where nodes represent entities and edges represent the relationships between them. The main components are:

• Subjects: Users or agents requesting access (e.g., employees, contractors, partners)
• Objects: Resources being accessed (e.g., files, records, projects)
• Relationships: Links between subjects and objects, or between subjects themselves, describing how they are connected (e.g., owns, manages, member_of, collaborates_with)
• Permissions: Permissions are dynamically derived from relationship paths rather than being statically assigned as in RBAC models
• Policies: Rules that define which relationships grant or restrict access (e.g., “allow access if the user manages the owner of this document,” “allow view if friend_of the owner”)

How It Works

When a user requests access to a resource, the ReBAC system (authorization engine) evaluates the relationship graph to determine whether a policy-compliant path exists that satisfies the defined policy. Access decisions are made dynamically based on these relationships, often stored in a graph database or directory. For instance:

• A manager can view reports owned by employees they manage (manage relationships)
• A project collaborator can edit documents shared within their project (member_of relationship)
• A customer service agent can access tickets for customers they support (supports relationship)

The relationships can be direct (user → document) or transitive (user → team → document). Access decisions typically use graph traversal logic or query evaluation to find paths that meet policy conditions.

Pros

• Fine-Grained and Dynamic: Access automatically adapts as relationships change, eliminating the need for manual updates

• Natural Modeling for Collaboration: Ideal for systems where sharing and delegation depend on social or organizational connections

• Reduced Administrative Overhead: No need to maintain large sets of roles or attributes; access follows existing organizational or system relationships

• Supports Delegated Access: Enables real-world delegation patterns, such as assistants accessing their manager’s calendar

Cons

• Graph Complexity: Relationship graphs can grow large and make traversal computationally expensive without optimization or caching

• Auditing Challenges: Relationship-based policies can be harder to audit compared to role or attribute mappings

• Policy Governance: Requires careful design to avoid unintended access through indirect or inherited relationships

• Integration Effort: Traditional enterprise systems built on RBAC or ABAC may require redesign to support relationship models

• Governance of Transitive Relationships: Because ReBAC allows access to be inherited through chains of relationships (e.g., user → team → folder → sub-folder), users can gain permissions indirectly. Without proper graph visualization or auditing tools, this “hidden access” can make it difficult for security teams to identify excessive entitlements during access reviews

Real-World Application

A practical and widely understood example of ReBAC is how access works in collaborative file-sharing platforms, such as Google Drive.

When a user creates a document or folder, they establish a foundational relationship (the owner). They can then share that resource with others, assigning them specific roles like viewer, commenter, or editor. Access is not determined by a user’s company-wide job title (a static role) but by their relationship to the specific resource and any inherited permissions. For instance, if a file is nested within a folder, the file automatically inherits the permissions of the parent folder. To determine authorization, the system traces this path from user to is_member → team to is_editor → folder to contains → document. If the owner revokes sharing, a collaborator leaves the team, or the document is moved to a private folder, their relationship and, therefore, their access changes instantly. This dynamic, relationship-driven model provides the fine-grained, real-time control necessary to reflect how people naturally collaborate in digital environments.

References

• NIST: https://csrc.nist.gov/projects/role-based-access-control
• IDPro: A Taxonomy of Modern Authorization Models https://idpro.org/a-taxonomy-of-modern-authorization-models/
• Sandhu et al., 1996 — Role-Based Access Control Models, IEEE Computer, DOI: 10.1109/2.485845
• Anderson, R. — Security Engineering: https://www.cl.cam.ac.uk/~rja14/book.html

Policy-Based Access Control

Policy-based access control (PBAC) is an authorization model that centralizes access decisions within explicit, externalized policies evaluated at runtime. PBAC separates policy definition, administration, and enforcement into distinct architectural components. This separation enables organizations to manage complex access control requirements through centralized policy repositories, version-controlled policy languages, and dedicated policy decision engines.

PBAC architectures often draw on architectural concepts introduced by XACML from OASIS Open, and many modern policy engines adopt similar patterns for policy evaluation and enforcement:

• PAP: The interface where policies are created, edited, tested, and version-controlled. PAPs often integrate with developer workflows, enabling policy-as-code practices with CI/CD pipelines, automated testing, and peer review

• PDP: The engine that evaluates access requests against policies. When an application needs an authorization decision, it sends a request containing subject attributes (who is requesting access), resource attributes (what is being accessed), action (what operation), and environmental context (when, where, why). The PDP retrieves applicable policies from the policy repository, evaluates them against the request, and returns a decision (permit, deny, or not applicable)

• PEP: The component within applications or infrastructure that intercepts access requests and enforces PDP decisions. PEPs are typically implemented as API gateways, reverse proxies, or application middleware

• PIP: External data sources that provide attribute values needed for policy evaluation. PIPs might query user directories (e.g., LDAP, Active Directory) for user attributes (e.g., HR systems for employment status)

• Policy Repository: The centralized storage for policies, policy sets, and metadata. Repositories support versioning (tracking policy changes over time), rollback (reverting to previous policy versions), and access control (restricting who can modify policies)

Pros

• Centralized Policy Management: Policies are defined, versioned, and governed in a single repository, making it easier to maintain consistency and track changes over time

• Separation of Concerns: The clear division between policy administration, decision, and enforcement allows teams to manage access logic independently from application code

• Auditability: Externalized, version-controlled policies provide a clear and traceable record of access rules, simplifying compliance reviews and incident investigation

• Flexibility and Expressiveness: PBAC policies can express role-based, attribute-based, relationship-based, or hybrid access rules within the policy engine, making it adaptable to a wide range of access control requirements without changing the architecture

• Policy-as-Code Support: Many PBAC implementations support integration with CI/CD pipelines, enabling automated testing, peer review, and rollback of policy changes, reducing human error and accelerating deployment

Cons

• Latency Overhead: Every access decision requires a request to the PDP for policy evaluation, which can introduce latency, particularly in high-throughput or real-time environments without caching. Latency can be mitigated by deploying the PEP/PDP alongside the application, using sidecars in service mesh architectures or implementing caching strategies

• Implementation Complexity: Designing a well-structured policy hierarchy, integrating PEPs consistently across applications, and connecting PIPs requires significant planning and technical expertise

• Policy Sprawl Risk: As the number of policies grows, maintaining clarity, avoiding conflicts, and ensuring consistent combining logic becomes increasingly difficult without strong governance practices

• Dependency on PDP Availability: Centralized PDPs create a dependency on their availability. High-availability deployments, caching mechanisms, and fail-safe strategies are required to prevent access outages

• Steep Learning Curve: Teams unfamiliar with policy languages (e.g., XACML, Rego) and the PAP/PDP/PEP architecture may face a significant onboarding and training investment

How It Works

When a user attempts an action on a resource, the request flows through the PBAC architecture:

1. Request Interception: The PEP intercepts the access request. For example, when a user attempts to view a financial report via a web application, the application’s PEP intercepts the HTTP request before processing it.

2. Context Assembly: The PEP constructs an authorization request containing all relevant context:

   1. Subject: {userId: “employee-12345”, department: “Finance”, clearanceLevel: “Secret”, roles: [“Analyst”], certifications: [“CFA”], lastTraining: “2024-10-15”}

   2. Resource: {reportId: “Q3-Financials”, classification: “Confidential”, owner: “CFO”, dataCategories: [“Revenue”, “EBITDA”]}

   3. Environment: {timestamp: “2024-11-08T14:30:00Z”, sourceIP: “10.0.5.42”, deviceCompliant: true, location: “US-East”}

   4. Action: “view”

3. Policy Retrieval: The PDP receives the request and retrieves all applicable policies from the policy repository. Policies are typically organized hierarchically and combined using policy combining algorithms.

4. Attribute Resolution: If policies require attributes not present in the request, the PDP queries PIPs.

5. Policy Evaluation: The PDP evaluates policies against the enriched request context.

6. Decision Rendering: The PDP returns a decision to the PEP: Permit (allow access), Deny (reject access), NotApplicable (no policies matched), or Indeterminate (error during evaluation).

7. Enforcement: The PEP enforces the decision. If Permit, the application proceeds with the requested operation, potentially fulfilling any obligations (e.g., audit logging, notifying data owners). If Deny, the application blocks the request and may log the attempted access for security monitoring.

Modern authorization systems increasingly adopt PBAC architectures to implement whatever access control model fits their requirements, gaining the benefits of centralization, auditability, and policy-as-code.

References

• OASIS. (2013). “eXtensible Access Control Markup Language (XACML) Version 3.0.” Available at: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

• NIST. (2014). “Guide to Attribute-Based Access Control (ABAC) Definition and Considerations.” NIST Special Publication 800-162. Available at: https://csrc.nist.gov/publications/detail/sp/800-162/final

• Hu, V. C., et al. (2014). “Guide to Attribute-Based Access Control (ABAC) Definition and Considerations.” NIST SP 800-162. DOI: 10.6028/NIST.SP.800-162

• Open Policy Agent Documentation. (2024). “What is OPA?” Available at: https://www.openpolicyagent.org/docs/latest/

• IDPro. (2023). “A Taxonomy of Modern Authorization Models.” Available at: https://idpro.org/a-taxonomy-of-modern-authorization-models/

Differences Between RBAC, ABAC, ReBAC, and PBAC

Feature	RBAC	ABAC	ReBAC	PBAC
Full Form	Role-Based Access Control	Attribute-Based Access Control	Relationship-Based Access Control	Policy-Based Access Control
Access Based On	User’s role	Attributes (user, resource, environment)	Relationships between entities (graph)	Policies written using conditions
Example	The manager can approve requests.	An HR employee in the office can access salary data.	A user can edit a file because they are “editor” of the parent folder.	Policy: Only HR can view salaries during work hours.
Flexibility	Low	High	High	Very High
Setup Complexity	Easy	Medium to Hard	Hard (requires graph data model)	Complex
Best For	Simple systems with clear roles	Systems needing detailed control	Social networks, collaborative apps, hierarchical data	Complex systems needing rule-based access
Example	Role = Editor	Department = Finance, Location = USA	User → member_of → Finance Team → collaborator_on → Project	Policy = Employee must be full-time AND on site
Real-World Use	The teacher can access the grade system.	A student can view the course only if enrolled.	A user can view a post because they are “friends” with the author.	Only teachers can edit grades from the school network.

Table 10: Differences Between RBAC, ABAC, ReBAC, and PBAC

Note: In practice, IAM architectures often combine RBAC, ABAC, and PBAC, as these models are not mutually exclusive.

Access Control Lists

Access Control Lists (ACLs) are among the oldest and easiest access control mechanisms. They define which users or system processes can access specific resources and what operations (e.g., read, write, execute) are allowed. ACLs are typically directly associated with the resource (e.g., file, directory, object) and are accessed whenever access to the resource is requested. This model excels in situations where users, resources, and privileges are fairly static.

How It Works

An ACL is a table or list attached to a resource that contains entries specifying the users or groups that possess access to the resource. When a user attempts to use the resource, the system checks the ACL to determine if the user is on the list and if their permission is suitable for the action requested. No policy engine or context-based evaluation—access is plain binary and identity- and right-predefined.

Pros

• Easy to implement and understand for small-scale systems
• Suitable for systems with a low number of users or static access need
• Explicit control over access to resources

Cons

• Not scalable as ACL management becomes increasingly complex as the number of users and resources grows
• Does not support abstraction as permissions are not role- or policy-based
• No context-dependent or dynamic decision support (e.g., when to retrieve, device trust)
• Minimal or no compliance auditing and monitoring

Real-World Application

ACLs suit systems with comparatively static and straightforward access control needs. Typical examples include file systems in operating systems, network appliances, and distributed file-sharing environments. For instance, traditional file servers or NFSv4-based shared file systems grant read/write/execute permissions to individual users or groups for specific files and directories through explicitly defined ACL entries. In these cases, access rights are commonly configured manually and enforced consistently across Unix/Linux environments.

ACLs are transparent and provide explicit access control, but they do not scale well in large enterprise environments. They become cumbersome as user populations grow or when permissions must align with organizational roles, workflows, or dynamic attributes. ACLs are best suited for tightly controlled environments with relatively few users and static resources, such as legacy systems, infrastructure appliances, or basic shared file services. While they offer simplicity and predictability, they lack flexibility, automation, and context-aware evaluation required in modern, dynamic, or Zero Trust–aligned environments.

Open Authorization (OAuth 2.0)

Within the authorization capability framework, OAuth 2.0 (RFC 6749) functions as the definitive standard for delegated access control. Rather than handling user authentication directly, it allows resource owners to grant third-party application clients scoped, time-bound, and revocable access tokens to programmatically interact with protected APIs without exposing primary credentials.

For a comprehensive structural deep dive into OAuth 2.0 architectural roles, secure grant types, and production security best practices, please refer to the dedicated OAuth 2.0 protocol section in the Protocols and Standards section of this document.

Provisioning

Provisioning is the process of granting users, systems, or devices access to systems, applications, or services. It involves setting up resources, permissions, and configurations so entities can perform their tasks effectively.

Examples of provisioning include:

• User Provisioning: Creating accounts, assigning roles, and granting access to tools like email or databases

• Device Provisioning: Configuring devices like laptops or phones with software, security settings, and access to resources

• Cloud Provisioning: Allocating cloud resources such as virtual machines, storage, or databases to users or applications

Just-In-Time Provisioning

Just-In-Time (JIT) provisioning is the process of granting access to systems, applications, or services at the time of first login, rather than pre-provisioning them in advance. This minimizes standing privileges and reduces security risks while improving resource efficiency.

To clarify, JIT provisioning refers to creating user accounts on-demand when they are needed, whereas Just-In-Time access refers to granting temporary permissions, which is typically handled by access control policies rather than provisioning protocols.

Examples of JIT provisioning include:

• User JIT Provisioning: Automatically creating accounts and granting access at the moment a user logs in for the first time
• Cloud JIT Provisioning: Provisioning virtual machines or containers only when workloads demand them
• Service JIT Provisioning: Temporarily activating access to APIs or services based on real-time requests

Deprovisioning

Deprovisioning is the process of revoking access and disabling accounts or resources when they are no longer needed. It ensures that former users or devices cannot access corporate systems, reducing the risk of unauthorized use and freeing up resources.

Examples of deprovisioning include:

• User Deprovisioning: Disabling accounts and revoking access when employees leave or change roles
• Device Deprovisioning: Wiping and removing access from unused or former employee devices
• Cloud Deprovisioning: Deleting inactive cloud resources to reduce costs and avoid resource wastage

System for Cross-Domain Identity Management

The System for Cross-Domain Identity Management, or SCIM, is an open standard designed to standardize the provisioning and deprovisioning of users and groups between identity systems and applications. It uses RESTful APIs and JSON to automate provisioning, updates, and de-provisioning of users and groups across systems.

How It Works

SCIM is an HTTP/REST-based standard that uses JSON for resource representations (e.g., users, groups). IdPs call SCIM endpoints on SPs to create, read, update, and delete identities. Transport security is provided by HTTPS/TLS. Authentication and authorization to the SCIM endpoints are out of scope of SCIM itself and are commonly implemented with OAuth 2.0 (e.g., bearer tokens) or other mechanisms.

Within the provisioning capability framework, the SCIM functions as the definitive open standard for automating the identity lifecycle across security domains. Designed to eliminate manual account creation and prevent identity drift, SCIM acts as a standardized connector that synchronizes user and group states between central IdPs and downstream SaaS or cloud applications. It ensures that user access is dynamically updated during department transfers and instantly revoked upon termination.

For a detailed technical exploration of SCIM schemas, operational endpoints, and multi-IdP integration architectures, please refer to the comprehensive SCIM protocol profile in the Protocols and Standards section of this document.

Pros

• Supports automation effectively by automatically provisioning, updating, and deprovisioning user accounts, reducing manual effort

• Provides standardization, a consistent and universal framework for identity management across systems

• Supports secure communication using protocols like OAuth 2.0 and HTTPS, minimizing unauthorized access

• It can handle large-scale identity management data transactions for organizations with multiple users and applications

Cons

• Not all applications and legacy systems support SCIM, limiting its utility and adoption

• Inconsistent SCIM implementations across applications and identity providers may introduce compatibility challenges

• Implementation challenges due to complex settings requires technical expertise

• Since it relies on protocols like REST APIs, OAuth 2.0, and JSON, it therefore requires frequent updates over time

Supporting Protocols

Protocol	Use
REST APIs	SCIM is built on REST APIs, which enable communication between identity providers (e.g., Okta, Microsoft Entra ID) and applications (e.g., Salesforce, Slack). REST APIs handle operations like creating, updating, deleting, and retrieving user data.
OAuth 2.0	SCIM uses OAuth 2.0 for secure authorization but it’s not mandatory, ensuring only authenticated and authorized entities can access and manage user identity data.
JSON	SCIM relies on JSON as the data exchange format for user profiles, group information, and permissions.
HTTPS	SCIM requires HTTPS to encrypt data during transmission, ensuring secure communication between identity providers and connected applications.
URI	SCIM uses URIs to uniquely identify resources, such as users, groups, and roles.

Table 11: Supporting Protocols for SCIM

Real-World Application

Imagine a company, Imaginary Minds, that uses Okta as its identity provider and Slack for team communication. When a new employee joins, SCIM automatically creates their Slack account, assigns them to the correct channels, and ensures their profile matches the information in Okta. If the employee changes departments, SCIM updates their Slack permissions without any manual input.

References

• SCIM Official Website: Provides detailed information about the SCIM protocol, specifications https://www.simplecloud.info

• RFC 7643: Defines the SCIM core schema and resources : RFC 7643 Documentation

• RFC 7644: Specifies the SCIM protocol for managing identity information : RFC 7644 Documentation

Identity Governance and Administration

Identity governance and administration (IGA) refers to the policies, processes, and technical standards that ensure secure, compliant, and consistent management of digital identities throughout their lifecycle—creation, usage, and deactivation. This includes defining who can access what, under which circumstances, and ensuring that all identity actions align with organizational or regulatory requirements. It is generally recommended to leverage an IGA tool to automatically assess and enforce governance policies in real time.

Purpose and Importance

• Accountability: Ensures traceability of access and actions for auditing and compliance (e.g., SOX, HIPAA, GDPR)

• Least Privilege: Enforces access only to what is necessary based on roles, responsibilities, and risk

• Lifecycle Management: Automates provisioning, access reviews, and deprovisioning as users join, move, or leave

• Policy Enforcement: Applies identity policies consistently across hybrid environments (cloud/on-premises)

• Delegation and Approval Workflows: Allows for controlled exceptions and business justification in access decisions

• Access Certification and Review: Periodic reviews of user access rights to ensure they remain appropriate for current job functions

• SoD: Enforcement of policies that prevent any single individual from having sufficient access to complete sensitive transactions alone

• Privileged Access Management (PAM): Specialized governance for accounts with elevated privileges, including administrative accounts, service accounts, and emergency access credentials

• Entitlement Management: Centralized visibility and control over what access rights exist across the enterprise, how they are assigned, and who possesses them

• Identity Analytics and Intelligence: Advanced analysis of access patterns, permission usage, and identity behavior to detect anomalies, identify excessive permissions, and recommend policy improvements

Supporting Protocols

Protocol	Use
SCIM	Purpose: Standardizes identity lifecycle management (create, update, delete) Governance Role: Automates provisioning and deprovisioning Ensures accurate, policy-aligned identity data across systems Reduces human error and manual inconsistencies
XACML (eXtensible Access Control Markup Language)	Purpose: Defines ABAC policies Governance Role: Centralizes and standardizes fine-grained access decisions Enables auditing and enforcement of context-aware policies Supports compliance by aligning access logic with organizational rules
SAML/OAuth 2.0/OIDC	Purpose: Enable secure authentication and authorization across domains Governance Role: Enforce consistent authentication and authorization policies Limit access scopes (OAuth), assert user identity (SAML/OIDC), and manage consent Provide audit trails for federated access
LDAP	Purpose: Access and manage directory information services over IP Governance Role: Acts as a centralized identity repository Supports access control based on directory attributes Enables consistent user lookup and role assignment across applications
Representational State Transfer (REST)	Purpose and Governance Role: REST plays a foundational role in modern IAM governance by enabling the APIs that governance systems use to enforce policies, conduct access reviews, provision identities, and maintain audit trails

Table 12: Supporting Protocols for IGA

Secrets Management

Secrets management refers to the secure generation, storage, distribution, rotation, revocation, and monitoring of sensitive credentials used by applications, services, and infrastructure. Unlike authentication protocols (e.g., SAML, OAuth) or provisioning protocols (e.g., SCIM), secrets management relies on a combination of cryptographic standards, API specifications, and security protocols that together form a comprehensive approach to credential lifecycle management.

Several underlying standards and protocols enable secure secret storage, distribution, and rotation across heterogeneous environments. Understanding these standards is crucial for implementing interoperable, vendor-neutral secrets management architectures that align with IAM best practices.

Purpose and Importance

• Least Privilege for Secrets: Enforces just-in-time and just-enough access to secrets based on workload identity, service context, and risk posture, preventing broad secret sharing

• Secret Lifecycle Management: Automates secret creation, rotation, revocation, and expiration across distributed systems, eliminating manual key management and reducing exposure windows

• Integration with Identity Systems: Binds secret access to verified workload identities (e.g., SPIFFE/SPIRE, workload identity federation, machine identities) rather than embedded credentials

• API Key and Token Management: Specialized handling of API keys, OAuth tokens, JWT signing keys, and service account tokens with scope-based access control and automatic refresh

• Certificate and PKI Management: Manages X.509 certificates, automates issuance, renewal, and revocation, integrates with internal/external certificate authorities (e.g., Let’s Encrypt, ACME protocol, private PKI)

Supporting Protocols

Protocol	Use
PKCS #11	PKCS #11 provides a vendor-neutral interface for applications to access cryptographic keys and perform cryptographic operations without directly handling key material. This abstraction enables secrets management systems to leverage Hardware Security Modules (HSMs) for tamper-resistant key storage while maintaining application portability.
Key Management Interoperability Protocol (KMIP)	KMIP provides a standardized way for applications, databases, storage systems, and other cryptographic clients to retrieve and manage encryption keys from centralized key management servers, eliminating proprietary APIs and enabling vendor interoperability.
OAuth 2.0 Token Exchange (RFC 8693)	Token Exchange enables secure, delegated access to secrets across trust boundaries. A service can exchange its identity token for a token authorized to access specific secrets, implementing least-privilege access without distributing long-lived credentials.
SPIFFE/SPIRE	Workload identity bootstrapping.Note: SPIFFE/SPIRE doesn’t store secrets itself. It provides a secure identity for workloads, which can then be used to safely access secret storage systems.
Automated Certificate Management Environment (ACME)	Automates certificate lifecycle.
JSON Web Key (JWK)/JSON Web Key Set (JWKS)	Standardize key distribution.

Table 13: Supporting Protocols for Secrets Management

Real-World Application

CI/CD pipelines frequently need to access databases, external APIs, or cloud infrastructure during build and deployment stages. Rather than embedding credentials directly into pipeline configuration files, a secrets management solution allows the pipeline to retrieve credentials at runtime from a centralized vault. The pipeline authenticates using its workload identity, receives a short-lived token scoped to the specific secret it needs, and the credential is automatically rotated after use. This eliminates the risk of credentials being committed to source code repositories or persisting longer than necessary.

In Kubernetes environments, workloads running across distributed clusters often need to access cloud-hosted databases or internal APIs. Service account tokens and SPIFFE identities allow each workload to authenticate to a secrets management system using its own verified identity rather than a shared credential. If a workload is compromised or decommissioned, its access is revoked without affecting other workloads in the cluster.

Organizations running public-facing HTTPS services must manage TLS certificates across potentially hundreds of domains. Automated certificate lifecycle management using the ACME protocol and integration with certificate authorities, such as Let’s Encrypt, allows certificates to be issued, renewed, and revoked without human intervention, eliminating the risk of service outages caused by expired certificates.

• Example 1: A financial services organization running microservices needs to ensure that API keys used for inter-service communication are never stored in plain text and are rotated on a regular schedule. A centralized secrets management system stores these keys in a hardware security module, enforces access policies based on the requesting service’s identity, and automatically rotates keys according to defined intervals. Audit logs capture every access and rotation event, providing full traceability for compliance and incident response.

• Example 2: A healthcare organization must ensure that credentials used by internal systems to access patient data stores comply with HIPAA requirements at all times. Secrets are stored in an encrypted vault with access governed by workload identity and least-privilege policies. All credential access is logged, rotation is enforced on a defined schedule, and any orphaned or inactive credentials are automatically flagged for review, ensuring continuous compliance without manual auditing.

Protocols and Standards

Security Assertion Markup Language

Security Assertion Markup Language, or SAML, is an XML-based open standard used for exchanging authentication and authorization data between the IdP and SP.

SAML is primarily used to achieve/enable SSO by allowing users to authenticate once and access multiple applications or systems without logging in each time. The main benefits of SAML include:

• Shares the user/identity information securely between applications/ systems
• Simplifies the authentication process
• Improves the user experience
• Enhances the security posture through key controls such as signed assertions and responses, replay detection, and audience restrictions to prevent forgery and replay attacks

Real-World Application

Use cases for SAML include:

• SSO
• Federated identity management
• Cross-domain authentication
• Centralized authentication
• Policy enforcement
• Cloud and SaaS access

The following examples highlight how SAML is applied in real-world scenarios:

• Example 1: A company wants to provide its workforce (users) with a seamless login experience across multiple enterprise applications. Individual employees need to authenticate once using their corporate credentials, and they will be granted access to other applications (e.g., on-premises, cloud, SaaS) without needing to enter their credentials again. Behind the scenes, when an employee tries to access a SaaS application (the SP) like Salesforce or Workday, the SaaS application redirects the user to the company’s IdP, which authenticates them (if not already logged in), and then sends back a SAML assertion providing the employee’s identity and attributes. The SaaS app trusts this assertion and logs them in without a password. The benefits of SAML are that employees get seamless SSO and do not have to remember multiple passwords for different service providers, and companies get centralized identity governance and avoid storing passwords in dozens of SaaS apps.

• Example 2: A company wants to enforce MFA use for all cloud and third party applications. In this case, they would make all apps use the IdP for authentication, and the IdP would enforce MFA during login, and thus all apps automatically get MFA without local configuration for each app. Centralized enforcement, consistent user experience and reduced overhead for application teams are the benefits of this approach. Organizations can implement SAML to enable authentication for their mobile applications, allowing users to log in with their enterprise credentials.

While SAML provides robust federation, implementations must strictly validate XML signatures to guard against XML Signature Wrapping (XSW) attacks. Proper validation ensures an adversary cannot alter the assertion payload while preserving a valid signature to achieve unauthorized access.

References

• https://www.oasis-open.org/standard/saml/
• https://datatracker.ietf.org/doc/html/rfc7522
• https://duo.com/blog/the-beer-drinkers-guide-to-saml

Open Authorization (OAuth 2.0)

OAuth 2.0 is an authorization framework standardized in RFC 6749, enabling third-party applications (clients) to obtain delegated access to protected resources on a resource server via access tokens issued by an authorization server. It operates over HTTPS, emphasizing secure, token-based access without requiring the resource owner (i.e., the user) to share credentials with the client. Its evolution, reflected in the emerging OAuth 2.1, incorporates modern security best practices by deprecating the Implicit Grant and Resource Owner Password Credentials (ROPC) Grant and requiring Proof Key for Code Exchange (PKCE) for all clients.

Access tokens are scoped, time-bound, and revocable, representing specific permissions granted by the resource owner. In many deployments these are bearer tokens, meaning possession alone is sufficient for use, which makes them vulnerable to replay if compromised. RFC 9700 (January 2025) establishes the current security baseline for OAuth 2.0 deployment. It makes PKCE mandatory for all Authorization Code flows, requires exact redirect URI matching, and recommends sender-constrained tokens, such as DPoP, particularly for public clients to mitigate token theft and replay attacks.

The primary objective of OAuth 2.0 is to provide a secure, interoperable mechanism for delegated authorization in distributed systems. OAuth 2.0 is strictly an authorization framework and must not be used as a standalone authentication protocol, as it does not define standardized identity claims or authentication context. It assumes the user is already authenticated and focuses on a single goal: allowing resource owners to grant granular, controlled access to their data without sharing passwords. It is designed for scalability and supports various client types—confidential (e.g., web servers), public (e.g., mobile apps), and machine-to-machine, making it a foundational protocol for modern API ecosystems and identity management.

OAuth 2.0 is deployed in scenarios requiring secure API access, federated identity, or third-party integrations. It leverages grant types (e.g., Authorization Code, Client Credentials) tailored to specific flows, enabling clients to request tokens after user consent or client authentication. The framework is widely adopted in cloud services, microservices architectures, and SSO implementations, particularly when paired with protocols such as OpenID Connect.

How It Works

The OAuth 2.0 protocol involves four key roles:

• Resource Owner: The user who owns the data and can grant access
• Client: The application requesting access to resources
• Authorization Server: Issues access tokens after authenticating the resource owner
• Resource Server: Hosts the protected resources and validates access tokens

Access tokens are:

• Scoped: Limited to specific permissions (e.g., “read photos” but not “delete photos”)
• Time-Bound: Expire after a set period for security
• Revocable: Users can revoke access without changing passwords

Token types consist of:

• Access Token: Used by client to access the resource
• Refresh Token: Used by client to access the resource without need for reauthentication
• ID Token: Provides clients identity but not part of OAuth 2.0 itself

Authorization flows, also known as grant types, follow these steps:

1. The client directs the resource owner to the authorization server.
2. The resource owner authenticates and approves the access request.
3. The authorization server issues an access token to the client.
4. The client uses the access token to request resources from the resource server.
5. The resource server validates the token and returns the requested resources.

OAuth 2.0 defines several grant types for different scenarios:

• Authorization Code Grant: Used by web applications with server-side backends

• Authorization Code + PKCE: For mobile apps and single-page applications (SPA). The client application initiates the flow by sending a request to the authorization server. Authorization server validates the user and sends a temporary authorization code to the client. The client then exchanges this code by making a secondary request to the authorization server, presenting the

  grant_type and the authorization code. Once the authorization server validates the code, it issues an access token

• Client Credentials Grant: For server-to-server communication (machine-to-machine)

• Refresh Token Grant: Allows client to obtain new access tokens without re-authentication

Note: The Implicit Grant and ROPC Grant are deprecated and should not be used in new implementations, per OAuth 2.1 draft, security advisories.

Real-World Application

OAuth 2.0 supports diverse authorization scenarios critical to IAM deployments. Use cases for OAuth 2.0 include:

• Web application authorization
• Identity federation and social login (“Sign in with Google/Facebook”)
• Mobile and native apps
• SPAs
• M2M access
• Delegated access for third-party integration
• Cross-domain API access
• Zero Trust API access with conditional authorization
• Third-party application integration
• Microservices authorization
• IoT device authorization

The following examples highlight how OAuth 2.0 is applied in real-world scenarios:

• Example 1: A company aims to enable its workforce (users) to securely access multiple enterprise applications and third-party services using a single set of corporate credentials, without having to share those credentials with each application repeatedly. With OpenID Connect for authentication and OAuth 2.0 for authorization, users authenticate once through the company’s IdP. OAuth 2.0 then issues access tokens to approved applications, and the system issues access tokens to approved applications—whether on-premises, cloud-based, or SaaS—enabling seamless and secure access to resources such as APIs or user data. For example, a user logs in via the IdP, and an OAuth 2.0 flow (e.g., Authorization Code Grant) grants a project management tool permission to read their calendar or grants a cloud storage app access to specific files, all without requiring re-entry of credentials

• Example 2: Organizations can implement OAuth 2.0 to secure authorization for their mobile applications. This allows users to log in to the mobile app using their enterprise credentials via an IdP, with OAuth 2.0 issuing access tokens that enable the app to interact with backend services or external APIs (e.g., retrieving customer data from a CRM) on the user’s behalf, maintaining security and control over access scopes

• Example 3: A user wants to use a photo printing service that needs access to their Google Photos. Instead of giving the printing service their Google password, they click “Connect to Google Photos.” They’re redirected to Google’s authorization server where they log in with their Google credentials and see a consent screen showing exactly what the printing service is requesting (e.g., “View your photos”). After the user provides approval, Google issues an access token to the printing service. The service uses this token to retrieve photos from Google’s API. The user can later revoke this access from their Google account settings without changing their password, and the printing service never learns their Google credentials.

Note on OAuth 2.1

The industry is converging on OAuth 2.1, an evolution of OAuth 2.0 that eliminates insecure flows, such as the Implicit Grant and the ROPC Grant, and mandates stronger security defaults—including requiring PKCE for all authorization code flows, not just public or mobile clients.

For more complex and emerging use cases, such as autonomous AI agents acting on a user’s behalf, a newer standard called Grant Negotiation and Authorization Protocol (GNAP) is under development. GNAP is designed to support dynamic, fine-grained authorization and richer delegation models that are difficult to implement cleanly with OAuth 2.0. While still evolving, GNAP represents a forward-looking approach to modern authorization scenarios beyond traditional browser-based applications.

As for security considerations, standard OAuth 2.0 bearer tokens remain susceptible to theft and replay attacks. High-assurance environments should implement sender-constrained tokens (e.g., DPoP, RFC 9449) or mutual TLS (e.g., mTLS, RFC 8705) to cryptographically bind access tokens to a specific client session.

References

• Hardt, D. (Ed.). (2012). “The OAuth 2.0 Authorization Framework.” RFC 6749, Internet Engineering Task Force (IETF). Available at: https://tools.ietf.org/html/rfc6749.
• Lodderstedt, T., et al. (2025). OAuth 2.0 Security Best Current Practice. RFC 9700, IETF. https://datatracker.ietf.org/doc/html/rfc9700
• Sakimura, N., et al. (2015). “Proof Key for Code Exchange by OAuth Public Clients.” RFC 7636, IETF. Available at: https://tools.ietf.org/html/rfc7636
• Jones, M., & Hardt, D. (2012). “The OAuth 2.0 Authorization Framework: Bearer Token Usage.” RFC 6750, IETF. Available at: https://tools.ietf.org/html/rfc6750

OpenID Connect

OpenID Connect, or OIDC, is an identity layer built on OAuth 2.0 and defined by the OpenID Foundation. It extends OAuth 2.0’s authorization framework by adding federated authentication capabilities, enabling clients to verify a user’s identity via an ID token—a JWT containing user attributes (claims)—issued by an OpenID Provider (OP) alongside OAuth access tokens.

OIDC’s primary purpose is to provide a simple, secure, and interoperable way to authenticate users and share their identity information across applications, while leveraging OAuth 2.0 for authorization. It aims to streamline SSO and federated identity use cases, offering a standardized alternative to SAML with a lightweight, API-friendly approach suitable for modern web, mobile, and cloud environments.

OIDC is used in scenarios that require both authentication (verifying the user’s identity) and authorization (granting access to resources). It employs OAuth 2.0 flows (e.g., Authorization Code with PKCE for web/mobile apps, hybrid flow for specific scenarios) with additional endpoints (e.g., UserInfo) and parameters (e.g., openid scope) to deliver ID tokens and user data, making it ideal for SSO across trust domains or integrating with third-party IdPs.

How It Works

This is how OIDC works:

1. OIDC is initiated with an OAuth 2.0 flow (most commonly Authorization Code with PKCE for web/mobile), requesting the openid scope.

2. The user is redirected to an identity provider to authenticate (e.g., password, MFA, passwordless).

3. The provider issues an ID token to the application digitally signed and typically includes a JWT, which safely conveys the authenticated user’s identity and claims (e.g., name, email, unique identifier).

4. An access token may also be issued for accessing APIs.

OIDC enables applications to obtain further user information via a standardized “userinfo” endpoint, if needed.

As for security considerations, to maintain trust across federated domains, OIDC implementations must strictly validate the aud (audience) and iss (issuer) claims within the ID Token. This prevents token substitution attacks, where a token issued for a malicious or differing client is replayed to a legitimate relying party.

Real-World Application

OIDC supports a variety of authentication and identity management scenarios. Common use cases include:

• SSO
• Mobile app authentication
• Web application login
• API security
• Federated identity
• User profile access
• B2B partner federation
• Multi-tenant SaaS authentication
• Identity brokering across multiple IdPs
• Decoupled authentication (e.g., Client-Initiated Backchannel Authentication (CIBA))

The following examples highlight how OIDC is applied in real-world scenarios:

• Example 1: A company aims to deliver a seamless and secure login experience to its workforce (users) across its portfolio of enterprise applications, encompassing on-premises systems, cloud platforms, and SaaS tools. With OIDC, users authenticate once using their corporate credentials via an OP (e.g., an internal IdP, a trusted third party), receiving an ID token that verifies their identity and an access token for resource access. This allows them to move seamlessly between applications, such as an internal HR system, a cloud-based collaboration tool, and a SaaS CRM, without re-entering credentials, leveraging OIDC’s SSO capabilities.

• Example 2: Organizations can also adopt OIDC to enable secure, passwordless authentication for their mobile applications, allowing users to log in with enterprise credentials. For example, after authenticating with the corporate IdP, a mobile app receives an ID token that verifies the user’s identity and an access token that authorizes access to backend services or external APIs (e.g., pulling data from a project management platform), ensuring a consistent and secure identity experience across devices.

References

• Sakimura, N., et al. (2014). “OpenID Connect Core 1.0.” OpenID Foundation. Available at: https://openid.net/specs/openid-connect-core-1_0.html.

System for Cross-Domain Identity Management

SCIM is an open standard (RFC 7642, 7643, 7644) that streamlines and automates the provisioning, management, and deprovisioning of user identities across diverse IT systems. It provides a RESTful API and a standardized, schema-based data model for exchanging user and group information between IdPs and SPs.

SCIM’s primary purpose is to simplify and secure identity lifecycle management by enabling consistent, real-time synchronization of user data across domains, reducing manual overhead and errors. It aims to streamline onboarding, updates, and offboarding processes in multi-system environments, enhancing interoperability between cloud, SaaS, and on-premises applications.
SCIM is implemented in environments that require automated user and group provisioning, synchronization, and deprovisioning across multiple platforms. It operates over HTTP, using standard methods such as POST, GET, PATCH, PUT, and DELETE to create, update, or remove user and group resources, by leveraging consistent schemas (e.g., User, Group) and well defined endpoints (e.g., /Users, /Groups). SCIM ensures interoperability between IdPs, directory services, and SPs.

Real-World Application

Use cases for SCIM include:

• ​User provisioning
• User deprovisioning
• Attribute synchronization
• Group management
• Cross-domain integration
• Federated identity support

The following examples highlight how SCIM is applied in real-world scenarios:

• Example 1: Healthcare Industry - Managing Staff Access Across Systems: Hospitals and clinics use many digital systems, EHRs, scheduling tools, lab systems, and secure messaging platforms. When a new nurse joins:
  • SCIM automatically creates their account across all systems
• If they switch departments (e.g., from pediatrics to emergency), SCIM updates their access rights
• When they leave, SCIM removes their access everywhere. It keeps patient data safe
  Since the healthcare data is sensitive, SCIM helps ensure only the right people have access, and only when they need it
• Example 2: Retail Industry - Seasonal Workforce Management: Retail companies often hire temporary staff during the holidays. SCIM helps manage these short-term identities:
• When a seasonal worker is hired, SCIM creates accounts for POS systems, inventory tools, and training platforms
• After the season ends, SCIM deactivates their access
  It saves time and ensures temporary workers don’t retain access after their job ends.
• Example 3: All Industries - Streamlining Identity Management: Companies often need to streamline identity management for its workforce (users) across a diverse set of enterprise applications, including on-premises systems, cloud platforms, and SaaS tools. With SCIM, user accounts are automatically provisioned to these applications when employees join the organization, pulling data (e.g., name, email, role) from the company’s central identity provider or HR system. As employee details change—such as a promotion or department transfer—SCIM updates the attributes across all connected systems in real time. When an employee leaves, access is instantly deprovisioned, ensuring security and compliance without manual intervention. SCIM ensures identity changes happen in real time based on lifecycle changes to help achieve effective security.

Key Benefits of SCIM

• Automation: No need to manually update user info in every app
• Consistency: User data remains consistent across systems
• Security: Access is removed quickly when someone leaves
• Scalability: Works well for large organizations with many users

Between Multiple IdPs

In modern organizations, identity is no longer managed in just one place. We often use multiple IdPs, like Microsoft Entra ID (formerly Azure AD), Okta, Google Workspace, or even custom-built solutions. They also rely on various identity solutions for authentication, access control, and user lifecycle management.

This creates a challenge: “How do you keep user data consistent, secure, and up-to-date across all these systems?” SCIM plays a strategic role.

Imagine a global company with Workday for corporate employees, SAP ARIBA Workspace for contractors, and Entra for partner access. Each IdP manages its own set of users. Without SCIM, syncing identities between these systems would require custom scripts or manual updates. With SCIM:

• User profiles can be automatically synchronized across IdPs
• Changes made in one system (like a role update or termination) can propagate to others
• Access policies stay aligned, reducing the risk of identity drift or orphaned accounts

Organizations often use a mix of identity tools: LDAP for legacy systems, OAuth/OIDC for modern apps, SAML for enterprise SSO, and custom APIs for internal platforms.

SCIM acts as a neutral connector between these systems. It doesn’t replace them, it compliments them by handling user provisioning and deprovisioning in a standardized way. In practice, implementations can vary across providers, and some operational considerations may arise depending on scale and application capabilities.

For example, a company uses Okta for SSO but also has an internal HR system and a legacy CRM. SCIM can:

• Pull user data from HR
• Push it to Okta and CRM
• Keep everything in sync without manual effort

Overall, SCIM reduces integration complexity and future-proofs identity architecture by supporting interoperability.

References

• Hunt, D., et al. (2015). “System for Cross-domain Identity Management: Protocol.” RFC 7644, Internet Engineering Task Force (IETF). Available at: https://tools.ietf.org/html/rfc7644.

Identity Query Language

The Identity Query Language (IDQL) is an emerging open standard designed to unify and orchestrate access policies across multi-cloud and hybrid environments. IDQL provides a declarative, JSON-based policy framework that enables organizations to define, translate, and enforce consistent IAM policies across heterogeneous systems, including AWS IAM, Microsoft Entra ID, Google Cloud IAM, Okta, and on-premises directories.

IDQL enables administrators to express authorization policies in a common language, decoupled from vendor-specific policy formats. These policies are processed through the Hexa Policy Orchestration Gateway, an open-source reference implementation that translates IDQL policies into the native syntax of each target platform.

Unlike authentication standards (e.g., OAuth 2.0, FIDO2), which focus on verifying identities, IDQL specifically addresses authorization policy abstraction and portability, thereby addressing the long-standing challenge of fragmented access control management across clouds and identity systems.

The purpose of IDQL is to establish policy interoperability for identity and access management in distributed environments. As enterprises increasingly adopt multi-cloud strategies, managing fine-grained authorization across platforms has become complex and inconsistent.

IDQL aims to:

• Centralize policy management while preserving decentralized enforcement across heterogeneous systems

• Simplify identity governance by enabling policies to be defined once and applied across multiple platforms

• Reduce configuration errors and compliance drift caused by inconsistent native policy models

• Accelerate Zero Trust adoption by enabling uniform enforcement of least-privilege principles across clouds and services

Through its declarative model and translation layer, IDQL supports policy consistency, auditability, and automation across environments. In practice, IDQL defines a standard schema for expressing authorization policies using abstract entities:

• Subjects (who)
• Actions (what operations)
• Objects/Resources (on what)
• Conditions (when/where/how)

The standard schema looks like:

1. Policy Authoring: Administrators define policies in IDQL syntax (JSON-based) using these abstract entities to express access rules.

2. Policy Translation: The Hexa Policy Orchestration Gateway translates each IDQL policy into native provider formats (e.g., AWS IAM JSON, Azure role definitions, Google Cloud IAM bindings). Translation fidelity depends on the capabilities of each target platform, as not all policy features can be represented identically.

3. Policy Deployment: Translated policies are distributed and enforced within each environment, ensuring the intended policy behavior is maintained across supported platforms.

4. Policy Synchronization: Changes made centrally in IDQL are automatically synchronized with the underlying platforms, ensuring continuous alignment.

This architecture allows organizations to standardize access control while retaining compatibility with their existing IAM ecosystems.

IDQL addresses scenarios where organizations need to manage and harmonize access policies across diverse identity systems and clouds, including:

• Multi-Cloud Access Governance: Define a single access control policy and apply it uniformly across AWS, Azure, and Google Cloud

• Hybrid Cloud Integration: Extend consistent authorization logic to on-premises systems and SaaS platforms

• Policy Federation in Mergers and Acquisitions: Rapidly align disparate IAM policies across newly combined infrastructures

• Zero-Trust Policy Automation: Implement centralized policy logic that dynamically enforces context-aware access across environments

Real-World Application

To help understand how IDQL may be applied, consider a multinational enterprise that uses IDQL and the Hexa Policy Orchestration Gateway to maintain unified access control across its AWS, Azure, and Okta environments. Security administrators define high-level policies, such as “Only employees in the Finance department may access accounting resources from managed devices,” using IDQL. Hexa automatically translates this abstract policy into:

• AWS IAM policies for S3 and Lambda resources
• Cedar policy for AWS Verified Permissions or an IAM policy condition
• Microsoft Entra ID (formerly Azure AD) conditional access rules
• Okta group-based entitlements

When organizational attributes (e.g., department, device compliance status) change, IDQL automatically updates and synchronizes the translated policies across all connected systems. This approach eliminates manual policy duplication, reduces drift, and supports consistent Zero Trust enforcement across multiple clouds.

References

• Strata Identity. (2022). New Identity Standard IDQL/Hexa Policy Project. Available at: https://www.strata.io/resources/news/new-identity-standard-idql-hexa-policy-project/
• Hexa Policy Orchestration. Overview and Open Source Project. Available at: https://hexaorchestration.org/
• Security Boulevard. (2022). How to Go from Zero to a Standard: Building IDQL/Hexa. Available at: https://securityboulevard.com/2022/05/how-to-go-from-zero-to-a-standard-building-idql-hexa/
• KuppingerCole Analysts AG. (2021). Addressing Multi-Cloud Identity Challenges with a New Standard: IDQL. Available at: https://www.kuppingercole.com/watch/eic2021-gebel-multi-cloud-identity-challenges-idql
• Brigandi, G. (2022). First Impressions of IDQL. Medium. Available at: https://medium.com/@gbrigandi/first-impressions-of-idql-8ef8b9de96d3

Decentralized Identifiers and the Decentralized Identity Ecosystem

Decentralized Identifiers (DIDs) are a type of globally unique, persistent, and cryptographically verifiable identifier defined by the W3C DID Core 1.0 specification. A DID represents a subject (e.g., person, organization, device, service) and is resolved to a DID Document that contains public keys, verification methods, and service endpoints.

DIDs are a foundational building block of the broader Decentralized Identity (DI) or Self-Sovereign Identity (SSI) ecosystem. This architectural model enables individuals and organizations to create, own, and control their digital identities independent of centralized authorities.

Together with Verifiable Credentials (VCs) and digital wallets, DIDs enable secure, privacy-preserving, and interoperable interactions across domains for identity.

The purpose of DIDs is to provide a decentralized identifier framework that replaces the need for centralized registries, identity providers, or certificate authorities. By using cryptographic verification and decentralized resolution methods (e.g., blockchain, distributed ledgers, other decentralized systems), DIDs enable:

• Self-ownership of identity without intermediaries
• Cryptographic verification of control and authenticity
• Privacy-preserving credential exchange through selective disclosure and ZKPs
• Interoperability across organizations, jurisdictions, and trust frameworks

This architecture strengthens privacy, reduces single points of failure, and establishes a verifiable, user-controlled foundation for digital trust.

In a decentralized identity ecosystem, several standards and roles interact:

• Issuer: Creates and issues VCs to a holder (e.g., a university issuing a diploma)
• Holder: Controls one or more DIDs and stores received credentials in a digital wallet
• Verifier: Requests and validates credentials presented by a holder using the issuer’s DID and public keys

Each DID resolves to a DID Document containing cryptographic material for authentication and verification. Communications between these parties can occur through protocols, like DIDComm, that enable secure, peer-to-peer messaging.

Privacy-preserving mechanisms, such as selective disclosure and ZKPs, enable individuals to prove facts about themselves without revealing the underlying data. These features require specific credential formats and cryptographic schemes that support them:

• Selective Disclosure: Allows revealing only the required credential attributes (e.g., proving “over 18” without sharing birth date). This capability requires credential formats such as JSON-LD with BBS+ signatures or Selective Disclosure for JWTs (SD-JWT). SD-JWT is the most widely deployed selective disclosure format as of 2025. It is adopted in the EU eIDAS 2.0 digital identity wallet specification and incorporated into NIST SP 800-63C-4. Unlike BBS+, which requires specialized cryptography, SD-JWT uses standard Hash-Based Message Authentication Code (HMAC)-based disclosure commitments compatible with existing JWT tooling.

• ZKPs: Enable the verification of authenticity without disclosing the credential content. ZKPs represent an advanced feature not yet supported by all VC implementations.

These techniques reinforce the principles of data minimization and privacy by design across decentralized identity implementations.

To make decentralized identity practical, many implementations use OpenID for Verifiable Credentials (OID4VC) protocols. OID4VC defines flows for credential issuance (OID4VCI) and presentation (OID4VP), allowing secure exchange between issuers, wallets, and verifiers using OAuth 2.0 and OIDC patterns.

Real World Application

Use cases for DIDs include:

• Decentralized and self-owned digital identity management
• Privacy-preserving credential sharing and verification
• Cross-organization and cross-border trust establishment
• Streamlined onboarding and verification (e.g., employment, education)
• Tamper-proof digital credential issuance and validation

As an example of how DIDs are applied in real-world scenarios, imagine a global airline alliance implements a decentralized identity framework, enabling passengers to store and manage travel credentials, such as passports, visas, and frequent-flyer memberships, within their digital wallets. Before boarding or crossing borders, passengers selectively disclose required credentials to airlines and border authorities, which verify them using decentralized identifiers and verifiable credentials. This process eliminates the need for repeated data collection while preserving authenticity and compliance. Similarly, universities utilize DIDs and VCs to issue tamper-proof digital diplomas that can be cryptographically verified by employers, thereby reducing administrative overhead and preventing credential fraud.

References

• W3C. (2022). “Decentralized Identifiers (DIDs) v1.0.” W3C Recommendation. Available at: https://www.w3.org/TR/did-core/
• W3C. (2022). “Verifiable Credentials Data Model v1.1.” W3C Recommendation. Available at: https://www.w3.org/TR/vc-data-model/
• Decentralized Identity Foundation. “DIDComm Messaging Specification.” Available at: https://identity.foundation/didcomm-messaging/spec/
• Hyperledger Aries Working Group. (2023). Aries Framework Overview. Available at: https://wiki.hyperledger.org/display/ARIES
• Trust over IP Foundation. (2023). ToIP Stack Overview. Available at: https://trustoverip.org
• OpenID Foundation, OpenID for Verifiable Credentials. Available at: https://openid.net/sg/openid4vc
• Fett, D., et al. (2024). Selective Disclosure for JWTs (SD-JWT). IETF Draft. https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt

Lightweight Directory Access Protocol

Lightweight Directory Access Protocol, or LDAP, was created in 1993 at the University of Michigan. It is a lightweight version of X.500 directory services protocols, such as the Directory Access Protocol (DAP). LDAP is a network protocol used to query and modify directory services over TCP/IP. This protocol is used by programs, applications, and systems to access and manage data stored in directories (databases that store data in a tree-like structure). The LDAP protocol facilitates the retrieval of data from directories quickly and easily. LDAP protocol can also be used by applications and systems to perform authentication as well as authorization against directories. The LDAP protocol is vendor-agnostic and provides primary functions, including authentication, search/query, add, delete, and modify/update. LDAPS is a secure version of the LDAP protocol that encrypts the communication between directories and clients while exchanging data. LDAPS is used to ensure the security and confidentiality of the data.

Real-World Application

Use cases for LDAP include:

• Retrieve information from directories
• Authenticate users
• Authorize users
• Add, delete, and update data in directories

As an example of a real-world application for LDAP, consider legacy applications. Every organization has legacy applications that cannot be integrated with a corporate Idp solution to achieve SSO or to delegate authentication. In this scenario, those applications connect with a corporate directory using LDAP to authenticate and authorize users into the applications.

In another scenario, a corporate system uses LDAP to authenticate users when they log in to the internal network. And LDAP directories also enable employees to connect to shared resources such as printers, file servers, or internal applications, streamlining access and management within corporate networks.

References

• Wahl, M., Howes, T., & Kille, S. (1997). Lightweight Directory Access Protocol (v3). RFC 2251, Internet Engineering Task Force (IETF). Available at: https://datatracker.ietf.org/doc/html/rfc2251 openldap.org+2Microsoft Learn+2
• Hodges, J., Morgan, R., & Wahl, M. (2000). Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. RFC 2830, IETF. Available at: https://datatracker.ietf.org/doc/html/rfc2830 IBM+1
• IETF FYI: Technical Overview of Directory Services Using the X.500 Protocol. RFC 1309, March 1992. Available at: https://datatracker.ietf.org/doc/html/rfc1309 rfc-editor.org
• Oracle Corporation. “X.500 Overview” (in Java tutorial for directory services). Available online: https://docs.oracle.com/javase/jndi/tutorial/ldap/models/x500.html Oracle Docs
• Microsoft Learn. Lightweight Directory Access Protocol (LDAP) – LDAP API. Available at: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api Microsoft Learn

Service Provisioning Markup Language

Service Provisioning Markup Language (SPML) is an XML-based protocol standardized by OASIS in 2006 for exchanging identity and service provisioning information between systems, applications, and services. It was designed to automate the creation, modification, and deletion of user and resource objects within enterprise environments.

The XML format provided a common language for identity provisioning and lifecycle management. However, SPML has become deprecated mainly due to its complexity, bulkiness, and slow performance. Most modern platforms have transitioned to SCIM, which offers better interoperability, simplicity, and REST/JSON-based communication.

Real-World Application

Common use cases for SPAML include:

• User provisioning and deprovisioning
• Access control management
• Automation to avoid or reduce manual work

SPML may be deprecated, but it still has current real-world applications. For example, when a new employee joins a large company, the HR system sends their details using SPML to the legacy IT systems that do not support newer protocols like SCIM. This allows the company to create the employee’s email account automatically, give access to internal tools, and set up payroll login, all without manual work.

References

• OASIS. (2006). “Service Provisioning Markup Language (SPML) Version 2.0.” OASIS Standard. Available at: http://docs.oasis-open.org/spml/spml-v2/spml-2.0-os.html

Remote Authentication Dial-In User Service

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users connecting to and using a network service. It is widely used by Internet Service Providers (ISPs) and enterprises to manage access to the Internet and internal networks, wireless networks, and other services. Older RADIUS implementations send some data in clear text, while modern RADIUS over TLS encrypts the communication for better security. This helps protect user credentials and sensitive network information from being intercepted.

By consolidating the AAA functions, RADIUS ensures that only authenticated and authorized users can access a network service while also maintaining detailed logs of user activity for auditing, billing, and reporting purposes. This centralized approach enhances security, simplifies administration, and provides a scalable solution for managing user access across diverse network environments, including wired and wireless networks, as well as other remote services.

Real-World Application

RADIUS servers are utilized in various scenarios to manage and secure network access through centralized AAA services. Here are some common uses of RADIUS servers:

• Wireless networks
• Virtual Private Networks (VPNs)
• Network Access Control (NAC)
• Enterprise networks

Consider the following example of RADIUS applied in the real world. A large enterprise uses RADIUS as part of its 802.1X Wi-Fi authentication system, which is integrated with Microsoft Active Directory. When an employee connects to the corporate Wi-Fi, the wireless access point acts as a RADIUS client, sending the user’s credentials—protected through EAP-TLS—to the central RADIUS server.

The RADIUS server verifies the user’s certificate against Active Directory, determines access rights based on group membership (e.g., corporate, guest, contractor), and returns an authorization response to the access point. Simultaneously, it logs session details for accounting and audit purposes.

This configuration allows centralized policy enforcement, fine-grained access control, and detailed visibility into network usage, forming a critical component of the organization’s Zero Trust network access strategy.

References

• Rigney, C., et al. (2000). “Remote Authentication Dial In User Service (RADIUS).” RFC 2865, Internet Engineering Task Force (IETF). Available at: https://tools.ietf.org/html/rfc2865
• Rigney, C. (2000). “RADIUS Accounting.” RFC 2866, IETF. Available at: https://tools.ietf.org/html/rfc2866

FIDO2 WebAuthN

FIDO2 is an open passwordless authentication standard designed to eliminate reliance on shared secrets (such as passwords) and mitigate risks from phishing, credential theft, and replay attacks. By shifting the authentication paradigm to public-key cryptography, FIDO2 ensures that the private key remains isolated on the user’s device, while the server verifies identity using a registered public key. The standard comprises two foundational components:

• Web Authentication (WebAuthn): A standardized browser API that enables relying parties (web applications and services) to register and authenticate users utilizing asymmetric public key credentials.

• Client-to-Authenticator Protocol (CTAP): A protocol that enables secure communication between host clients (browsers and operating systems) and authenticators over physical transport layers such as USB, NFC, or Bluetooth.

FIDO2 authenticators generate and store unique asymmetric key pairs per service, delivering a phishing-resistant, credential-less login experience across platforms. The framework supports both platform authenticators (built-in biometrics or TPMs) and roaming authenticators (external hardware security keys or mobile devices).

While most current implementations rely on elliptic curve or RSA algorithms, forward-looking enterprise deployments must account for future cryptographic risks. Selecting upgradeable hardware authenticators that support firmware updates ensures organizations can transition to emerging post-quantum cryptography standards without requiring a complete hardware replacement cycle as the technology evolves. Ultimately, FIDO2 enhances user adoption and digital workflows while significantly shrinking the attack surface within Identity and Access Management (IAM) systems.

FIDO2/WebAuthn supports a range of secure authentication scenarios:

• Passwordless login to enterprise systems and SaaS platforms
• Strong customer authentication (SCA) for banking and e-commerce
• MFA via biometric authenticators
• Secure employee access to sensitive systems (e.g., Zero Trust networks)
• Authentication in high-assurance environments (e.g., government, defense)

Real-World Application

• Example 1: Microsoft - Passwordless Enterprise Logi: Microsoft has integrated FIDO2/WebAuthn across its identity platform, enabling passwordless sign-in to Windows 10/11, Microsoft Entra ID (formerly Azure AD), and Microsoft 365 services. Users authenticate using platform authenticators (such as Windows Hello with TPM-backed biometric or PIN) or roaming authenticators (FIDO2 security keys). During login, the client platform invokes the WebAuthn API, triggering a challenge from the identity provider. The authenticator signs the challenge with its private key, and the IdP verifies it using the registered public key. This process ensures phishing-resistant authentication without transmitting shared secrets. Microsoft supports conditional access policies tied to FIDO2 authentication, enabling fine-grained access control based on device compliance, location, or risk signals

• Example 2: GitHub - Secure Account Access with FIDO2: GitHub supports FIDO2/WebAuthn for two-factor authentication and passwordless login via passkeys. Users register FIDO2-compatible authenticators, security keys (e.g., YubiKey, Titan Key), or platform biometrics (e.g., Face ID, Windows Hello) with their accounts. During login, GitHub sends a cryptographic challenge through the WebAuthn API. The FIDO2 authenticator signs the challenge with a private key (verified by biometric or PIN), and GitHub validates it using the stored public key. This phishing-resistant flow eliminates OTP codes and SMS-based 2FA vulnerabilities. GitHub’s passkey support enables single-gesture authentication (e.g., Face ID) that satisfies both password and second-factor requirements simultaneously, providing a seamless yet highly secure login experience

Security Consideration

While FIDO2 provides robust AAL2/AAL3 phishing resistance, the overall architectural security posture relies heavily on the account recovery and fallback mechanisms. A highly secure FIDO2 primary authentication flow can be easily undermined if the account recovery or helpdesk reset processes rely on weak, socially engineerable methods (e.g., SMS one-time password, security questions).

Comparing IAM Protocols and Standards

Choosing the right IAM protocol empowers organizations to unlock seamless interoperability, maximize operational efficiency, and build a resilient Zero Trust architecture. Each protocol is uniquely designed to excel at a specific stage of the identity lifecycle. Aligning the right tool with the right purpose ensures a secure, high-performance identity ecosystem. The analysis below highlights the core strengths and ideal use case of each protocol to help you select the perfect protocol for your strategic goals.

Protocol	Primary Purpose	AuthN/AuthZ	Use Cases
SAML	Federated authentication	Authentication	Enterprise SSO (legacy and SaaS)
OAuth 2.0	Delegated authorization	Authorization	API access, delegated app access
OIDC	Identity layer on OAuth	Authentication	Modern SSO, enterprise apps
SCIM	Identity lifecycle management	Provisioning/ deprovisioning	User and group sync to SaaS apps
IDQL	Identity data queries	Query/read operations	Identity data retrieval in IGA tools
DIDs	Self sovereign identity	Authentication (verifiable credentials)	Web3, privacy preserving identity
LDAP	Directory services	Authentication and directory lookup	On-premises directories (e.g., AD, LDAP)
SPML	Provisioning standard	Provisioning	Legacy IAM provisioning
FIDO2/ WebAuthn	Passwordless authentication	Authentication	Phishing resistant login

Table 14: A Comparison of IAM Protocols and Standards

References

• W3C. (2019). Web Authentication: An API for accessing Public Key Credentials – Level 2. Available at: https://www.w3.org/TR/webauthn-2/
• FIDO Alliance. (2020). Client to Authenticator Protocol (CTAP) Specification v2.0. Available at: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html
• FIDO Alliance. (n.d.). FIDO2 Overview. Available at: https://fidoalliance.org/fido2/
• Microsoft Corporation. Passwordless authentication options for Microsoft Entra ID. Microsoft Learn. Available at: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless
• Microsoft Corporation. Enable passwordless security key sign-in to Windows using Microsoft Entra ID. Microsoft Learn. Available at: https://learn.microsoft.com/en-us/entra/identity/devices/howto-authentication-passwordless-security-key
• GitHub, Inc., Configuring two-factor authentication. GitHub Documentation. Available at: https://docs.github.com/articles/configuring-two-factor-authentication
• GitHub, Inc. About passkeys on GitHub. GitHub Documentation. Available at: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-passkeys-on-github
• GitHub, Inc. Supported authentication methods. GitHub Documentation. Available at: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/supported-authentication-methods
• FIDO Alliance. Case Study: GitHub. Available at: https://fidoalliance.org/github-deploys-fido-authentication-to-secure-software-developers/
• NIST. Digital Identity Guidelines: Authentication and Authenticator Management (SP 800-63B-4). July 2025. Available at: https://csrc.nist.gov/pubs/sp/800/63/b/4/final
  • NIST SP 800-63B-4 defines Authenticator Assurance Levels (AALs):
  • AAL1: Single-factor authentication (e.g., password, SMS OTP)
  • AAL2: Multifactor, phishing-resistant authenticators (e.g., FIDO2 with biometric or PIN)
  • AAL3: Highest assurance, requiring hardware-based, non-exportable authenticators with verifier impersonation resistance (e.g., FIDO2 security keys)
  • FIDO2 deployments can meet AAL2 when using properly configured platform or roaming authenticators that satisfy verifier requirements, and hardware-bound implementations may achieve AAL3 when all relevant protections are in place.

Conclusion

Identity and access management is now a critical part of modern security, especially as identity-based attacks continue to rise. Attackers target user accounts, service accounts, and credentials more than ever, making strong identity controls essential for every organization. As businesses adopt cloud platforms, artificial intelligence, and other new technologies, the need for clear and effective identity standards becomes even more important.

This paper explains the key IAM standards, protocols, and practices, including authentication, authorization, multifactor authentication, passwordless methods, federation, provisioning, and access control models. With simple explanations, comparisons, and real-world examples, it helps security professionals understand when and how to use each standard.

Choosing the right approach can be difficult, but the information in this paper makes it easier to avoid mistakes and build a strong identity foundation. Identity threats will continue to grow, and organizations must stay prepared. This guide serves as a practical resource for security teams today, with future versions to cover new technologies and evolving identity challenges. Successful IAM modernization requires not only adopting standards like FIDO2 but also deliberately retiring legacy protocols such as SPML and LDAP to reduce risk and strengthen the organization’s overall security posture.

References

• Okta. 2024. “What Is LDAP & How Does It Work?”. Okta. https://www.okta.com/identity-101/what-is-ldap
• Rajat Bhargava. 2021. “What is LDAP? The Ultimate Guide”. Jump Cloud. https://jumpcloud.com/blog/what-is-ldap

• [SP 800-63-4, Digital Identity Guidelines

  CSRC](https://csrc.nist.gov/pubs/sp/800/63/4/final)

• SP 800-63A-4 ID Proofing
• SP 800-63B-4 Authentication
• SP 800-63C-4 Federation
• https://csrc.nist.gov/pubs/sp/1800/35/final

References (Full List)

Anderson, R. (2020). Security engineering: A guide to building dependable distributed systems (3rd ed.). Wiley. https://www.cl.cam.ac.uk/~rja14/book.html

Anthropic. (n.d.). Model context protocol (MCP) authorization. Model Context Protocol. https://modelcontextprotocol.io/docs/tutorials/security/authorization

Apple Inc. (n.d.). About Face ID advanced technology. Apple Support. https://support.apple.com/en-us/102381

Ayers, B. (n.d.). The beer drinker’s guide to SAML. Duo Security. https://duo.com/blog/the-beer-drinkers-guide-to-saml

Babeanu, A., & Shaikh, T. (2023, November 20). A taxonomy of modern authorization models. IDPro. https://idpro.org/a-taxonomy-of-modern-authorization-models/

Bhargava, R. (2021). What is LDAP? The ultimate guide. JumpCloud. https://jumpcloud.com/blog/what-is-ldap

Brigandi, G. (2022, May). First impressions of IDQL. Medium. https://medium.com/@gbrigandi/first-impressions-of-idql-8ef8b9de96d3

Cappalli, T., & Tulshibagwale, A. (2025). OpenID continuous access evaluation profile (CAEP) 1.0. OpenID Foundation. https://openid.net/specs/openid-caep-specification-1_0.html

Cloud Native Computing Foundation (CNCF). (n.d.). SPIFFE/SPIRE: Secure production identity framework for everyone. https://spiffe.io/

Cloud Security Alliance. (2024). State of non-human identity security survey report. https://cloudsecurityalliance.org/artifacts/state-of-non-human-identity-security-survey-report

Cybersecurity and Infrastructure Security Agency (CISA) & Federal Bureau of Investigation (FBI). (2024, December 18). Mobile communications best practice guidance. CISA. https://www.cisa.gov/sites/default/files/2024-12/joint-guidance-mobile-communications-best-practices_v2.pdf

Decentralized Identity Foundation. (n.d.). DIDComm messaging specification. https://identity.foundation/didcomm-messaging/spec/

Fett, D., Yasuda, K., & Campbell, B. (2024). Selective disclosure for JWTs (SD-JWT) (Draft, draft-ietf-oauth-selective-disclosure-jwt). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt

FIDO Alliance. (2019). Client to authenticator protocol (CTAP) specification v2.0. https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html

FIDO Alliance. (n.d.). Case study: GitHub deploys FIDO authentication to secure software developers. https://fidoalliance.org/github-deploys-fido-authentication-to-secure-software-developers/

FIDO Alliance. (n.d.). FIDO2 overview. https://fidoalliance.org/fido2/

FIDO Alliance. (n.d.). How passkeys work. Passkey Central. https://www.passkeycentral.org/introduction-to-passkeys/how-passkeys-work

FIDO Alliance. (n.d.). Passkeys. https://fidoalliance.org/passkeys/

GitHub, Inc. (n.d.). About passkeys on GitHub. GitHub Documentation. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-passkeys-on-github

GitHub, Inc. (n.d.). Configuring two-factor authentication. GitHub Documentation. https://docs.github.com/articles/configuring-two-factor-authentication

GitHub, Inc. (n.d.). Supported authentication methods. GitHub Documentation. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/supported-authentication-methods

Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems. SIAM Journal on Computing, 18(1), 186–208. https://doi.org/10.1137/0218012

Hardt, D. (Ed.). (2012). The OAuth 2.0 authorization framework (RFC 6749). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc6749

Hardt, D., Parecki, A., & Lodderstedt, T. (Eds.). (2024). The OAuth 2.1 authorization framework (Draft, draft-ietf-oauth-v2-1-14). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

Hexa Orchestration. (n.d.). Hexa policy orchestration: Overview and open source project. https://hexaorchestration.org/

Hodges, J., Morgan, R., & Wahl, M. (2000). Lightweight directory access protocol (v3): Extension for transport layer security (RFC 2830). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc2830

Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., & Scarfone, K. (2014). Guide to attribute-based access control (ABAC) definition and considerations (NIST Special Publication 800-162). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-162

Huang, K., Narajala, V. S., Yeoh, J., Ross, J., Lambe, M., Raskar, R., Harkati, Y., Huang, J., Habler, I., & Hughes, C. (2025). Agentic AI identity and access management: A new approach. Cloud Security Alliance. https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach

Hunt, P., Grizzle, K., Wahlstroem, E., & Mortimore, C. (2015). System for cross-domain identity management: Protocol (RFC 7644). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc7644

Hyperledger Aries Working Group. (2023). Aries framework overview. Hyperledger Wiki. https://wiki.hyperledger.org/display/ARIES

Jones, M. B., & Wahlstroem, E. (2015). SAML 2.0 profile for OAuth 2.0 client authentication and authorization grants (RFC 7522). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc7522

Jones, M., & Hardt, D. (2012). The OAuth 2.0 authorization framework: Bearer token usage (RFC 6750). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc6750

KuppingerCole Analysts AG. (2021). Addressing multi-cloud identity challenges with a new standard: IDQL [Video]. European Identity and Cloud Conference 2021. https://www.kuppingercole.com/watch/eic2021-gebel-multi-cloud-identity-challenges-idql

Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025). OAuth 2.0 security best current practice (RFC 9700). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc9700

Microsoft Corporation. (n.d.). Enable passwordless security key sign-in to Windows using Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/devices/howto-authentication-passwordless-security-key

Microsoft Corporation. (n.d.). Lightweight directory access protocol (LDAP) API. Microsoft Learn. https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lightweight-directory-access-protocol-ldap-api

Microsoft Corporation. (n.d.). Passwordless authentication options for Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless

National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE). (2025). Implementing a zero trust architecture (NIST Special Publication 1800-35). U.S. Department of Commerce. https://csrc.nist.gov/pubs/sp/1800/35/final

National Institute of Standards and Technology (NIST). (2017). Digital identity guidelines: Authentication and lifecycle management (NIST Special Publication 800-63B). U.S. Department of Commerce. https://pages.nist.gov/800-63-3/sp800-63b.html

National Institute of Standards and Technology (NIST). (n.d.). Role-based access control (RBAC) [Project page]. CSRC. https://csrc.nist.gov/projects/role-based-access-control

Neuman, C., Yu, T., Hartman, S., & Raeburn, K. (2005). The Kerberos network authentication service (V5) (RFC 4120). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc4120

OASIS. (2006). Service provisioning markup language (SPML) version 2.0. OASIS Standard. http://docs.oasis-open.org/spml/spml-v2/spml-2.0-os.html

OASIS. (2008). Security Assertion Markup Language (SAML) V2.0 technical overview. OASIS. http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

OASIS. (2013). eXtensible Access Control Markup Language (XACML) version 3.0. OASIS Standard. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

OASIS. (n.d.). Security Assertion Markup Language (SAML). https://www.oasis-open.org/standard/saml/

Okta. (2024). What is LDAP and how does it work? https://www.okta.com/identity-101/what-is-ldap

Okta. (n.d.). What Is single sign-on (SSO)? Okta. https://www.okta.com/blog/identity-security/single-sign-on-sso/

Open Policy Agent. (2024). What is OPA? https://www.openpolicyagent.org/docs/latest/

OpenID Foundation. (2024). Financial-grade API security profile 2.0 — Part 1: Baseline. https://openid.net/specs/fapi-2_0-security-02.html
OpenID Foundation. (n.d.). OpenID for verifiable credentials. https://openid.net/sg/openid4vc

Oracle Corporation. (n.d.). X.500 overview. Oracle Java Naming and Directory Interface (JNDI) Tutorial. https://docs.oracle.com/javase/jndi/tutorial/ldap/models/x500.html

OWASP. (n.d.). Multifactor authentication cheat sheet. OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html

PingIdentity. (n.d.). Your guide to FIDO2 passwordless authentication. https://www.pingidentity.com/en/resources/blog/post/fido2-passwordless.html

Richer, J., Fenton, J., Lefkovitz, N., Temoshok, D., Galluzzo, R., Regenscheid, A., & Choong, Y.-Y. (2025). Digital identity guidelines: Federation and assertions (NIST Special Publication 800-63C-4). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/63/c/4/final

Rigney, C. (2000). RADIUS accounting (RFC 2866). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc2866

Rigney, C., Willens, S., Rubens, A., & Simpson, W. (2000). Remote authentication dial in user service (RADIUS) (RFC 2865). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc2865

Rosetta Digital. (n.d.). RBAC vs. ABAC vs. PBAC. https://rosettadigital.com/rbac-vs-abac-vs-pbac-2/

Sakimura, N., Bradley, J., Agarwal, N., & Mortimore, C. (2015). Proof key for code exchange by OAuth public clients (RFC 7636). Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc7636

Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., & Mortimore, C. (2014). OpenID Connect Core 1.0. OpenID Foundation. https://openid.net/specs/openid-connect-core-1_0.html

Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-based access control models. IEEE Computer, 29(2), 38–47. https://doi.org/10.1109/2.485845

Security Boulevard. (2022, May). How to go from zero to a standard: Building IDQL/Hexa. https://securityboulevard.com/2022/05/how-to-go-from-zero-to-a-standard-building-idql-hexa/

SimpleCloud.info. (n.d.). System for cross-domain identity management (SCIM). https://www.simplecloud.info

Smith, J. K. (1992). Technical overview of directory services using the X.500 protocol (RFC 1309). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc1309

South, T., Nagabhushanaradhya, S., Dissanayaka, A., Cecchetti, S., Fletcher, G., Lu, V., Pietropaolo, A., Saxe, D. H., Lombardo, J., Shivalingaiah, A., Bounev, S., Keisner, A., Kesselman, A., Proser, Z., Fahs, G., Bunyea, A., Moskowitz, B., Tulshibagwale, A., Greenwood, D., Pei, J., & Pentland, A. (2025). Identity management for agentic AI: The new frontier of authorization, authentication, and security for an AI agent world. OpenID Foundation. https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf

Strata Identity. (2022). New identity standard IDQL/Hexa policy project. https://www.strata.io/resources/news/new-identity-standard-idql-hexa-policy-project/

StrongDM. (n.d.). NIST password guidelines: 2025 updates & best practices. https://www.strongdm.com/blog/nist-password-guidelines

StrongDM. (n.d.). What is attribute-based access control (ABAC)? https://www.strongdm.com/what-is/attribute-based-access-control-abac

Temoshok, D., Choong, Y.-Y., Galluzzo, R., LaSalle, M., Regenscheid, A., Abruzzi, C., Fenton, J., & Lefkovitz, N. (2025). Digital identity guidelines: Identity proofing and enrollment (NIST Special Publication 800-63A-4). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/63/a/4/final

Temoshok, D., Choong, Y.-Y., Galluzzo, R., LaSalle, M., Regenscheid, A., Proud-Madruga, D., Gupta, S., & Lefkovitz, N. (2025). Digital identity guidelines (NIST Special Publication 800-63-4). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/63/4/final

Temoshok, D., Choong, Y.-Y., Galluzzo, R., LaSalle, M., Regenscheid, A., Proud-Madruga, D., Gupta, S., & Lefkovitz, N. (2025). Digital identity guidelines: Authentication and authenticator management (NIST Special Publication 800-63B-4). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/63/b/4/final

Trust over IP Foundation. (2023). ToIP stack overview. https://trustoverip.org

Tulshibagwale, A., Cappalli, T., Scurtescu, M., Backman, A., Bradley, J., & Miel, S. (2025). OpenID shared signals framework specification 1.0. OpenID Foundation. https://openid.net/specs/openid-sharedsignals-framework-1_0.html

Wahl, M., Clauss, S., & Kille, S. (2012). System for cross-domain identity management: Core schema (RFC 7643). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc7643

Wahl, M., Howes, T., & Kille, S. (1997). Lightweight directory access protocol (v3) (RFC 2251). Internet Engineering Task Force (IETF). https://datatracker.ietf.org/doc/html/rfc2251

World Wide Web Consortium (W3C). (2019). Web authentication: An API for accessing public key credentials — Level 2. W3C Recommendation. https://www.w3.org/TR/webauthn-2/

World Wide Web Consortium (W3C). (2022). Decentralized identifiers (DIDs) v1.0. W3C Recommendation. https://www.w3.org/TR/did-core/

World Wide Web Consortium (W3C). (2022). Verifiable credentials data model v1.1. W3C Recommendation. https://www.w3.org/TR/vc-data-model/

Yubico. (n.d.). FIDO2 passwordless authentication. https://www.yubico.com/authentication-standards/fido2/