Part 13: Identity Management in the era of AI and LLMs

What’s wrong with modern authentication, and why IAM is not about tokens at all…

Part 0: What Modern Identity Management Solutions Should Look Like?

Part 1: The Datastore

Part 2: Connectors

Part 3: The Sync Engine

Part 4: The Workflow Engine

Part 5: The Customers and What to deploy?

Part 6: Engineering challenges - Connectors

Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?

Part 8: IAM People Management challenges

Part 9: The Unspoken Realities of Identity Management

Part 10: Confessions of a Former Hacker: From Script Kiddie to Identity Management Advocate

Part 11: What Are the Gaps in Current Identity Management Solutions?

Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Part 13: Identity Management in the era of AI and LLMs

Part 14: Future Trends in Identity Management for 2025-2030

In today’s world of web-based authentication, large language models (LLM), artificial intelligence (AI), and their agents, the proper vision for Identity and Access Management (IAM) is more crucial than ever. IAM has become exponentially more complex. While program managers focus on releasing new features to achieve promotions, and cybersecurity concerns are sometimes overlooked, this article highlights the risks tied to modern authentication and authorization models and explores possible solutions. It’s also worth noting that history often repeats itself, with many “new cool features” being old concepts in disguise.

Before diving into the gaps in modern authentication and authorization scenarios, as well as the new challenges introduced by LLMs and AI agents, let’s revisit the history of IAM.

Maturity Levels of Identity Management

The concept of Identity and Access Management has significantly evolved over the last three decades. Today, the job description of an IAM engineer has transformed entirely from what it was in the 1990s. More often than not, “IAM Engineering” today involves configuring authorization claims, registering applications, and managing federation providers with pre-configured session protection features.

Identity Management (IdM) Childhood

Identity Management in its early stages was a combination of three essential components: synchronization servers, directory servers, and authorization servers. These elements worked together to establish foundational identity and access management systems.

·?????? Synchronization Servers: Solutions such as Microsoft Identity Integration Server (MIIS), Sun ONE Identity Manager, Oracle Identity Manager, and Tivoli Identity Manager were used to synchronize identity data across different systems.

·?????? Directory Servers: Core directory services included Windows NT/Active Directory Domain Services (AD DS), Sun One Directory Server, Oracle Internet Directory, and various other products like Oracle Directory Server Enterprise Edition, Oracle Unified Directory, Oracle Virtual Directory, and OpenLDAP.

·?????? Authorization Servers with Single Sign-On: These included AD DS, Active Directory Federation Services (AD FS), Oracle Authentication Services for Operating Systems (OAS4OS), OpenAM (based on Sun Access Manager), and Tivoli Access Manager.

The primary objective was to collect data from HR feeds, integrate it into internal identity stores, enrich it with enterprise-specific data, and provision user accounts into target directories. These accounts were kept current through processes such as Joiner, Mover, and Leaver (JML) scenarios. Directory servers played a critical role, handling user authentication and issuing session and access tokens (e.g., Kerberos Ticket Granting Tickets, Kerberos Ticket Granting Sessions, JAAS, or SAML tokens). Resource servers used these access tokens to determine and enforce appropriate access levels.

Today, the foundational role of Identity Management in IAM solutions is often overlooked, creating significant risks for enterprises that focus primarily on managing claims and tokens without a comprehensive identity strategy.

Identity and Access Management (IAM) Youth

As web-based applications expanded, the limitations of traditional authentication methods became apparent, prompting the introduction of web-based authentication mechanisms like SAML tokens. These methods, however, brought new risks, including token theft, reuse, and replay attacks. This evolution highlighted the need for enhanced Access Management, which led to the development of session protection mechanisms such as token bindings. Notably, features like token protection and token bindings, now being introduced in Entra ID, were already present in AD FS over a decade ago, addressing the same challenges.

Both SAML and Kerberos tokens faced significant issues. For example, Kerberos Golden and Silver tickets posed security risks, and tokens often included all groups a user belonged to. This not only exposed enterprise-wide access details to resource servers but also caused practical problems. On Solaris x86 machines with PAM_KRB5 modules, Kerberos TGS tokens larger than 4KB – common for users in 20-30 groups – would crash the system. Although some Tivoli and Oracle products offered solutions to limit the groups included in tokens, their expensive TIM/TAM/OIM suites struggled in the market due to pricing issues and eventually faded away.

Today, Access Management is frequently reduced to a narrow focus on issuing authentication and authorization tokens, mapping groups to token claim fields, and enabling token protection features. However, this approach often neglects the broader identification, authentication, and authorization processes. Without comprehensive Identity Management processes in place, Access Management alone cannot provide adequate security.

Identity Management and Access Governance Administration (IGA) Adulthood

The growing need to comply with government and industry standards led to the introduction of products and features that support critical governance capabilities, such as Segregation of Duties, the 4-eyes principle, Attestation Reviews, and Role-Based and Attribute-Based Access Control models. While solutions like Entra ID Governance Services, SailPoint Identity IQ/Now, Okta, and Saviynt are often marketed as innovative, a closer look at history reveals similar functionality in legacy tools like IBM Tivoli Access Manager, Oracle Access Manager, CA SiteMinder, NetIQ Access Manager, Forefront Identity Manager with the bHold suite, and SAP NetWeaver. These older solutions targeted on-premises directories with comparable effectiveness.

It is essential to recognize that purchasing governance services – such as Access Reviews – or session protection services – like Token Binding – without establishing a robust Identity Management process for Joiner, Mover, and Leaver (JML) scenarios exposes organizations to significant risks. Without a strong foundational process in place, these governance tools cannot deliver the intended security benefits.

Let’s Talk About the ‘A’ in IAM

The ‘A’ in IAM stands for ‘Access,’ but what does Access Management truly mean?

At its core, the ultimate goal of IAM is to identify a user, securely verify their identity, and grant them the minimal authorization required to perform their job. This principle ensures both security and operational efficiency.

To better understand Access Management, it’s helpful to revisit its history. By comparing legacy authentication and authorization methods with modern ones, it becomes clear that these approaches are strikingly similar. Consequently, they share many of the same risks, limitations, and challenges, despite technological advancements.

Legacy Authentication and Authorization Protocols

Many early authentication protocols, such as LM, NTLM, and those offered by IBM, Sun, and Oracle in the 2000s (e.g., JAAS), have largely fallen by the wayside. The only protocol that has endured across enterprises is Kerberos 5.

Kerberos

As its name suggests, Kerberos is a “three-headed guardian dog”, consisting of a Key Distribution Center (KDC), the client user, and the resource server. Its basic flow operates as follows:

·?????? User Identification and Authentication

The user identifies themselves using an account name (e.g., sAMAccountName) or a user principal name (UPN), and authenticates to the KDC with either a password, a certificate, or another single-factor or multi-factor authentication method.

·?????? Ticket-Granting Ticket (TGT)

The KDC validates the user’s credentials against the directory store and issues a Ticket-Granting Ticket (TGT). The TGT is valid for the local domain, typically for 10 hours, and can be renewed without requiring re-authentication. It may also include the user’s IP address for added protection against man-in-the-middle attacks – akin to modern Token Binding (currently in preview).

·?????? Secure TGT Storage

The TGT is stored in the local machine’s volatile memory and remains inaccessible to applications. As a main session token, it is used to obtain access tokens when the user requests access to a resource server.

·?????? Ticket Granting Service (TGS)

The user presents the TGT to the KDC, specifying the service principal name of the resource they wish to access. The KDC issues a Ticket Granting Service (TGS) ticket, encrypted for the requested service principal. This ticket also contains the user’s group memberships.

·?????? Resource Server Access

The user presents the TGS ticket to the resource server. The server evaluates the ticket’s contents to decide whether to grant access and, if so, at what level.

Does this flow sound familiar? It mirrors modern authentication and authorization methods in many ways.

One of the strengths of Kerberos in Windows environments is its secure implementation. Applications cannot access the LSASS process or ticket storage, ensuring malicious apps cannot steal a TGS ticket. Everything occurs at the machine level, simplifying development: developers only need to configure a connection string to enable SSPI. For system administrators, there’s no need for extensive registration of applications, secret management, or complex federation setups. Joining a server to an NT/AD DS domain is sufficient. For impersonation needs, Kerberos Constrained Delegation was also available.

Challenges of Kerberos

Despite its strengths, Kerberos has several notable limitations:

·?????? Limited Authentication Mechanisms: Only passwords and PKINIT (certificate-based authentication) are commonly used, necessitating password rotation, certificate renewal, and robust PKI management (e.g., AIA, CDP, CRLs, and enterprise trusts). Managing service account credentials in secure vaults remains a challenge.

·?????? Access Control Complexity: Access control depends heavily on the application’s model. Kerberos only provides a user principal name and group memberships, requiring Identity Management solutions to map directory groups to resources and roles. Group membership alone doesn’t answer questions about user access rights.

·?????? Excessive Group Data in Tokens: TGS tickets include all groups a user belongs to, even irrelevant ones, leading to inefficiencies.

·?????? Security Risks: Vulnerabilities include Golden and Silver ticket attacks, unconstrained delegation, and other exploits.

·?????? Federation and Trust Issues: Cross-forest trusts create administrative burdens, requiring management of AD DS Foreign Security Principals, SID-history, and Shadow Security Principals.

·?????? Infrastructure Dependencies: Kerberos relies on DNS and ideally LDAP servers. KDCs must not be exposed to the internet.

·?????? Internet Incompatibility: Kerberos is unsuitable for cross-domain authentication on the internet. For example, Google.com users cannot authenticate to LinkedIn.com resources using Kerberos.

Securing Kerberos

Hardening Kerberos implementations and AD DS requires advanced system administration and cybersecurity expertise, making secure operations costly. However, tools, training, and professional services are widely available to support AD DS management. The key is not to leave these systems unattended.

Proper Identity Management processes are also essential to maintain directory integrity for authentication and authorization. Access Management in this context becomes more of a?Cybersecurity responsibility?than an Identity Management task. Ideally, AD DS administration should be handled by a separate, specialized team, not the Identity Management team.

Modern Authentication and Authorization Protocols

With the rise of SaaS platforms and services, the need to authenticate remote users and support lightweight clients led to the development of modern authentication and authorization methods. Ironically, many of these so-called modern protocols – such as WS-Trust, WS-Federation, SAML, OAuth and OIDC, JWT ?– existed in AD FS for years and are far from new.

Security Assertion Markup Language (SAML)

SAML became the modern equivalent of what RADIUS was for dial-ups and VPNs – an open standard for authentication and authorization, also offering single sign-on (SSO) for web clients. While earlier versions and flavors like Shibboleth were available, SAML 2.0 became the most widely adopted version.

?

When comparing the SAML SSO flow with Kerberos, striking similarities emerge, particularly in the roles of the three parties: the user, the service provider, and the identity provider (IdP). Even the flow is almost identical:

·?????? Initial Resource Access

The user attempts to access a resource, triggering an "Authentication required" response. The user must present an access token to prove their identity.

·?????? Redirection to Identity Provider

The resource provider (service provider) redirects the user to the identity provider (IdP), much like how a domain user discovers a KDC via DNS SRV records in Kerberos.

·?????? User Authentication

If the IdP has no existing session (security context) for the user, it must authenticate the user using any available method: basic authentication, form-based login, integrated Windows authentication, Kerberos, certificates, or even Dallas TouchID.

·?????? Token Issuance

Once authenticated, the IdP provides the user with a SAMLResponse XML element (analogous to a TGT in Kerberos). This is passed to the service provider to establish a security context (similar to a TGS in Kerberos).

·?????? Access to Resource

The user is redirected back to the originally requested resource.

Much like Kerberos, the majority of SAML communication occurs via front-end exchanges, with no direct back-channel communication between the service provider and the IdP. Although SAML references and back-channel validations could technically enhance security, they are rarely implemented in practice.

Challenges with SAML

SAML 2.0 was adequate for its time (2005) but came with significant limitations:

·?????? Configuration Complexity

Both the identity provider and the service provider required manual setup, including pre-shared keys and certificates to establish mutual trust.

·?????? Security Risks

SAML itself wasn’t inherently insecure, but its reliance on XML and SOAP, coupled with vulnerable browser environments, made it prone to exploitation.

·? Malware, viruses, and malicious browser extensions could access local cookie stores.

·? Man-in-the-middle attacks via proxy servers at hotels, airports, or malicious Wi-Fi hotspots became common.

·? Cross-site scripting, <iframe> abuse, and buggy JavaScript DOM further weakened security.

·? Malicious DNS servers redirected users to fake IdPs to harvest passwords.

·? Tools to lock down browsers and mitigate these risks were virtually nonexistent.

?·?????? Chaos in Security Contexts

Unlike Kerberos, where applications had no access to the security context, SAML gave user applications direct access, leading to widespread vulnerabilities. Additionally, developers often disliked XML and SOAP, favoring newer technologies like JavaScript Object Notation.

·?????? Service-to-Service Authentication

The need for service-to-service authentication – or user impersonation – exposed SAML’s limitations. Kerberos was unavailable due to the complexities of AD forests and trusts. While SAML theoretically supported authorization via metadata in assertions, its implementation was overly complicated and restrictive.

Ultimately, while SAML offered valuable solutions for its time, its inherent complexity and limitations, combined with the advent of new standards, have relegated it to a less prominent role in modern authentication.

Pre-shared Keys / API keys

The need for inter-service web communication has unfortunately revived a problematic practice: single-factor authentication using pre-shared keys or certificates. This method, often the only option available, is among the least secure. If a pre-shared key is compromised, anyone with the key can access the API – particularly if the API endpoint is public and lacks private endpoints with conditional access.

Solutions like Entra ID and AWS attempt to mitigate these risks by offering automated injection and rotation of certificates into cloud virtual machines or containers. This approach, known as Entra ID System- or User-Assigned Managed Identities Authentication, simplifies basic authentication via certificates by eliminating the need for manual management.

However, this convenience comes at a cost. Certificates injected into virtual machines or containers are accessible to any local administrator. Anyone with sufficient access to the VM can effectively act as the managed identity. This design choice is treated as a feature rather than a security flaw, prioritizing convenience over robust security.

Ideally, managed identities should be tied to specific service accounts, and certificates should be stored in dedicated user certificate stores. Unfortunately, this functionality is currently unavailable, leaving systems vulnerable to exploitation by attackers who know how to exploit these weaknesses.

Open Authorization (OAuth)

OAuth is an open standard for access delegation that allows websites or services to act on behalf of a user. For example, a financial app like Invent.us can collect tax forms from banks and brokers, or act on its own behalf. While OAuth facilitates access to resources, it is not an authentication protocol and is primarily used to access personal data.

In the OAuth framework, the client is not the user but a web application or service. The user, acting as the resource owner, grants consent to the client to access resources within a limited scope. OAuth, as the name implies, is designed to authorize a client’s actions against a resource server. This is achieved by providing an access token (similar to a TGS in Kerberos) obtained from an authorization server (akin to a KDC) after the resource owner grants consent. Notably, OAuth's scope-based delegation differs from Kerberos’ group membership-based access.

OAuth’s Limitations

OAuth is fundamentally an authorization protocol, not an authentication protocol. Using OAuth for authentication purposes is often called pseudo-authentication, which introduces significant limitations.

·?????? Authentication Issues: OAuth does not verify the identity of the caller, nor does it provide information about when or how the user was authenticated.

·?????? Enterprise Challenges: In environments with discrete Access Control Lists (ACLs) and multiple resource owners, OAuth proves only partially useful. OAuth scopes are often overly simplistic, limiting the granularity of access control.

Additionally, OAuth introduces serious security risks when web applications store and renew OAuth authorization codes:

·?????? If such a server or its storage is compromised, attackers could gain access to sensitive data at scale. For example, the bank statements of millions of users could be exposed if a hacked server stores their tokens.

·?????? These risks add new attack vectors, such as SQL injections and exploitation of insecure storage mechanisms.

OAuth - The User Perspective

Despite its risks, OAuth is relatively user-friendly. It simplifies the user experience with a straightforward “Grant Consent” button. However, this simplicity comes at the cost of transparency and control:

·?????? Consent pages rarely allow users to select specific scopes, forcing them to grant full access to proceed.

·?????? Once granted, users seldom review or revoke their permissions.

In the consumer identity space, Access Reviews are virtually nonexistent. Organizations and developers often collect, sell, or utilize user data, providing little incentive to implement granular scope selection or user-access review features. For apps, the more extensive the granted access, the greater the opportunities for data usage and monetization.

OAuth’s design prioritizes user convenience but leaves significant gaps in security, particularly in high-stakes enterprise and multi-user environments.

OpenID Connect (OIDC)

OpenID Connect addresses the authentication shortcomings of OAuth by introducing a "notarized referral letter" in the form of a digitally signed token. This token contains information about the user's identity, such as a user principal name or email address. The authentication flow for OIDC closely resembles the process used in Kerberos:

·?????? User Authentication Attempt

The user tries to access a website or application, triggering the need for authentication.

·?????? Redirection to Identity Provider

The user is redirected to an identity provider (e.g., corporate AD FS, Entra ID, Google, or Facebook) to authenticate using any available method (analogous to obtaining a TGT in Kerberos).

·?????? Token Issuance

The identity provider issues a small, digitally signed token containing the user’s identity (similar to a TGS in Kerberos).

·?????? Token Presentation

The user passes the OIDC token to the application, which uses it to establish the user’s identity and enable secure access.

For a clear visual explanation of how OAuth and OIDC differ, Wikipedia provides an excellent diagram comparing their workflows.

Together, the combination of OIDC and OAuth tokens is becoming the standard for consumer authentication and authorization, offering a balance of security and usability in modern applications.

Modern Authentication and Authorization Methods

Modern authentication methods have evolved to enhance security and usability, reducing reliance on traditional passwords. Just to name a few:

Biometric Authentication

·?????? Fingerprint Scanning: Uses unique fingerprint patterns.

·?????? Facial Recognition: Analyzes facial features using cameras or infrared sensors.

·?????? Iris/Retina Scanning: Scans the eye for unique patterns.

·?????? Voice Recognition: Identifies users based on their voice.

·?????? Behavioral Biometrics: Tracks unique user behaviors, such as typing patterns or mouse movements.

While biometrics can be highly effective for physical access control, their direct use for authenticating applications remains uncommon. Instead, biometrics are most often employed as a second authentication factor to unlock other credentials, such as a private key stored on a token.

Multi-Factor Authentication (MFA)

Multi-Factor Authentication (MFA) combines two or more authentication factors to enhance security:

·?????? Something You Have: Smartcards, hardware tokens, or mobile apps like Google Authenticator.

·?????? Something You Are: Biometrics.

·?????? Something You Know: PINs or security questions.

It’s important to note that MFA is not a standalone authentication method but rather a combination of these methods.

Passwordless Authentication

·?????? Magic Links: A one-time link sent to the user's email for login.

·?????? One-Time Passcodes (OTP): Sent via SMS, email, or an authenticator app.

·?????? Push Notifications: Sent to a trusted device for approval.

·?????? QR Code Scanning: Scanning a QR code with a trusted device to authenticate.

Passwordless authentication is highly effective, provided you have a trusted device running an authenticator app. However, legacy OTP codes sent via SMS or email should be avoided due to numerous security vulnerabilities. Ideally, a trusted, managed device – such as a smartphone – should comply with corporate policies, run an authenticator app capable of handling push notifications or QR code scans, and have its access protected by biometrics. This setup mirrors the reliability of the old days with hardware SecurID tokens and RADIUS authentication.

Hardware-Based Authentication

·?????? Security Keys: Devices like YubiKey or Google Titan that comply with FIDO2/WebAuthn standards.

·?????? Smart Cards: Physical cards with embedded chips.

·?????? Trusted Platform Modules (TPMs)

Smartcards

Smart cards are an excellent authentication method. They offer secure authentication, and in 99% of cases, duplication is nearly impossible – unless Microsoft Identity Manager (MIM CM) is used to generate a key pair outside the cryptographic processor and import a private key onto the card later. Smart cards provide two-factor authentication, with private keys typically protected by a PIN. Additionally, they can incorporate a photo of the owner and RFID chips for physical access, combining multiple uses in one card.

One of the greatest advantages of smart cards is their ability to simplify onboarding processes. For example, organizations can issue pre-enrolled smart cards for new joiners with certificates installed, but without a PIN (with a randomized, unknown PIN to be precise). These cards can then be shipped to new hires, who can unblock the cards themselves upon receiving them.

However, there are challenges associated with smart cards:

·?????? They require the operation of a public key infrastructure (PKI).

·?????? Organizations must maintain card printers, replace broken or worn cards, and resolve issues like poor contact with card readers.

·?????? Compatibility is a significant limitation – 99% of laptops and all smartphones lack built-in card readers.

Trusted Platform Modules (TPMs)

TPMs function like embedded smart card cryptographic processors that are permanently integrated into a computer or smartphone motherboard. They offer the same security benefits as smart cards but remain "always plugged in."

Modern USB Tokens (FIDO2)

FIDO2 tokens are essentially modern smart cards in a compact, USB-based form factor. Unlike traditional smart cards, they support advanced protocols like Client-To-Authenticator Protocols (CTAP) for wireless communication and WebAuthn specifications.

FIDO2 tokens, especially when protected by PINs or biometric safeguards, represent the best balance of usability, convenience, and security available today. Smartphones and TPM chips holding passkeys also fall into this category, providing a robust authentication solution.

The primary challenge with FIDO2 tokens is their initial assignment. This process can either be centralized, similar to smart cards, or rely on a bring-your-own-token (BYOT) model. In BYOT scenarios, users must authenticate themselves to assign their FIDO2 tokens – a process that often brings us back to passwords, even if only temporarily. These short-lived passwords, sometimes called "Temporary Access Pass", are still passwords, presenting a familiar security trade-off.

Behavioral Authentication

·?????? Analyzes user behavior patterns, such as typing speed, device usage, or geolocation, to verify identity.

This method is commonly employed in conditional access policies and CAPTCHAs to enhance security by identifying deviations from typical user behavior.

Token-Based Authentication

Token-based authentication involves the use of tokens to facilitate secure access to APIs and resources:

·?????? JWT (JSON Web Tokens): Issued upon login and used to access APIs and other resources.

·?????? OAuth Tokens: Commonly used for third-party app authentication, such as "Sign in with Google."

This approach is considered "secondary" authentication, as obtaining a token requires prior authentication with an identity provider using another method.

Certificate-Based Authentication

·?????? Uses digital certificates stored on devices or smart cards to verify identity.

This method is significantly more secure than passwords but requires a public key infrastructure (PKI) to manage, making it relatively expensive to implement and maintain.

Federated Authentication

·?????? Allows users to authenticate across multiple systems using a single identity provider (e.g., SSO with Google, Microsoft, or Okta).

It is considered "secondary" authentication, as users must first authenticate with the identity provider using another method to obtain the necessary token.

Blockchain-Based Authentication (DID)

·?????? Decentralized authentication using blockchain technology to verify identity without centralized credentials.

The concept aims to replace traditional, costly public key infrastructure (PKI) with a blockchain, where certification authorities are replaced by trusted issuers, such as a USPS office validating a driver’s license.

While the idea is promising, its adoption remains limited. Early adopters and pioneers have yet to see significant benefits, slowing its broader implementation.

Proximity-Based Authentication

·?????? Uses devices nearby (e.g., Bluetooth or NFC) to authenticate users automatically.

While convenient, it is not sufficiently secure as a single-factor authentication method. Similar approaches, like Dallas TouchID buttons, have largely fallen out of favor due to their limitations.

Modern Authentication and Authorization Problems

Let’s examine some of the key issues, threats, and mitigations associated with OIDC and OAuth protocols (and reviewing this list, it’s hard not to miss the simplicity of Kerberos).

Common Problems

Misconfigured Redirect URIs

·?????? Problem: Allowing overly permissive redirect URIs can lead to security vulnerabilities.

·?????? Impact: Attackers may exploit open redirect vulnerabilities to intercept authorization codes or tokens.

·?????? Solution: Use exact match validation for redirect URIs and avoid wildcards.

Insecure Token Storage

·?????? Problem: Storing tokens insecurely on the client side (e.g., in local storage or cookies without proper security flags).

·?????? Impact: Tokens may be stolen via cross-site scripting (XSS) or other attacks.

·?????? Solution: Use secure storage mechanisms like HTTP-only cookies or secure device storage.

Lack of Token Expiry and Rotation

·?????? Problem: Long-lived tokens or lack of token rotation increases exposure if tokens are compromised.

·?????? Impact: Prolonged unauthorized access.

·?????? Solution: Implement short-lived tokens with refresh tokens and monitor for anomalies.

Insufficient Scopes

·?????? Problem: Granting excessive or insufficient scopes to applications.

·?????? Impact: Applications may gain more permissions than needed or fail to function as intended.

·?????? Solution: Use the principle of least privilege and clearly define scopes.

Poor Error Handling

·?????? Problem: Leaking sensitive information in error messages or redirecting users to untrusted locations on errors.

·?????? Impact: Attackers may exploit these details for reconnaissance.

·?????? Solution: Sanitize error responses and avoid exposing sensitive data.

Common Threats

Authorization Code Interception

·?????? Threat: An attacker intercepts the authorization code during the redirection process.

·?????? Impact: The attacker can use the intercepted code to obtain access tokens.

·?????? Mitigation: Use PKCE (Proof Key for Code Exchange) to secure authorization codes.

Token Replay Attacks

·?????? Threat: Stolen tokens are reused by attackers to impersonate users.

·?????? Impact: Unauthorized access to resources.

·?????? Mitigation: Use token binding or implement one-time-use tokens.

Cross-Site Request Forgery (CSRF)

·?????? Threat: An attacker tricks a user into performing unwanted actions on an authenticated session.

·?????? Impact: Unauthorized actions performed on behalf of the user.

·?????? Mitigation: Use CSRF tokens and enforce state parameter validation in OAuth flows.

Phishing Attacks

·?????? Threat: Fake login pages trick users into providing credentials.

·?????? Impact: Compromise of user credentials.

·?????? Mitigation: Educate users to verify URLs and use anti-phishing mechanisms like browser warnings.

Token Leakage via Browser History

·?????? Threat: Tokens included in URLs (e.g., as query parameters) may be exposed in browser history or logs.

·?????? Impact: Token compromise.

·?????? Mitigation: Use the authorization code flow with PKCE and avoid passing tokens in URLs.

Lack of Audience Validation

·?????? Threat: Tokens intended for one audience are accepted by another.

·?????? Impact: Unauthorized access if tokens are misused.

·?????? Mitigation: Always validate the audience claim in tokens.

Open Redirects

·?????? Threat: Open redirects in the authorization server or client application.

·?????? Impact: Attackers can exploit redirects to steal tokens or credentials.

·?????? Mitigation: Avoid open redirects and validate redirect URIs strictly.

Session Fixation

·?????? Threat: An attacker forces a user to use a known session ID.

·?????? Impact: Session hijacking.

·?????? Mitigation: Regenerate session IDs after authentication.

Best Practices for Mitigation

Some very obvious statements, yet very valid:

·?????? Limit group claims to specific groups.

·?????? Use application roles instead of group claims to reduce token size.

·?????? Configure group filtering for tokens issued to specific applications.

·?????? Follow Security Standards: Adhere to OAuth 2.1 and OIDC security best practices.

·?????? Use HTTPS: Always enforce HTTPS for secure communication.

·?????? Implement PKCE: Protect authorization codes in public clients.

·?????? Monitor and Audit: Log and monitor for suspicious activities.

·?????? Educate Developers: Ensure developers understand potential risks and secure implementation techniques.

If you really want to dive into Cybersecurity, then Steve Turner compiled a list of interesting reads.

By addressing these problems and threats, organizations can significantly improve the security and reliability of their OIDC and OAuth implementations.

The Gaps in Modern Authentication and Authorization

Modern authentication and authorization heavily rely on various tokens (similar to TGS in Kerberos). However, obtaining these tokens still requires authentication with an identity provider, and no method is entirely without flaws:

·?????? Passwords: Weak and prone to compromise.

·?????? FIDO2 Tokens: Require pre-authentication through other methods to generate passkeys or necessitate centralized management.

·?????? Smartcards: Effective but expensive and inconvenient.

·?????? Third-Party Logins: Options like "Login with Google" or SAML/OAuth/OIDC do not eliminate security risks for the identity provider.

Beyond authentication challenges, modern web applications have introduced additional risks through simplified and basic access control models.

The Decline of Fine-Grained Permissions

Two decades ago, file shares used precise Access Control Lists (ACLs) with features like directory traversal, inheritance, and granular permissions (e.g., "List"). ACLs were tied to AD DS security groups, often nested, making access models relatively simple: if a TGS token contained a group SID listed in the folder ACL, access was granted. Since ACLs were part of the NTFS file system, file servers required minimal effort to validate permissions.

In contrast, modern web applications and JWT tokens have simplified security models to the point of losing fine-grained control. Authorization rules are often reduced to basic scopes, such as:

·?????? Operation: GET, PATCH

·?????? Scope: Movies (where "Movies" denotes a target resource type).

OAuth authorizations suffer from the same problem. For example, granting an application access to your OneDrive means granting access to the entire OneDrive – without options to restrict access to specific folders or labels.

A Better Approach: Policy Servers

Once I was developing a proper access model for my friends at Invent.US, and we concluded that relying solely on authorization tokens was insufficient. Instead, we explored implementing a policy server, such as Ory Keto or Google Zanzibar (and its forks). When I first discovered Zanzibar’s architecture, I was genuinely impressed by its capabilities and scope outside the Microsoft ecosystem.

Rather than building a full-blown Identity Management Solution to populate the Keto database with owners and objects, we opted for a simpler approach. We introduced an application manifest that lists all system roles, permissions, object types, and related artifacts. This manifest could be easily imported into Keto, streamlining implementation while retaining flexibility.

I hope that Ory continues to receive sufficient support and funding to refine their products, eventually establishing them as the new "baseline architecture" for modern access control. Their success could pave the way for more secure and robust authorization models in an increasingly token-driven world.

What About LLMs and AI Agents?

The real impetus behind writing this article stems from the resurgence of issues that enterprise search engines previously grappled with, now resurfacing due to the widespread adoption of large language models (LLMs) and AI agents. History, as it often does, is repeating itself. To simplify the discussion, think of LLM models and their query results as an index server with a database, and AI agents as web crawlers operating under a service identity principal.

A Legacy Use Case

Consider a legacy scenario: a file share with documents that are access-controlled (ACLed) to specific security groups, a SharePoint library with its own ACL, some documents protected by Active Directory Rights Management Services (AD RMS) labeled as “confidential”, and others encrypted.

The primary goal in such a setup was clear: ensure that confidential data would only appear in search results for users who had the appropriate access rights.

How was this achieved?

An indexer needed to access all documents across the system, operating under a "root" or admin account. It also needed to:

·?????? Consume Protected Data: This included handling encrypted or rights-protected content by using AD RMS Recovery Agent keys.

·?????? Preserve Access Control: The indexer stored the original ACL for each document it indexed and respected these ACLs when rendering search results.

However, a challenge arose when ACLs were updated after the document was indexed. To address this, best practices at the time recommended assigning users to project groups, then including those project groups within resource groups. The resource groups, in turn, controlled access. This setup ensured that shared folder ACLs remained static, while only project group memberships needed to be managed. And it worked.

The Current Landscape and Emerging Risks

Today, with the absence of Active Directory Domain Services (AD DS) and security groups, companies like Anthropic are proposing new protocols like the Model Context Protocol, built around OAuth. This evolution introduces potential risks. Imagine scenarios where sensitive data – like Office Activation keys or management salary details – accidentally appears in LLM query results. Worse still, consider LLM models deployed in federal clouds, where AI agents crawl OneDrive and SharePoint libraries under a "root" context.

Unless changes are made, these risks could escalate quickly.

Key Recommendations:

·?????? Preserve Access Controls: AI agents must not only parse documents but also preserve the original ACLs for every document chunk. This is especially important as parts of documents might be protected differently (e.g., AD RMS encryption or confidentiality labels).

·?????? Dynamic ACL Verification: When rendering LLM query results, AI systems must consult policy servers like Ory Keto or Google Zanzibar to verify the current ACLs, rather than relying on static OAuth authorizations.

Additionally, storing models in unsecure locations (e.g., S3 buckets) without ACLs can lead to unauthorized access by infrastructure administrators. History has already shown how improperly configured storage accounts exposed sensitive data on the internet – this risk cannot be ignored.

A Glimmer of Hope

Fortunately, some progress is evident. For instance, CoPilot appears to have implemented at least one of the necessary requirements for secure data handling. It’s reassuring to think that CoPilot’s team may have drawn insights from systems like SharePoint’s FAST Search, which also grappled with preserving ACLs in indexed results.

The Vital Role of Identity Management

Having a robust policy server like Keto or Zanzibar is only part of the solution. Since these systems target owners and resources, the Identity Management process becomes critical in defining ownership and ensuring accurate resource mapping. The unanswered question of “Who owns what?” remains the linchpin for secure and effective deployment.

Data Leakage Through Public AI Tools

Another pressing concern is the widespread use of public AI tools like ChatGPT and similar platforms. Users routinely rely on these tools to rephrase emails, debug code, or search for information, much like they previously relied on Google. However, this convenience comes at a cost: corporate data leakage.

Owners inadvertently expose sensitive information when interacting with these public models. The only viable solution is to provide enterprise-grade versions of tools like Claude or ChatGPT, ensuring that users stay within secure environments instead of resorting to public versions.

By addressing these challenges head-on, we can create a safer landscape for AI agents and LLM models while minimizing risks associated with data exposure and improper access control. It’s crucial to act before these risks become unmanageable.

Why Do So Few PMs See the Whole Picture?

The answer lies in the nature of their roles. Product Managers (PMs) are not Solution Architects, Enterprise Architects, or Security Researchers. Their primary focus is on delivering and monetizing specific features or products.

When a PM’s goal is, for instance, to deliver a chatbot, their priorities often revolve around functionality and user engagement rather than security. If security measures are not part of their metrics, the architecture may not receive proper scrutiny from the security team. In such cases, the product is developed and shipped as a minimal viable product (MVP) to justify further investment.

This approach, while expedient, often ignores critical security and architectural considerations, leaving the product vulnerable to potential failures and risks. Ultimately, without a comprehensive view, such products are unwittingly set up for disaster.

Do You Have a Remedy?

Yes, I do. Start by focusing on Identity Management, integrating HR feeds, and establishing robust Joiner, Mover, and Leaver (JML) processes.

As for the full answer? Well, that comes at a price – because, why not? ??

Previous: Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Next: Part 14: Future Trends in Identity Management for 2025-2030