BeyondTrust - Secure Remote Access and Privileged Access Management

Overview: How Token Inline Hooks and Custom Authorization Servers Can Be Used to Manipulate Trusted Identity Claims

In OAuth 2.0 and OpenID Connect (OIDC) environments, applications and APIs rely on tokens issued by an Identity Provider (IdP) to make authentication and authorization decisions. Once validated, the contents of those tokens dictate a user's identity, privileges, scopes, and access rights within the target application or service.

In Okta, Custom Authorization Servers and Token Inline Hooks provide administrators with the ability to influence how OAuth and OIDC tokens are constructed before they are cryptographically signed and delivered to applications and APIs. While intended to support legitimate identity customization and authorization workflows, these capabilities operate directly within the token issuance trust boundary.

If an attacker gains control of these token issuance workflows, they can influence claims, scopes, group memberships, roles, and other authorization-relevant attributes before the token is signed. Since downstream applications validate the token’s signature rather than how its contents were constructed, these modified claims are treated as legitimate identity data. As a result, attackers can manipulate the identity and authorization context trusted by downstream applications without compromising those applications directly.

In environments where a centralized IdP issues tokens consumed across multiple applications, APIs, and cloud services, this represents a cross-platform security risk with potentially broad impact.

This blog explores:

  1. What is OAuth?

  2. What is OIDC?

  3. How Tokens Become Trusted Authorization Decisions

  4. Where Okta Constructs Tokens

  5. Abuse Examples involving trusted OAuth and OIDC tokens

  6. Attack Limitations

  7. Detection opportunities for defenders

What is OAuth?

OAuth is an authorization framework that allows applications and APIs to grant access to protected resources using tokens issued by a trusted authorization server. In OAuth environments, applications and APIs do not independently verify a user's identity or determine what access should be granted. Instead, they trust tokens issued by an authorization server.

Before examining how Okta token issuance workflows can be abused, it is important to understand the trust relationship that makes those attacks possible.

In many enterprise environments, Okta serves as that authorization server. If a token is validly signed by a trusted issuer, the receiving application accepts the claims and scopes inside that token as authoritative.

At a high level, OAuth involves three important parties for this blog:

  • Client - The application requesting access

  • Authorization Server - The service that authenticates the requestor and issues tokens (Okta in this architecture)

  • Resource Server - The API or application that validates tokens and enforces access

Whether an application is acting on behalf of a user or authenticating directly as itself, the trust model remains the same. Okta constructs and signs a token, and the downstream application or API trusts what that token says.

Okta pt 2 Figure 1
Figure 1: User-initiated flow
Okta pt 2 figure 2
Figure 2: System-to-system flow

The resource server does not determine how the token was constructed. It validates the token's signature and issuer, confirms that Okta issued it, and then uses the token contents to make authorization decisions. That trust boundary is the foundation for the abuse scenarios discussed later in this blog.

What is OIDC?

OAuth provides authorization. OpenID Connect (OIDC) extends OAuth by adding an identity layer.

When a client requests the OpenID scope, Okta can return an ID token in addition to an access token. The ID token tells the client who the authenticated user is, and the access token tells the resource server what actions should be permitted.

Although they serve different purposes, both tokens are trusted for the same reason: they were issued and signed by Okta.

In this architecture, Okta acts as both the IdP and the authorization server. It authenticates the requestor, constructs the tokens, and signs them before they are consumed by downstream systems.

How Tokens Become Trusted Authorization Decisions

The next question is how Okta determines what appears inside a token.

Tokens contain claims and scopes. Claims describe the subject and context of the request, such as a user identity, group membership, role, application identifier, or other attributes. Scopes define what access has been granted.

Resource servers frequently rely on these values when making authorization decisions. They do not determine how those values were derived. They assume the authorization server correctly enforced the policy before issuing the token.

For example, an API may grant administrative access based on a role claim, or allow access to a privileged endpoint because a specific scope is present. If those values appear in a valid token, the resource server trusts them.

Okta pt 2 figure 3
Figure 3: Sample command that lists the scopes

In typical Okta deployments, ID and access tokens are JSON Web Tokens (JWT).

A JWT contains:

  • A header describing the token type and signing algorithm

  • A payload containing scopes and claims

  • A signature proving the token was issued by Okta

Okta pt 2 Figure 4
Figure 4: JWT Token broken down

The payload contains the identity and authorization information that downstream systems rely on. The signature is what establishes trust. Once a token's signature is validated, the receiving application treats the contents of that payload as authoritative.

Where Okta Constructs Tokens

The trust boundary becomes particularly important when examining how Okta constructs tokens.

Okta provides two types of authorization servers:

  • The org authorization server - protects the Okta tenant and management APIs

  • The custom authorization server - protects external applications and APIs

For this research, the custom authorization server is the relevant control point.

Administrators can use a custom authorization server to:

  • Define access policies

  • Create custom scopes

  • Create custom claims

  • Control which clients may request specific scopes

  • Attach inline token hooks that modify tokens before signing

Okta pt 2 Figure 5
Figure 5: ID vs Access tokens
Okta pt 2 Figure 6
Figure 6: Custom vs Org Auth Server

The authorization logic relevant to these attacks is centralized here. The custom authorization server decides what claims and scopes will be included before the token is cryptographically signed and delivered to downstream systems.

This research assumes an attacker has already obtained administrative control over these authorization-server workflows. Under that condition, the attacker does not need to bypass JWT signature validation or compromise the resource server. Instead, they can influence how trusted tokens are constructed inside Okta before those tokens are issued.

The following attack vectors demonstrate two ways this trust boundary can be abused:

  1. Modifying claims and scopes directly within a custom authorization server

  2. Using a Token Inline Hook to alter token contents before Okta signs the token

Abuse Examples Involving Trusted OAuth and OIDC Tokens

Example 1: Manipulating Hasura Authorization with a Token Inline Hook

Hasura GraphQL enforces row-level access control by validating an Okta-issued access token and evaluating claims within the hasura_claims namespace.

The objective: obtain administrative access to data using a client that Hasura should not treat as an administrator

Setup

Hasura is configured to trust the Hasura custom authorization server and loaded with sample data.

Okta pt 2 figure 7
Figure 7: Configure Hasura GraphQL to trust the hasura custom authorization server
Okta pt 2 figure 8
Figure 8: Sample data for testing

Finally, row-level permissions are configured to evaluate the X-Hasura-User-Id claim within the hasura_claims namespace.

Okta pt 2 Figure 9
Figure 9: Hasura row-level permissions using X-Hasura-User-Id

At this point, Hasura’s authorization model is functioning as intended, making access decisions based solely on claims contained within a valid Okta-issued access token. To validate this behavior, we request an access token for a standard user and present it to Hasura, which correctly returns only user-authorized data and provides no visibility into administrator-level information.

Okta pt 2 Figure 10
Figure 10: Hasura correctly checks access token privileges

Token Manipulation

Rather than attacking Hasura directly, the attack targets Okta’s token inline hook. A hook is created that injects administrative Hasura claims into an access token before Okta signs it.

Okta pt 2 Figure 11
Figure 11: Token Inline Hook injecting administrative Hasura claims

The custom authorization server is then configured to invoke the token inline hook.

Okta pt 2 figure 12
Figure 12: Custom authorization server configuration

Note that none of these changes touch Hasura. Its permission model and authorization logic remain unchanged.

Result

An access token is requested from the custom authorization server. Note this is a client_credentials token: it represents a machine and contains no authenticated user.

Okta pt 2 figure 13
Figure 13: Requesting an access token

Inspecting the resulting token shows the injected Hasura administrative claims.

Okta pt 2 figure 14
Figure 14: Access token containing administrative claims

The token is presented to Hasura and it returns all records, including data that should only be available to an administrator.

Okta pt 2 figure 15
Figure 15: Hasura returning administrative records

Hasura did nothing wrong; it validated a genuine, signed token and enforced its rules against the contents. A compromised IdP is not just an authentication problem but also a downstream authorization one.

This example used a token inline hook to modify claims before signing. However, the same trust boundary can be influenced directly within the authorization server itself.

Example 2: Claim Manipulation in a Custom OIDC Application

The Hasura example showed how a token inline hook can modify an access token before signing. This example shows the other angle: modifying an ID token directly inside the custom authorization server.

To demonstrate this, a simple OIDC application is configured to authenticate through Okta and display the ID token it receives after login.

Okta pt 2 figure 16
Figure 16: TokenViewer application code snippet

A custom claim is added to the authorization server so that Okta inserts a permission value into the token during construction.

Okta pt 2 figure 17
Figure 17: Custom claim added in the authorization server

After authentication, the application receives a validly signed ID token containing the injected permission claim.

Okta pt 2 figure 18
Figure 18: ID Token containing the injected permission claim

Many applications rely on application-specific claims embedded in ID tokens to drive identity and authorization decisions. If an attacker understands which claims are trusted and can influence token construction within Okta, they can insert those claims into a token that appears completely legitimate to the application.

Attack Limitations

Okta does enforce meaningful constraints on token modification.

Registered claims such as sub, iss, and aud cannot be modified in an ID token, neither through a token inline hook nor directly within the custom authorization server. Okta enforces this restriction to maintain compliance with the OpenID Connect specification and preserve the integrity of identity tokens.

Okta pt 2 figure 19
Figure 19: Error returned when attempting to modify registered ID token claims

In contrast, access tokens are different. Because OAuth allows the authorization server to define the structure and contents of an access token, the same registered claims can be modified before the token is signed.

Okta pt 2 figure 20
Figure 20: Successfully modified sub claim in an access token

This distinction defines where the attack can be applied most effectively. While registered ID token claims are protected, many applications and APIs make authorization decisions based on access-token claims. If those claims are modified inside Okta before signing, downstream systems will continue to trust the resulting token because the signature remains valid.

Detection opportunities for defenders

Detection 1: Identify Applications that Trust Custom Identity or Authorization Claims

Review client applications and APIs for the following patterns:

  • Identity decisions based on custom claims in ID tokens

  • Authorization decisions based on claims or scopes in access tokens

  • Relying on non-standard claims, custom roles, group memberships or permission attributes

Applications that make security decisions based solely on token contents inherit the trust assumptions of the IdP. In the Hasura example, a client_credentials access token containing injected identity claims was sufficient to influence authorization decisions.

Understanding which claims are trusted and where they are consumed can help identify applications that may be susceptible to token manipulation attacks.

Okta sources:

Detection 2: Monitor Changes to Token Issuance Workflows

Monitor administrative changes affecting:

  • New token inline hooks

  • New custom claims and scopes

  • Changes to the authorization server and access policies

These settings directly influence the contents of tokens before they are signed and delivered to downstream applications. Because these modifications occur within the identity trust boundary, unexpected changes should be reviewed and correlated with approved administrative activity.

As a broader trust-boundary monitoring strategy, defenders should also monitor events such as app.oauth2.trusted_server.add and app.oauth2.trusted_server.delete, which indicate changes to authorization-server trust relationships. For threat hunting, app.oauth2.as.token.grant.access_token and app.oauth2.as.token.grant.id_token can provide visibility into token issuance activity, although their volume generally makes them more useful for hunting than alerting.

Okta pt 2 figure 21
Figure 21: Example of a token inline hook configuration

Conclusion

Identity Providers sit at the center of modern enterprise trust relationships, making them one of the most high-value targets for attackers. Whether through SAML assertions, OAuth access tokens, or OIDC ID tokens, the common theme is the same: downstream systems trust what the IdP signs. As organizations continue to centralize authentication and authorization within their identity platforms, understanding where trust is created, modified, and enforced will be critical to securing the modern enterprise.

For further reading on Okta exploits, check out the first blog in the Hooked on Identity series, Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta

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.

Explore the latest Phantom Labs researchCircle Arrow Right