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
Step-up & assurance
Maya is signed in. But before a big payment, the bank wants proof that it is her right now. Step-up asks for fresh, stronger proof just before a risky action. The API must check that the proof came back. Your goal: tie each risky action to a level of proof.
- Being signed in is not the same as proving it is you now.
- The token says how and when the user proved who they are.
- The API is the gate. It checks the token. The client only asks.
- For money, check
auth_time, not when the token was issued.
Judge the proof, not only the person
Every token carries an authentication context. It tells how and when the user proved who they are. Three claims matter.
amrlists the methods used, such asmfa.acrsays how strong the login was.auth_timesays when a person last signed in at the screen.
You tie each risky action to a minimum level of proof.
📊 Read data
Any signed-in session is enough. It is like checking your balance.
📧 Change recovery email
The token must show MFA (amr includes mfa). Any age is fine. A password-only session is refused. It is like changing your registered mobile number: the bank asks for an OTP.
💳 Authorize a ₹25,000 payment
Needs fresh MFA, done by a person in the last few minutes. An old token is refused, even if it says amr=mfa. It is like a new OTP for every big transfer.
The step-up pattern
When the proof is too weak, the API does more than say no. It answers 401 with the error insufficient_user_authentication. The answer names the acr_values that the client must ask for. For money, it can also give max_age. This is the oldest sign-in it accepts.
The app asks the IdP for a stronger sign-in. Then it retries the same call.
In this design, sending acr_values asks only for the second factor on the existing session. prompt=login is different. It forces a new password sign-in. That is the tool for lost-factor recovery, not for step-up.
acr_values only asks for a factor. The real check happens when the API reads a validated token.The API must first validate the token: signature, issuer, audience and expiry. Then it reads amr, acr and auth_time. Judge freshness by auth_time, never by when the token was issued. A token made from a refresh token does not prove that a person is at the screen now.
A bank teller knows you by sight for a balance check. Before a big transfer, the teller asks for a signature from today. Recent proof, matched to the stakes.
Go deeper: the standard
RFC 9470 describes this step-up pattern. It defines the insufficient_user_authentication error and the acr_values and max_age hints in the answer.
🧪 Interactive lab — enable JavaScript to play with this one.
Mapping risky actions to assurance levels? Talk to our team.