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
Signup & verification
Maya wants to try your app. The signup form is the first thing she sees, and the easiest place to lose her. Your goal: build a short signup that you can still trust.
- Ask for the least you can, as late as you can.
- Check the email or phone. An unchecked one is almost useless.
- A code works across devices. A link opens where the inbox is.
- Keep fake and bot signups out with checks, not puzzles on everyone.
A good signup is short
Ask for the least you can, as late as you can. This habit is called progressive profiling. Collect only what you need today. Usually that is an email and a password, or a passkey. Ask for more later, after Maya likes your app. Lesson Progressive profiling & consent goes deeper.
Picture Maya on a food delivery app. She is hungry and the signal is slow. Each extra box is one more reason to close the app and open another.
Every extra field is friction, and friction costs customers. But a contact detail that nobody checked is almost useless. So be able to trust the little you collect.
a cinema entrance. The guard checks one thing well: your ticket. It is fast, and a photocopy does not get in.
Why we check an email or phone
Verification means proving that the contact detail Maya typed really belongs to her and works. There are three reasons.
- Deliverability. If Maya types maya@gmial.com, every receipt, alert and reset is lost without a sound.
- Ownership. Only the true inbox gets the challenge. So nobody can sign up as someone else.
- Reachability. If something goes wrong later, a checked channel is how you reach the real person.
Link or code?
There are two classic ways to confirm a channel. A verification link is a one-time web address in an email. Maya clicks it. A one-time code is a short number. Maya reads it and types it back. Both prove control.
| Verification link | One-time code (OTP) | |
|---|---|---|
| Using two devices | Awkward: it opens on the device that has the inbox | Easy: read it on the phone, type it anywhere |
| Watch out for | Mail scanners that click links early. Make links single-use and short-lived. | A caller who talks Maya into reading the code aloud |
A polite signup often uses double opt-in. The account exists, but it waits until Maya confirms the channel. Only a confirmed channel gets marketing or sensitive mail. It protects Maya from unwanted lists. It also keeps your mail reputation clean.
Fake signups
Not every new "customer" is real. Some use a disposable email: a throwaway inbox that disappears after ten minutes. They want a free trial or a coupon, and then they vanish. Verification stops many of them, because the inbox is gone before they confirm. You can also flag known disposable domains.
Other signups are scripts that create accounts by the thousand. Defend against them with invisible bot detection and rate limits. Use a CAPTCHA only when the risk rises. See Bot detection & CAPTCHA.
A cheap, unchecked account helps an attacker. A heavy form sends good customers away. Get the balance right, and login, recovery and notifications all stand on solid ground.
Go deeper: Passwords at signup (NIST SP 800-63B-4)
NIST SP 800-63B-4 (final, 2025) sets simple rules for passwords. A password used alone must be at least 15 characters long. A password used only inside multi-factor login must be at least 8. Services should allow at least 64 characters. They must not force mixed character types or other composition rules. They must check new passwords against a password blocklist of common and leaked values. They must not prompt users to use security questions when they choose a password. Source: pages.nist.gov/800-63-4/sp800-63b/.
Go deeper: Bot checks without puzzles
A puzzle on every signup annoys real people, and bots can pass many puzzles anyway. Many services now use invisible checks that run in the browser and score the visit. They ask for no puzzle. Another idea is Privacy Pass (RFC 9576, June 2024, an informational RFC). A client proves once that it passed a check. It gets tokens that the service cannot link back to the person. The service learns "probably not a bot" and nothing else. OWASP says to layer controls, because any one of them can fail. It also warns that blocking by IP address alone is weak, because attackers spread their traffic across many addresses.
Go deeper: Checking who a customer really is
Most apps only need to know that Maya controls an email address. Some need more, such as banks, lenders and age-limited services. They use identity proofing, also called IDV or eKYC. Maya shows an ID document, takes a selfie and passes a liveness check. NIST SP 800-63A defines levels of confidence for this, called IAL1 to IAL3. This costs money and friction, so do it only when the law or the risk requires it. Later, Wallets & verifiable credentials shows how to reuse such a check.
🧪 Interactive lab — enable JavaScript to play with this one.
After signup, Maya gets a session. Check that its cookies are hardened with Cookie Check. If you issue an ID token at signup, lint its claims with ID Token Check.