Stats
Actions
Tags
From qa-auth-flows
Authors tests against Okta - uses org-isolation strategy (per-PR org via Okta Developer Edition vs shared org with namespaced data); tests sign-in policy + MFA enforcement; exercises Okta Identity Engine (OIE) workflows including factor enrollment, recovery flows, and SCIM provisioning; tests scoped API tokens for least-privilege automation. Use when the user works with Okta as IdP and needs unit / integration tests for org config, sign-in policies, or OIE workflows.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qa-auth-flows:okta-testsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The current Okta platform (Okta Identity Engine, OIE) replaces
The current Okta platform (Okta Identity Engine, OIE) replaces the older Okta Classic engine; tests target OIE for new orgs.
Tests against an Okta org fall into four layers:
| Pattern | Pros | Cons |
|---|---|---|
| Per-PR Okta Developer Edition org (free tier) | Isolated; safe destructive tests | Spin-up time + manual approval to create new orgs |
Shared dev org + namespaced fixtures (pr-123-* user prefixes) | Cheap; no spin-up | Cleanup discipline required |
| Mocked OIDC server | No Okta dep; fast | Misses Okta-specific behavior |
For new flows, prefer per-PR org; for app-side flow tests on a stable Okta config, mocked OIDC is fine (cross-ref Auth0 Step 7).
Manage org config as code:
okta/okta) for declarative
config-as-codeokta) for ad-hoc operationsTest config drift by re-running terraform plan against the live
org and asserting no drift:
terraform init
terraform plan -detailed-exitcode # exit 2 if drift; 0 if no drift
Source: registry.terraform.io/providers/okta/okta and developer.okta.com/docs.
Okta's token endpoint:
https://{your-org-domain}/oauth2/{authorization-server-id}/v1/token
The default authorization server is oauth2/default; custom auth
servers are common in B2B for tenant-specific scopes.
import requests
def test_client_credentials_grant(okta_domain, auth_server_id, client_id, client_secret):
response = requests.post(
f"https://{okta_domain}/oauth2/{auth_server_id}/v1/token",
auth=(client_id, client_secret),
data={"grant_type": "client_credentials", "scope": "api:read"},
)
assert response.status_code == 200
body = response.json()
assert "access_token" in body
assert "expires_in" in body
Source: developer.okta.com/docs/reference/api/oidc/.
Sign-in policies in Okta enforce per-app MFA, IP restrictions, and device trust. The policy itself is org-config (Step 2); tests verify enforcement at runtime:
def test_signin_policy_requires_mfa_for_admin_app(okta_session_for_admin_user):
# Initiate auth code flow
response = okta_session_for_admin_user.get(
f"https://{okta_domain}/oauth2/{auth_server_id}/v1/authorize",
params={
"client_id": admin_client_id,
"response_type": "code",
"redirect_uri": redirect_uri,
"scope": "openid profile",
"state": "test",
},
)
# Should redirect to MFA enrollment / challenge per sign-in policy:
assert response.status_code == 302
assert "mfa" in response.headers["Location"].lower()
(Exact verification depends on the policy + factor setup; consult developer.okta.com/docs.)
Okta Identity Engine has a well-defined factor enrollment flow.
Test pattern: drive the flow via Playwright (Universal-Login style)
or via the OIE REST API directly. The Okta Auth JS SDK
(@okta/okta-auth-js) ships idiomatic helpers for OIE flows;
unit-test against the SDK's mock mode.
Source: developer.okta.com/docs/guides/authentication-flows/.
For B2B SaaS that integrates with customer Okta orgs via SCIM:
def test_scim_user_provisioning_creates_user_in_app(scim_test_client):
response = scim_test_client.post(
"/scim/v2/Users",
json={
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "[email protected]",
"name": {"givenName": "Alice", "familyName": "Smith"},
"emails": [{"value": "[email protected]", "primary": True}],
"active": True,
},
headers={"Authorization": "Bearer scim-token"},
)
assert response.status_code == 201
body = response.json()
assert "id" in body
assert body["userName"] == "[email protected]"
For SCIM compliance verification, Okta provides a SCIM tester at developer.okta.com/standards/SCIM/.
For tests that call Okta admin APIs, use scoped tokens (limited to specific scopes via OAuth 2.0 client credentials), not super-admin SSWS tokens:
def test_with_scoped_token():
# Pre-test: get a scoped token via client_credentials with limited scopes
token = get_admin_token(scopes=["okta.users.read"])
# Now use this token for the test - it can read users but NOT modify
...
Source: developer.okta.com/docs/guides/implement-oauth-for-okta/.
- run: terraform init
- run: terraform plan -detailed-exitcode # config drift check
- run: pytest tests/integration/okta/ -v
For per-PR org provisioning, automation requires Okta partner-tier access; most teams use shared dev orgs (Step 1).
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Use SSWS super-admin tokens in tests | Token leak compromises entire org | Scoped client-credentials tokens (Step 7) |
| Skip config-drift check | Manual dashboard changes never reach prod | Terraform plan in CI (Step 8) |
Hardcode authorization-server ID default | Most B2B uses custom auth servers per tenant | Pass via env var |
| Test with Okta Classic engine patterns on OIE org | Classic API ≠ OIE API; tests fail | Verify org engine type before authoring tests |
| Use shared user accounts across tests | Test interference (e.g., failed-login lockout) | Per-test user namespace |
keycloak-tests,
auth0-tests - sister IdP toolsoauth-flow-test-author,
session-management-test-author - build-an-X authorsnpx claudepluginhub testland/qa --plugin qa-auth-flowsProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.