Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
Phantom Labs™ researcher Madhav Nakar breaks down how Okta SAML Assertion Inline Hooks can be abused to enable impersonation, privilege escalation, and access bypass—and how defenders can monitor and detect potential malicious activity.
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.
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.
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.
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.
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:
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.
The figures below walk you through the privilege escalation process:
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:
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.
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.
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.
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.