Approving a sign-in on the phone
Applies to: identity newer than 0.33 · messaging newer than 0.146 · Checked: 27.09.2026
As in Microsoft Authenticator, Okta Verify or Duo, but in our own app: after the password, identity's sign-in page offers "Approve on your phone", the phone gets an "Is this you signing in?" notification, the person picks on the phone the number the page shows — and the sign-in continues.
Turning it on
Identity console: Policies → Sign-in requirements → Approve a sign-in on the phone → on, or the
credential policy field push_approval: on. Off by default.
Nothing to enrol: a phone is any device where the person is signed in to the SimpleTwo app and
allowed notifications. The person sees these devices in the /me portal, Security tab, card
"Approve sign-ins on the phone". Signing in to the app adds a device; signing out of it removes
one.
When the page offers the phone
Wherever the sign-in page asks for a second factor:
- after the password, for a person with an authenticator code — the phone beside the code field;
- when the policy requires a second factor (
mfa_required) or the application requires two (require_mfa): a person whose only factor is the phone is offered the phone instead of setting up an authenticator; - when a sign-in steps up for an application that needs two factors.
Not after a passkey: the passkey may live on that very phone, and one phone is one factor. The code, the e-mail code (sign-in codes by e-mail) and the passkey stay as the other ways; with the e-mail code and the phone both, no letter goes out until the person picks e-mail.
Signing in to the SimpleTwo app itself (through the coordinator) asks no phone approval: where the policy requires a second factor, that sign-in still takes the code or a passkey.
What it looks like
- The page shows a large two-digit number and waits.
- The phone gets a notification — a locked one too: the application, the network and browser, as in the new-device sign-in notice, and the time. Buttons: "Approve…" and "Deny".
- "Approve…" asks for the phone to be unlocked and opens a sheet with three numbers. The person picks the page's number. The wrong number denies: a request approved without looking is a one-in-three guess, and it is closed.
- The page notices the answer by itself and continues the sign-in.
The sheet also has "Deny" and "This wasn't me". "This wasn't me" denies the sign-in and ends every session and refresh token of the account, like the portal's button of the same name, and offers to change the password: whoever tried knows it.
With several phones the request goes to all of them; one answer counts, and the other devices are told "this request was already answered".
Limits
| What | How much |
|---|---|
| Time to answer | 2 minutes |
| Requests waiting per account | 3 |
| Requests per account | 10 per 15 minutes |
| Requests from one address | 20 per 15 minutes |
Over a limit the page says "Too many requests to your phone" and offers another way. A request is single use: the page redeems an approved sign-in once.
The log
In the security event log (and the SIEM):
push.request— sent (or refused:reason=budget,no_device, address locked;failed— no device received it);push.approve— approved; refused when the wrong number was picked (reason=wrong_number);push.deny— denied;push.not_meandsignin.not_me— "This wasn't me" and the sessions it ended;push.expire— two minutes passed without an answer.
Recent sign-ins show such a sign-in as "password + phone approval". In the application's token
amr carries push and, together with the password, mfa.
What the server needs
The request travels through messaging: of identity's events it is the one that also goes out as a real push (APNs, FCM), or a locked phone would not get it. Messaging's push must be configured (the APNs key and/or the Firebase service-account key in the coordinator's admin console). Without it there are no devices to approve with, and the page does not offer the phone.