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
Building a custom push authenticator
Maya taps "Approve?" on her phone. A lot of work hides behind that tap. Your goal: explain how a push authenticator works and how to make the tap safe.
- The phone keeps a private key. Only the public key goes to the IdP.
- The phone signs approve or deny. No secret travels.
- Number matching stops push fatigue.
- The prompt must show the real details of what you approve.
It is 3 a.m. Priya's phone buzzes: "Approve?" She did not start anything. She is half asleep, and the buzzing will not stop. She taps yes. A stranger who had her password is now inside her work mailbox.
Enrollment
Your app makes an enrollment ticket. It is a one-time link, usually shown as a QR code. It ties the phone to the user. When the phone scans it, the phone makes a key pair on the device. It keeps the private key in the platform keystore. That is secure storage that the phone's operating system guards, often with hardware. The phone sends only the public key to your IdP. One app can hold several enrollments. So Priya can pair the same phone with staging and with production.
Sign, don't share
When your IdP needs an approval, it sends a challenge over your own push channel. That is a notification pipe that you run, not a shared third party's. The phone signs "approve" or "deny" with the private key. That key never leaves the keystore. The IdP checks the signature with the public key it saved. No secret travels. A one-time code is a shared value. It can be phished or replayed. A signature over a new challenge cannot be reused.
Make the tap safe
A plain "Approve?" button has a weakness. An attacker with Priya's password can send prompt after prompt until a tired user taps yes. This is push fatigue. Two defenses help. First, number matching. The login screen shows a number. The person must type it on the phone. An attacker's spam has no number to type. Second, limit how many prompts can be sent.
Show the real details
A blind "Approve this request?" is weak. RAR fixes this. It stands for Rich Authorization Requests. The details of the transaction travel in a field named authorization_details. Now the phone can show exactly what is being approved: "Send ₹50,000 to +91 98… — approve?". The IdP also binds these details into the token it issues. So the API can enforce them. This is the on-device side of human-in-the-loop approvals. If the phone cannot show rich details, the app can fall back to a plain prompt. This is called graceful degradation. The token still enforces the details.
A signet ring pressed into wax. Only your ring makes that exact seal. You never hand the ring over. The private key is the ring. The signature is the seal.
Suppose the phone shows a generic prompt, but the token allows a ₹50,000 transfer. This is consent theater. Whenever the tier supports it, show the real authorization_details. The person must see, on the device, exactly what they approve.
Go deeper: RAR standard
Rich Authorization Requests is defined in RFC 9396.
Go deeper: What NIST says about push approvals
NIST SP 800-63B-4 (2025) treats push approval with care. Verifiers that send push notifications should limit how many they send since the last successful sign-in. A plain approval prompt on the phone is no longer acceptable. The reason is fatigue attacks. The person should move a secret from one channel to the other. For example, they type the number shown on the login screen.
NIST also says out-of-band authentication is not phishing-resistant. A fake site can still relay the request. A passkey is phishing-resistant, because it is tied to the real site. A push authenticator is a good second factor. It is not a replacement for a passkey.
🧪 Interactive lab — enable JavaScript to play with this one.
Building a branded push authenticator with rich transaction consent? Talk to our team.