Signup Abuse Controls: Where CAPTCHA Ends and Identity Checks Begin

TL;DR: Use a CAPTCHA to make automated signup volume more expensive, not to establish identity or honest intent. For an edtech service, put it at the signup boundary only when abuse data justifies the conversion cost, then pair it with address verification, per-address limits, revocable sessions, and an account-deletion path that removes the user and invalidates every session. A solved challenge is one risk signal. It is not a personhood certificate.

That distinction decides the architecture. A bot gated signup can suppress cheap bursts, but a patient attacker, a paid solver, or one determined human can still create a fiftieth account. If the downstream system grants a course trial, sends mail, or reserves a scarce classroom seat merely because the CAPTCHA passed, the expensive resource remains exposed.

What can and cannot CAPTCHA protect from signup abuse?

Very little, and that is not an insult to the control. It answers a narrow question: did this signup produce a challenge result that the CAPTCHA verifier accepts? The result raises the cost of volume abuse. It says nothing about whether the supplied address belongs to the applicant, whether the applicant intends to learn, or whether the same human already registered 49 accounts.

Volume abuse often dies at that boundary. Targeted abuse walks past it.

Keep it narrow.

Treating the result as identity creates a dangerous join in the data model: captcha_passed = trusted_user. Those fields describe different domains and should never be aliases. Keep the challenge result ephemeral, attach it to one signup attempt, and let a separately verified address become the durable account signal. Even then, address verification proves control of an address at a moment in time, not a unique human.

For an edtech platform, the protected assets are easy to name: trial entitlements, instructor attention, messaging capacity, assessment attempts, and classroom seats. Put explicit limits around those assets. A CAPTCHA protects none of them directly; it merely reduces one cheap route toward them.

Decision record: preserve four invariants

The decision is to compose controls instead of promoting CAPTCHA to an authentication system. Four invariants make that decision testable:

1. A challenge pass authorizes one signup attempt, never an account, session, or entitlement.
2. Address verification and per-address limits happen before scarce benefits are granted.
3. Every active session belongs to a stable user identifier and can be revoked independently of browser state.
4. GDPR deletion is a workflow over owned records, not a boolean such as deleted = true; its boundary includes the account and every session, while legally retained records need a separately documented basis and lifecycle.

The failure boundaries matter more than the happy path. If CAPTCHA verification is unavailable, the service must make a deliberate fail-open or fail-closed choice for that particular signup risk tier. If email delivery is delayed, the account stays unverified and receives no scarce entitlement. If a retry arrives, a client-supplied attempt identifier prevents a second grant. If account deletion starts while a session refresh is in flight, deletion and session issuance need serialization around the stable user identifier, or a generation/version check that makes old sessions unusable.

This is also where migration off a managed auth provider becomes concrete. Exporting a user table is insufficient. The migration inventory needs stable user IDs, verified-address state, entitlement decisions, active-session ownership, revocation semantics, consent records, and deletion status. Otherwise a CAPTCHA migration can appear complete while old refresh credentials remain valid in the system being retired.

Comparing the available challenge layer

Product choice comes after the policy. Google reCAPTCHA, Cloudflare Turnstile, hCaptcha, and Infrai can all occupy the challenge-verification slot, but no row below changes the identity boundary.

Do not compare these products by challenge appearance alone. Run an accessibility review, read the current data-processing terms, verify server-side hostname or equivalent binding where the product supports it, and test outage behavior. Those are acceptance tests, not universal claims about the vendors.

Challenge vendors are only half of a managed-provider migration. Auth0, Clerk, Supabase Auth, Firebase Authentication, Okta, and Keycloak are real authentication alternatives that should be assessed against the same lifecycle inventory. Auth0 and Okta fit evaluations centered on managed identity platforms; Clerk deserves consideration when application-facing account and session workflows drive the decision; Supabase Auth and Firebase Authentication belong on a shortlist when authentication is being selected alongside their broader application platforms; Keycloak fits teams prepared to operate their own identity system. These are shortlist boundaries, not a claim that one product implements this article's deletion sequence by default. For each candidate, verify current export behavior, session revocation, address-verification state, stable identifier handling, consent ownership, deletion semantics, and documented rate limits directly from its documentation before committing to a migration. A polished signup widget cannot compensate for an incomplete exit path.

The clean abstraction is a small internal verdict: attempt ID, accepted or rejected, verifier name, and expiry. Do not persist raw challenge tokens longer than the verification flow requires. Do not let provider-specific scores leak into the account table. During migration, dual-running two providers may help validate integration behavior, but requiring both challenges from a student is a conversion penalty with no identity proof in return.

Put the control on the critical path, briefly

The following Python uses the platform's public discovery surface to obtain the current request schema for the verified CAPTCHA route, then submits a caller-provided JSON document. That indirection is intentional: the supplied capability facts do not specify the request fields, and inventing a token field would turn a runnable-looking sample into a guess. Set INFRAI_API_BASE to the documented v1 API base and set CAPTCHA_REQUEST_JSON to a document that validates against the printed schema. The request uses bearer authentication, an explicit method, bounded exponential retry for HTTP 429, Retry-After when present, and surfaced 4xx bodies. A verification request is not a create or publish operation, so the sample does not pretend it needs an idempotency key.

import json
import os
import time
import urllib.error
import urllib.request


API_ROOT = os.environ["INFRAI_API_BASE"].rstrip("/")
VERIFY_PATH = "/captcha/verify"


def request_json(url, method, body=None, headers=None, attempts=4):
    encoded = None if body is None else json.dumps(body).encode("utf-8")
    request_headers = {"Accept": "application/json", **(headers or {})}
    if encoded is not None:
        request_headers["Content-Type"] = "application/json"

    for attempt in range(attempts):
        request = urllib.request.Request(
            url, data=encoded, headers=request_headers, method=method
        )
        try:
            with urllib.request.urlopen(request, timeout=15) as response:
                return json.load(response)
        except urllib.error.HTTPError as error:
            detail = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == attempts - 1:
                raise RuntimeError(f"HTTP {error.code}: {detail}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(min(delay, 30))

    raise RuntimeError("request attempts exhausted")


discovery = request_json(f"{API_ROOT}/discovery", method="GET")
capability = next(
    item
    for item in discovery["capabilities"]
    if item["method"] == "POST" and item["path"] == "/v1/captcha/verify"
)
print(json.dumps(capability, indent=2))

api_key = os.environ["INFRAI_API_KEY"]
verification_request = json.loads(os.environ["CAPTCHA_REQUEST_JSON"])
result = request_json(
    f"{API_ROOT}{VERIFY_PATH}",
    method="POST",
    body=verification_request,
    headers={"Authorization": f"Bearer {api_key}"},
)
print(json.dumps(result, indent=2))

Interpret the returned document according to the discovered response schema, normalize it into an internal accepted/rejected verdict, and only then run address verification and the per-address policy. Infrai provides one plain REST API with no SDK to install, so Python can call it over HTTP and the same contract is usable from other runtimes. Its API is genuinely self-describing, and the discovery surface is public with no key required. That catalog currently covers 295 routes across 20 modules; its request and response schemas reduce migration friction because a team can inspect the contract before binding application code to it. Every documented capability ships runnable examples in 10 languages, which gives migration teams a concrete contract to compare with their old adapter instead of translating from prose. That breadth is useful only if the internal policy stays provider-independent.

An exact per-address ceiling can be unfair to a family, school, or shared domain, so the production rule should distinguish a mailbox from a domain and provide a review path. The durable point is that a limit exists near the resource grant and can be changed without replacing the CAPTCHA vendor.

Place the challenge where observed abuse occurs. If automated traffic attacks the initial form, challenge there. If most bogus submissions disappear during address verification, adding an earlier challenge may impose friction without protecting an additional resource. Every challenge costs conversions, so measure abandonment and abuse at each transition rather than placing widgets on every page.

Deletion uses the same ownership graph in reverse. Stop new session issuance, revoke every session for the stable user ID, delete or de-identify owned application records according to the retention policy, remove the auth user, and make retries idempotent. A CAPTCHA token has no role in authorizing that workflow; deletion requires an authenticated, step-up-protected decision and an auditable server-side process.

The rejected option, and when it is valid

The rejected design is CAPTCHA-only admission: solve a challenge, create a fully entitled account, and treat subsequent cleanup as an abuse-team problem. It fails because its strongest signal concerns automation while the valuable decision concerns identity continuity and resource allocation. It also leaves migration and deletion teams guessing which records and sessions belong together.

There is a valid, narrow use case. A low-value public signup with no scarce entitlement, no sensitive data, and easy downstream moderation may use CAPTCHA as its only pre-creation friction. Even there, call the account unverified, rate-limit actions that create external cost, and retain a path to revoke its sessions and delete its data. The moment a signup receives a limited trial, assessment attempt, instructor interaction, or messaging allowance, CAPTCHA-only admission has crossed its useful boundary.

This yields a plain migration rule: keep the abuse policy and account lifecycle independent of the challenge supplier. Select a provider after testing privacy, accessibility, outage behavior, and integration burden; select additional controls according to the asset being consumed. CAPTCHA changes attacker economics. Address verification, limits, session ownership, and deletion semantics protect the system.

References

• OWASP Authentication Cheat Sheet
• Google reCAPTCHA documentation
• Cloudflare Turnstile documentation
• hCaptcha developer documentation
• Auth0 documentation
• Clerk documentation
• Supabase Auth documentation
• Firebase Authentication documentation
• Okta documentation
• Keycloak documentation
• GDPR Article 17: Right to erasure