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
Cheat sheet & pop quiz
This track was about identity for people who choose you. Here is the whole track on one page. Then five questions check that it stuck.
Nine ideas to remember
| # | If you remember nothing else… |
|---|---|
| 1 | Signup is a funnel, not a form. Every extra field loses customers. Ask for the minimum, verify the contact you will use (email or phone), and screen out bots and fakes. |
| 2 | Recovery is a second front door. Make it at least as strong as login. A passkey account "recovered" by an SMS code gives attackers a way around it. |
| 3 | One human, one account. Link a social login only on a verified email plus a fresh re-login. Otherwise you built an account-takeover feature. |
| 4 | Ask for less, over time. Progressive profiling collects data when it is needed. Granular, opt-in consent (never pre-ticked) keeps you lawful and trusted. |
| 5 | Assume the password is already stolen. Use layers: breached-password checks, risk-based MFA and passkeys. |
| 6 | Migrate without a reset storm. Use bulk import and lazy (just-in-time) migration. Check each old password at first login. Nobody is forced to reset. |
| 7 | A B2B customer is an organization. Model org tenants with org-scoped roles, invitations, per-org SSO and policy, and delegated admin. |
| 8 | A phone number is a loan. Numbers get reissued to strangers. Re-check them, never let one SMS reset an account, and ask a second proof before moving an account to a new number. Let Maya sign out everywhere, and make leaving easy, with a short wait (new number, new phone, leaving). |
| 9 | Identity can live in the customer's wallet. An issuer signs a fact once. The customer shows only the claims you need (selective disclosure). You check the issuer's signature and keep no copy. But wallet loss is the new account-recovery problem (wallets & verifiable credentials). |
The situation and the right call
| The situation… | …the right call |
|---|---|
| A new user's first screen | Ask for the minimum, then profile progressively later. Verify the contact you rely on (signup & verification, progressive profiling) |
| Maya forgot her password | Recovery as strong as login, never weaker. No SMS shortcut around a passkey (account recovery) |
| A social login arrives with the same email as an existing account | Link only after a verified email and a fresh re-login (social login & linking) |
| How much to ask up front | Only what you need now, with granular, opt-in consent (consent) |
| An account is under attack | Layers: breached-password check, risk-based MFA and passkeys (account takeover defense) |
| Moving everyone to a new system | Bulk import plus lazy migration. No reset storm (user migration) |
| Selling to a company, not a person | Org tenants, invitations and delegated admin, with per-org SSO and policy (B2B organizations) |
| A customer changes number, or an old number is reissued | Re-check numbers. Never reset on one SMS alone. Ask a second proof, and tell the old number and the email (account lifecycle) |
| Proving age or identity without collecting a document | Ask for a verifiable credential. Take only the claims you need. Verify the issuer's signature. Then discard (wallets & verifiable credentials) |
Pop quiz — five questions
Q1 · Your signup form asks for name, email, phone, company, job title and "how did you hear about us?". 70% of people quit. Product wants to add a date-of-birth field. What do you do?
Shorten the form, do not grow it. Ask only what you need to create the account: an email and a way to sign in. Verify the email. Collect the rest later with progressive profiling, when each field is used. Extra fields lose customers. They are also data you must protect for no gain (signup & verification, progressive profiling).
Q2 · Maya protected her account with a passkey and has no password. She loses her phone and taps "recover account". The flow emails her a code and then texts her a six-digit code. What is wrong?
Recovery became a downgrade attack. The account's real strength is a passkey that phishing cannot beat. But anyone with a stolen SMS code, or a SIM swap, can skip it. Recovery is now weaker than login. Fix it: recovery must be at least as strong as the main method. Use a backup passkey or security key, a recovery code saved at enrollment, or a careful identity check. Never use an SMS shortcut (account recovery).
Q3 · Maya has an account. An attacker uses a throwaway social account that lists maya@example.com as an unverified address. The attacker taps "Sign in with a social account". Your system sees a matching email and links him straight into Maya's account. What went wrong?
You linked on an unverified email. That is an account-takeover feature, not a convenience. Linking needs a verified email from the provider and a fresh re-login to the existing account. Otherwise anyone who can claim your email at any provider gets your account. A matching email is a hint, never proof (social login & account linking).
Q4 · Marketing ships a signup page with a pre-ticked box: "Yes, send me partner offers and share my data". They say users can always untick it. Setting legal worries aside, why is this the wrong default?
Consent must be a freely given, opt-in choice. A pre-ticked box is assumed consent, not consent. Many privacy laws reject it, and it hurts trust. Make each purpose a separate, unticked option that the user switches on. Record what they agreed to and when. Make withdrawing as easy as giving. Data you collected under a false default is a liability, not an asset (progressive profiling & consent).
Q5 · You are moving two million users to a new identity system. The plan: import the profiles, then email everyone a "set a new password" link on cutover day. Why will this hurt, and what is the better plan?
A forced reset storm cuts conversion, because most people ignore the email and never return. It also buries support in tickets. And a flood of "reset your password" emails looks just like phishing. Better: bulk-import the accounts and use lazy (just-in-time) migration. Check each user's old password against the old store at their first login, then upgrade it quietly. Prompt only the small group who cannot move automatically (user migration).
That is the whole Customer Identity track. You can now onboard customers without friction and recover them without a downgrade. You can link accounts without a takeover and profile people with consent. You can defend against a stolen password, migrate without a reset storm, and grow from one person to whole organizations. Next up is Cloud & Workload Identity: the same care, now for machines. Start at identity for machines in the cloud.
Put it to the test. Browse our free security micro-tools at the tools shelf, or explore our services. Talk to our team when you are ready to design the real thing.