How push approvals work
The end user taps a matching number on a device you have paired in advance.
The whole flow
- 1The developer’s backend mints a pairing code for one of its users and shows it to them.
- 2The end user enters that code in the U2 Secured Authenticator app, which links their device to your app.
- 3At sign-in the developer’s backend calls requestPush with that same user identifier and a context string.
- 4The U2 Secured Authenticator backend delivers a notification and shows the end user three numbers.
- 5The end user taps the number displayed on the sign-in screen, confirming with biometrics.
- 6The developer’s backend learns the outcome by waiting on the approval or by receiving a webhook.
This workflow is stateful
Unlike TOTP, the U2 Secured Authenticator backend holds real records here: the paired device, its delivery token, the pending approval and its expiry. That is what makes an enrolment list, central revocation and webhook delivery possible — and it is why approvals, not verifications, are what a paid plan meters.
Pairing must happen before the first push
A requestPush for a user who has never paired returns 404 ENROLMENT_NOT_FOUND, and one whose pairing never finished on the phone returns 409 NO_DEVICE. Neither means the code was wrong — they mean there is no confirmed device to send to yet.
Ubuntu sign-in is this workflow
The Ubuntu PAM module (pam_u2auth.so) is not a separate factor. It requests a push and waits for its status exactly as a web application would, after sshd has accepted the key or the desktop has accepted the password. Everything on this page applies to it, including pairing first: u2auth-admin enroll prints the pairing code. Ubuntu sign-in