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
Adaptive risk-based MFA
Asking for a second factor on every login annoys everyone and adds little safety. Adaptive MFA gives each sign-in a risk score. It asks for a challenge only when something looks strange. Your goal: explain how a risk score decides, and what an API app must do.
- The engine reads signals: device, place, IP address, time.
- Low confidence means a challenge. High confidence passes quietly.
- A hosted login page shows the challenge for you.
- An API app gets
mfa_requiredand must run the challenge itself.
Score the risk, then decide
The engine reads signals about each sign-in. A new device or browser is one. A jump to a far-away place is another (impossible travel). An IP address with a bad record also counts. So does an odd time of day.
From these signals it builds a confidence score. Low confidence means "this does not look like Maya". The engine asks for a challenge. High confidence lets a normal sign-in pass quietly.
🌍 New place
A login from a country Maya has never used, minutes after one at home. She could not travel that fast.
💻 New device
A browser or device that was never used with this account before.
🚩 IP address with a bad record
Traffic from an address linked to abuse, botnets or tools that hide who is connecting.
Your bank watches how you spend. A small buy in your own town goes through quietly. Then the card is used in another country ten minutes later. You get an SMS: "Was this you?" Adaptive MFA does the same for sign-ins.
A browser hides this. An API login must handle it.
A hosted login page is a page run by the identity provider. With it, adaptive MFA is invisible. The page shows the challenge when the risk is high. It finishes the login for you.
An app can also sign in over an API back channel. Then there is no page. The token call returns 403 mfa_required and a short-lived mfa_token. The app must run the challenge itself. The mfa_token only allows that challenge. It is not an access token.
If you switch the policy off, the risk score is still computed. Your post-login hooks can still read it. These hooks are your own code that runs after a login. You keep the signal without challenging everyone.
Also, for back-channel logins, location risk uses the real network address of the sender. That is your own server, not the end user. So every user can look like they are in your server's city.
Go deeper: vendor names
The names mfa_required and mfa_token come from one vendor. Other providers use other codes for the same idea.
🧪 Interactive lab — enable JavaScript to play with this one.
Tuning risk signals and confidence thresholds? Talk to our team.