How to Abuse SAML Assertion Inline Hooks in Okta | Phantom Labs

Overview: How SAML Assertion Inline Hooks in Okta Can be Used to Manipulate Trusted Identity Claims

In SAML-based federated authentication, Service Providers (SPs) rely on the assertions signed by the Identity Provider (IdP). Once validated, the contents of that assertion dictate the authentication and authorization contexts for the target application.

Okta’s SAML assertion inline hook feature allows administrators to dynamically modify SAML assertions before they are delivered to a Service Provider. While intended for legitimate identity customization, this capability places the hook directly inside the authentication trust boundary.

If an attacker gains access to configure or tamper with a SAML assertion inline hook, they can alter identity attributes, nameID values, or authentication context fields before the assertion is signed. Since the Service Provider validates only the signature, not how the assertion was constructed, these modified claims are indistinguishable from legitimate identity data. This can result in privilege escalation, impersonation, or unauthorized access without compromising the Service Provider itself.

In environments where a centralized IdP federates access across multiple tenants, domains, and SaaS platforms, this represents a cross-platform security risk with potentially broad impact.

This blog explores:

What is an Okta Inline Hook?
Deep dive into how SAML trust relationships work
Capabilities and security implications of a SAML Assertion Inline Hook
Attack path and examples of abuse scenarios across federated applications
Detections and monitoring opportunities in Okta
Security considerations for defending the identity trust boundary

What is an Okta Inline Hook?

Inline hooks allow administrators to introduce external logic at specific stages of identity processing. Okta provides this feature to support advanced identity workflows. At a high level, an inline hook is an outbound HTTP request from Okta to a customer-controlled service, triggered during a defined point in a workflow. The external service can inspect and modify certain data before Okta continues processing.

Specifically, there are five types of inline hooks:

Registration - introduces additional logic during user onboarding
SAML assertion - allows modification of claims within the SAML authentication flow
Token - can modify access or ID tokens before issuance
Passport Import - validates credentials against an external store during initial sign-in
Telephony - integrates external providers into enrollment and recovery workflows

Among these, the SAML assertion and Token inline hooks are distinct in that they operate directly within authentication and authorization flows, controlling identity claims before they are trusted by downstream SPs. In this blog, we focus specifically on the SAML assertion inline hook.

SAML Deep Dive: What is SAML and How Do Its Trust Relationships Work?

SAML (Security Assertion Markup Language) is a protocol used to exchange authentication and authorization data between an IdP and a SP. It forms the foundation of many single sign-on (SSO) implementations across cloud environments.

To understand the security implications of modifying SAML assertions, it is important to understand how trust is established in a SAML authentication flow.

Figure 2: Illustration of a SAML authentication flow

At a high level, the flow for SAML is:

User accesses an application (SP).
SP redirects them to the IdP (includes a SAML Authentication Request in the redirect).
User logs into the IdP.
Okta generates and sends a SAML response to the user’s browser.
User’s browser forwards the SAML response to the SP.
SP validates and grants the user access to the app.

Although the SAML response travels through the user’s browser, its integrity is protected since it is digitally signed by the IdP. The SP validates this signature and, if it is valid, trusts the contents of the assertion.

What Is a SAML Assertion?

A SAML assertion is the XML payload within a SAML response that contains the identity and authorization data consumed by the Service Provider. Once the assertion is signed and validated, its contents determine who the user is and what access they receive.

An assertion can contain multiple statement types, including:

Authentication Statements - indicate that the user successfully authenticated with the IdP; these include fields such as AuthnContextClassRef, describing how the user authenticated.
Attribute Statements - carry identity attributes, such as username, email, group membership, and role information.
Authorization Decision Statements - indicate whether a user is permitted to perform a specific action (rarely used in modern SAML deployments).

From a security perspective, the Authentication and Attribute statements are particularly important. SPs frequently rely on these fields for access control and role mapping decisions.

Figure 3: Example Authentication Statement in a SAML ticket

Figure 4: Example Attribute Statement in a SAML ticket

Capabilities of an Okta SAML Assertion Hook

The SAML assertion inline hook executes after Okta generates the assertion but before it is cryptographically signed and delivered to the SP. During this window, Okta sends the assertion to an external service, which can add new claims, replace existing values, or otherwise modify elements within the authentication and attribute statements.

Figure 5: Inline hook patch response modifying SAML assertion claims.

Because Okta signs the assertion only after the hook returns the modified payload, the external service effectively has pre-signature control over the identity claims that the SP will trust.

Figure 6: The hook can modify fields under “assertion”

In the updated SAML flow, the only structural change is this additional step: the assertion is temporarily routed to the external service prior to signing. Once returned, Okta signs the modified assertion with its private key and sends it to the SP. The SP validates the signature but cannot determine how the assertion was constructed, meaning any added or replaced claims are trusted.

Attack Path and Examples

Requirements:

This attack requires Super Administrator privileges in Okta to create or modify an inline hook, and a target application configured for SAML-based single sign-on.

Setup:

Once a SAML assertion inline hook is registered and associated with the target application, Okta routes each generated assertion to an external service before signing it. That service can be a simple web application, such as a lightweight Flask application exposed through a secure tunnel like ngrok, which is designed to receive the assertion payload and return patch commands that modify specific claims.

After the service responds, Okta signs the modified assertion and delivers it to the Service Provider. From that point forward, every authentication attempt to the application passes through this pre signature modification step.

Examples Of Abuse Scenarios Across Federated ApplicationsThe following examples demonstrate several ways a malicious SAML assertion inline hook can be abused against downstream applications:

User Session Hijacking (Jenkins)

Privilege Escalation (Salesforce)

Authentication Context Manipulation (Custom SAML Application)

Example 1: User Session Hijacking

Service Provider: Jenkins

By replacing the /subject/nameId value in the assertion, the inline hook causes Jenkins to associate the authenticated session with a different user account.

The figures below walk you through the user session hijacking process:

Figure 8: Step one: Log into Okta as a low privileged user. In this case, I logged in as [email protected]

Figure 9: Step two: Replace the nameId to a Jenkins administrator. In this case, I used [email protected]

Figure 10: Step three: Authenticate to Jenkins as the administrator

Example 2: Privilege Escalation

Service Provider: Salesforce

In this scenario, a low-privileged user authenticates to Okta and attempts to access Salesforce. Before the assertion is signed, the inline hook replaces the /subject/nameID value with that of a Salesforce system administrator.

When the modified assertion is returned and signed by Okta, Salesforce validates the signature and associates the session with the administrator account referenced in the assertion.

Figure 11: Privilege level of both users

The figures below walk you through the privilege escalation process:

Figure 12: Step one: Log into Okta as the low privileged user (in Salesforce)

Figure 14: Step four: Log into Salesforce as an administrator

Example 3: Other abuse primitives

Service Provider: Custom SAML application

In environments where an SP enforces policy decisions based on specific assertion values, the inline hook can influence more than just user identity. Some applications validate fields, such as AuthnContextClassRef, group membership, or custom attributes, to determine whether access requirements have been satisfied.

In this scenario, the SP requires a specific AuthnContextClassRef value to indicate stronger authentication. Without the inline hook enabled, Okta generates an assertion containing the original authentication context, which does not meet the SP’s policy. As a result, access is denied.

With the inline hook enabled, the /authnStatement/authnContextClassRef field is modified before the assertion is signed. Once signed and delivered, the SP validates the signature and evaluates the updated authentication context. Because it relies on the signed assertion for policy enforcement, access is granted. This is demonstrated in the figures below:

Figure 15: Custom application denies access because of authentication requirements

Figure 16: The inline hook modifies that field

Figure 17: The application allows access

How To Detect SAML Assertion Inline Hook Abuse in Okta

To detect malicious use of SAML Assertion Inline Hooks, defenders need to monitor multiple stages of the attack lifecycle for suspicious activity. These include:

The creation of malicious hooks
When the Hook is attached to the SAML Application
Hook execution
Downstream authentication events that may indicate impersonation or privilege escalation

The following detections identify activity throughout the attack lifecycle.

Detection 1: Monitor Creation of SAML Assertion Inline Hooks

Monitor Okta logs for inline_hook.created events where the inline hook type is com.okta.saml.tokens.transform. Since creating a SAML hook requires elevated privileges and directly impacts the identity trust chain, any creation event should be reviewed and validated against approved administrative activity. The new hook configurations will be available in Inline Hook API.

Detection 2: Monitor Hook Attachment to Applications

Monitor application configuration changes and investigate application.lifecycle.update events affecting SAML applications. A newly attached assertion hook may indicate that authentication assertions are being modified before signing and should be correlated with recent inline hook creation activity.

Figure 19: Example application settings indicating a possible hook

Of these settings, app.settings.singon.ssoacsurl is the most security-relevant because it defines where authenticated SAML assertions are sent, making it useful field for identifying potentially malicious application modifications.

Detection 3: Monitor Hook Execution

Monitor successful inline_hook.response.processed events to identify when SAML assertions are being modified during authentication. Unexpected execution activity, particularly for newly created hooks, should be investigated.

Figure 20: Example inline_hook.response.processed event showing the user executing the hook

Detection 4: Correlate SSO Activity with Hook Execution

Correlate user.authentication.sso and inline_hook.response.processed events using the log.debugContext.debugData.requestId. Differences between the authenticating user and the resulting assertion subject may indicate impersonation, privilege escalation, or other SAML assertion manipulation activity.

Figure 21: Example log showing the hook processing

Figure 22: Example query to identify mismatches between the authenticating user and SAML assertion subject

Conclusion

Identity Providers sit at the center of modern enterprise trust relationships, making them one of the most high-value targets for attackers. SAML Assertion Inline Hooks are just one example of how trusted identity workflows can be leveraged to alter downstream security decisions without directly compromising the applications that consume them. As identity platforms become increasingly complex, understanding where trust is created, modified, and enforced will be critical to defending the modern enterprise.

Explore More Research from Phantom Labs

Phantom Labs™ researchers "think like attackers" to expose privilege escalation paths and identity attack vectors, helping defenders proactively uncover misconfigurations and detect threats in complex hybrid and cloud environments. Using advanced graph modeling, Phantom Labs researchers map attack paths to privileged access across cloud and on-premises infrastructure.

Continue Reading

About the Author

Madhav Nakar

Security Researcher

Madhav is a cybersecurity researcher with a background in mathematics, interested in AI and identity security research, particularly in understanding how these systems can be abused. He enjoys creating social media content around AI, cybersecurity and spirituality.

Phantom Labs™

BeyondTrust

BeyondTrust Phantom Labs™ believes the best way to fully understand cybersecurity threats is to work closely with our customers and partners, conducting real world research into the attacks that matter most to them. By dissecting emerging attack methods and exploitation techniques of threat actors, as well as conducting novel research, the team’s mission is to help organizations defend against identity threats.

Watch Product Demos

Buyer's Guide for Complete PAM

Gartner® Magic Quadrant™ for PAM

See what customer success looks like

Find a Partner

Leader in Privilege-Centric Identity Security