IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Bot detection & CAPTCHA
Credential stuffing means bots try millions of leaked passwords on your login. It is cheap for attackers. Bot detection makes it costly for them. Your goal: know when a CAPTCHA can be shown and what to do when it cannot. (The attack itself is in credential stuffing, password spraying and bots.)
- Bot detection looks for signs of automation, then asks for a test.
- A CAPTCHA needs a screen that the identity provider controls.
- An API token call has no screen. It returns
requires_verification. - Then the app must send the user to the hosted login page.
Making automation expensive
Bot detection watches sign-in and sign-up traffic for signs of automation. It looks for bursts of tries, headless browsers and IP addresses with a bad record. A headless browser is a browser with no window that a script controls.
If a request looks like a robot, the system asks for a test. A person can pass it. A script cannot. That test is a CAPTCHA.
Add breached-password checks and limits on repeated tries (brute-force throttling). Together they remove most of the fuel from credential stuffing.
A thief steals a bunch of keys from another society. The thief tries every key on every flat door, 300 doors a minute. A real resident tries one door, once. The watchman sees the pattern and stops the thief. Bot detection is that watchman.
Where a CAPTCHA can be solved
A CAPTCHA must be drawn on a screen. Say your app signs in with a password grant. This is a call from its backend to the token endpoint. The identity provider controls no screen there. So the token call returns requires_verification instead. The app must send the user to the hosted login page. There the CAPTCHA is drawn, solved and checked.
| Login flow | Can it show a CAPTCHA? |
|---|---|
| Hosted login page | Yes. It does this by itself. This is the best path. |
| Password grant (API call) | No. It returns requires_verification. Send the user to the hosted page. |
| Embedded passwordless | Yes. It is the one embedded sign-in that can show a CAPTCHA on the page. |
Zara, on the security team, sees many requires_verification replies as a stuffing wave hits. No bot gets in. Each risky try goes to the hosted page. The bots have no browser to solve the puzzle, so they stall. People pass.
Go deeper: vendor names
The name requires_verification comes from one vendor. Other providers word it differently. Passing the problem to the hosted page is one more reason to avoid embedded password grants.
🧪 Interactive lab — enable JavaScript to play with this one.
Hardening a login against credential stuffing? Talk to our team.