Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta

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.

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.

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

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 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.

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:

• https://developer.okta.com/docs/guides/validate-access-tokens/
• https://developer.okta.com/docs/guides/validate-id-tokens/

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.