hCaptcha for Okta Identity and Enterprise Access

How does hCaptcha integrate with Okta?#

hCaptcha and Okta connect in two distinct ways. Okta Identity Engine's hCaptcha integration can protect supported end-user sign-up, password-reset, and sign-on flows. Separately, hCaptcha Enterprise can use Okta as a SAML identity provider for authorized administrators who manage hCaptcha organizations and zones.

The first path protects an Okta user journey. The second controls workforce access to the hCaptcha Enterprise dashboard. They use different configuration, credentials, and acceptance tests. This guide covers both and keeps their scope separate.

Protect Okta user flows with hCaptcha#

Okta documents hCaptcha as a CAPTCHA service under Security > General. The administrator supplies a sitekey and secret, then selects the supported pages where Okta should invoke the service.

The current Okta Identity Engine documentation lists:

• Sign Up: verification during registration and initial sign-in.
• Password Reset: verification during password recovery, subject to the flow limitation below.
• Sign On: verification during sign-in.

Okta describes its supported CAPTCHA implementations as invisible and says they run background risk analysis. Confirm the actual hCaptcha mode, challenge behavior, and account capabilities for the target Okta tenant with hCaptcha before rollout.

Prepare the Okta configuration

1. Identify the Okta org, engine, custom domains, Sign-In Widget hosting model, and exact flows to protect.
2. Contact hCaptcha to scope the deployment and obtain the appropriate credentials.
3. Create a sitekey whose allowed hostnames include every custom sign-in domain.
4. If the flow uses the Okta-hosted Sign-In Widget, follow Okta's instruction to add okta.com to the hCaptcha service-domain list.
5. Create and secure an Okta API token before activation. Okta requires it for the documented recovery request if a configuration error blocks access.
6. Assign separate administrators for the change and recovery procedure so one invalid key cannot strand the only operator.

The sitekey is public. Restrict the secret and Okta API token to their supported administrative stores and never place either in browser code, screenshots, logs, tickets, or source control.

Configure hCaptcha in Okta

Follow the current Okta CAPTCHA integration instructions:

1. In the Okta Admin Console, go to Security > General.
2. Find CAPTCHA Integration.
3. Select hCaptcha as the service type.
4. Enter the sitekey and secret for this Okta environment.
5. Under Enable CAPTCHA for, select the reviewed Sign Up, Password Reset, and Sign On flows.
6. Save the configuration.

Okta says CAPTCHA is not supported for password reset in identifier-first flows where the password appears on a second page. Its documented workaround changes the authentication flow and constrains identity-provider and global-session-policy settings. Treat that as an identity-architecture change and have the Okta owner review it before modifying production.

Preserve the recovery path

Okta warns that an incorrect sitekey can lock users out of the org. Its documentation provides an authenticated API request that clears captchaId and enabledPages. Store the current Okta recovery instructions in the change record, verify that the recovery token and administrator path work before activation, and rotate any temporary API token according to policy.

Use Okta SSO for hCaptcha Enterprise administration#

The hCaptcha listing in the Okta Integration Network describes SAML SSO and group-based access for hCaptcha Enterprise administrators. Our current Enterprise API documentation also confirms SAML integration with identity providers such as Okta and role-based permission levels.

The public OIN listing presents a broad functionality matrix but does not provide current customer-specific SAML endpoints, attributes, group mappings, provisioning behavior, or break-glass steps. Obtain those settings from our team during onboarding. Do not copy values from another organization or infer SCIM support from the generic catalog matrix.

Plan the SSO rollout around:

• hCaptcha organizations, zones, sub-organizations, and environment boundaries.
• Okta groups and the least-privilege roles each group should receive.
• assignment, change, deactivation, and access-review workflows.
• SAML signing, certificate rotation, session lifetime, and audit requirements.
• tested break-glass access that does not depend on the same identity-provider path.

Validate both Okta integration surfaces#

For user-flow protection, test each enabled page with valid, missing, expired, and reused responses. Test custom and Okta-hosted domains, identifier-first behavior, supported browsers, accessibility, failure responses, slow networks, and the documented recovery API.

For Enterprise SSO, test assigned and unassigned users, each mapped role, deactivated users, group changes, assertion validation, certificate rollover, audit events, and break-glass access. Record the Okta configuration, hCaptcha settings, test date, approvers, and rollback owner for each surface separately.

Frequently asked questions#

Can Okta use hCaptcha on sign-in pages?

Yes. Okta Identity Engine documents hCaptcha for Sign Up, Password Reset, and Sign On in its CAPTCHA Integration settings.

Does hCaptcha work on identifier-first password reset?

Okta says CAPTCHA is not supported when password reset uses an identifier-first flow with the password on a second page. Review Okta's documented flow constraints before changing that architecture.

Can a bad sitekey lock users out of Okta?

Yes. Okta warns that an incorrect sitekey can block org access and documents an authenticated API request to clear the CAPTCHA configuration. Test that recovery path before activation.

Is the Okta OIN app the same as protecting an Okta login?

No. The OIN app governs Okta-based access to hCaptcha Enterprise administration. Okta's CAPTCHA Integration protects supported Okta end-user flows.

Does Okta require hCaptcha Enterprise for CAPTCHA protection?

Okta's user-flow documentation requires a sitekey and secret but does not name a plan. This page uses Enterprise onboarding so the identity architecture, modes, recovery, SSO, and policy can be reviewed together.