Push authentication: set up phone approval for your organization

This page is for the administrator who wants people to approve a sign-in on their phone instead of typing a code. It covers the policy setting that offers phone approval, the realm-wide settings under Settings > Authenticator, what enrolment looks like from the Admin Console, and how to check that approvals arrive. What the person sees on the phone is in Approve a sign-in on your phone and The SSOGEN Authenticator app.

Who can do this. A Super admin can do every step. An Authentication admin can create and edit policies and can read Settings > Authenticator but not change it. Choosing the Default policy or the Admin Console policy on SSO policies > Defaults is for a Super admin only. A Read-only admin can read all of these pages and change none.

What you need first.

A sign-in policy, or the default policy, that you may edit. If you have none yet, see Create a policy and assign it.
The SSOGEN Authenticator app on your people’s phones: iPhone on iOS 17.0 or later, Android 11 or later.
For notifications to reach phones, the SSOGEN server must be allowed to make outbound HTTPS connections to api.push.apple.com, fcm.googleapis.com and oauth2.googleapis.com. Without that, push is not lost: people open the app and approve there.

The result. After a person types their password (or signs in through your identity provider), the sign-in page shows one number and the line “Tap this number in the app”. Their phone shows six numbers; they tap the matching one and are signed in. Approval is always by number matching; there is no setting to turn that off.

1. Offer phone approval in the policy

Open SSO policies > Policies. The page says “Who signs in how, per application.” Select the policy to change, then Edit beside its requirements. (For a new policy, select Add policy, choose a starting point, and select Next.)
On the Requirements step, under Second factor (“An extra proof after the first factor.”), choose Required. Its help says “A second factor is asked after the first. SSOGEN asks for one when the provider did not.”
Under Accepted second factors, tick SSOGEN Authenticator approval. Use Move up until it is first; the summary line below the list then starts “Offered in this order: Approve in SSOGEN Authenticator, then …”. People are asked with the first method they can use; the others sit under “Use another way” on the sign-in page.
Decide what happens to a person who has no second factor yet, under If the person has no second factor: Offer to set one up during sign-in, After a reset only, or Send them to the help desk. With the first choice, people pair their phone the first time they sign in under this policy.
Select Next through Conditions and Name, and on Review select Save policy (or Create policy for a new one). The notice reads “Saved.” or, when the policy is already in use, “Saved. This change reaches n application(s).” A new policy says “Policy created. Assign it to applications from their Access rules tab.”

Two things to know while you are on this step:

Under Second factor: None, the page notes “People who set up an authenticator or paired a phone are still asked for it after a password.” So a person who pairs a phone is asked to approve even where the policy does not require a second factor.
The policy can also accept phone approval as the whole sign-in. Under First factor, tick Phone approval: “Anyone who knows a username can send a request to that person’s phone. They approve it only by tapping the number this page shows. Counts as both factors: nothing more is asked after it.” This needs SSOGEN Authenticator approval among the accepted second factors; otherwise saving is refused with “Phone approval needs SSOGEN Authenticator approval as an accepted second factor, and a second factor no stricter than Required.” Phone approval as a first factor is not available for the Admin Console’s policy.

2. Make the policy apply

A policy asks nothing until something uses it. The policy page says so: “Nobody is offered phone approval until this policy is used: after saving, choose Make default on its page for My Apps, or assign it to an application.”

For everyone signing in to My Apps and to applications without their own policy: on the policy’s page select Make default, or open SSO policies > Defaults and choose it under Default policy (“Used for sign-in to My Apps and apps with no policy of their own.”). Both need a Super admin; the notice reads “Saved.”
For one application: assign the policy on that application’s Access rules tab. See Access rules.
For the Admin Console: administrators always take a second factor, and approval in the app is one of the methods the console accepts. Phone approval as a first factor and emailed or texted codes are never offered there. See Admin Console sign-in.

3. Check the Authenticator settings

Open Settings > Authenticator (“Authenticator setup and push services.”). The page has four cards and one Save settings button, then a Push notifications section whose switches save on their own.

The card states how approval works: “Sign-ins are approved by number matching: the phone shows six numbers and the person taps the one the sign-in page shows.” It also says that “Sign-ins to the Admin Console also take an approval in the app, always with number matching.” The limits are:

Setting	Default	Allowed	What it does (as the page says)
Push lifetime (seconds)	90	30 to 180	“How long a phone has to answer one sign-in request.”
Devices per person	5	1 to 10	“How many phones one person can pair.”
Denials before push is paused	3	1 to 10	“Consecutive denials or wrong numbers that pause push for the person.”
Pause after denials (minutes)	15	1 to 1,440	How long push stays paused after those denials.
Pause after “This wasn’t me” (minutes)	60	1 to 1,440	How long push stays paused after a person reports a request.
Requests per 10 minutes	5	1 to 20	“Push requests one person can start in 10 minutes.”
Known network window (days)	30	1 to 365	The phone shows “Known Network Location” if the person signed in from that network within this window, else “New Network Location”.
Set-up window after a reset (hours)	72	1 to 720	How long after an administrator’s Reset MFA the person may set up a new second factor at sign-in.
Allow people to remove their phone from the app	on	on or off	A tick box, on by default: people may use the app’s own Remove this phone.

A number outside its range is refused with “Enter a whole number from min to max.” before anything is saved. The defaults are safe to keep for a first rollout.

Code setup

Where people get sign-in codes decides which authenticator apps are accepted for the 6-digit code. The default is SSOGEN Authenticator only: pairing a phone also sets up its codes, and no QR code for another app is shown. Any authenticator app keeps pairing and also lets people scan a QR code with another app. Approval on the phone works only with the SSOGEN Authenticator whichever you choose; another app gives codes only. Details are in One-time code policy.

Lost phone and App downloads

When a person loses their phone is covered in Lost or replaced phone. Under App downloads, iOS download URL and Android download URL are “Shown in My Account above Pair a phone. Leave empty to show none.” Each must start with https://, be 512 characters or fewer, and carry no user name or # part.

Select Save settings. The notice reads “Authenticator app settings saved.”

Push notifications

The switch Push notifications: provided by SSOGEN is on by default. With it on, the status line below it reads “Ready” once the server can reach Apple and Google. Turning it off shows “Push notifications turned off. People open the app to approve.” and the status “Off. The sign-in page asks people to open the app to approve. When a push cannot be delivered, people can still sign in with the 6-digit code the app shows.”

Leave Advanced: use my own app credentials closed unless you publish a rebranded app. Its help says: “Only for a rebranded app published under your own Apple and Google accounts. The SSOGEN Authenticator uses push provided by SSOGEN.”

The page reminds you that “Without push, people open the app to approve.” Push is a convenience; the sign-in itself, the number matching and the limits above are the same either way.

4. How people enrol, and what you see

A person pairs a phone in one of two places:

In My Account, under Authenticator, with Pair a phone (“Pair a phone to approve sign-ins on it and get your sign-in codes.”). The steps on the phone are in The SSOGEN Authenticator app, section 2.
At sign-in, when the policy offers set-up: after the first factor the page Set up your second step appears with Use the SSOGEN Authenticator, and the same pairing follows. Before that, the person proves it is them in the way the policy’s Before setting one up, the person proves says. The policy page adds that “The person is emailed when a second factor is added, and every offer, refusal and completion is recorded.”

Pairing is limited by Devices per person; at the limit the person sees “Phone limit reached. Remove one first, then pair this one.”

To see a person’s phones, open Identity > Users, open the person, and select the Devices tab. It opens with “Phones this person paired with the SSOGEN Authenticator. Key protection is as the app reports it.” and the table Paired phones:

Column	What it shows
Name	The phone’s name, with “Paired date” under it.
Phone	iPhone or Android, with the model when the app reported it.
App version	The SSOGEN Authenticator version on that phone, or “Unknown”.
Key protection	None, Software, Hardware (TEE), Secure Enclave or StrongBox, as the app claims.
Push	“Not registered”, or the push service with its state, for example “APNs (active)” or “FCM (disabled)”.
Last seen	When the phone last contacted SSOGEN; Inactive marks a phone not seen for 90 days.
State	Active, Suspended or Pending.

A person with no phone shows “No phone paired” and “This person has not paired the SSOGEN Authenticator, or every phone was removed.”

5. What the person sees

On the computer, after the first factor: “Tap this number in the app”, a countdown, Use another way for the other accepted methods. On the phone: a notification (or, with push off, the request when they open the app), the sign-in’s location marked “Known Network Location” or “New Network Location”, six numbers to choose from, and This wasn’t me. The page Approve a sign-in on your phone walks through it with screenshots.

Outcomes the sign-in page can show:

The page says	Why
“Request denied. Try again or use another method.”	The person denied it on the phone.
“The number you chose did not match. Start again.”	The wrong number was tapped.
“Sign-in stopped. Your administrator has been notified.”	The person tapped This wasn’t me. Push for that person pauses for Pause after “This wasn’t me” (minutes), the event is in the audit log, and Monitoring > System health counts it under Setup health for 24 hours. No email or message is sent to you.
“The request expired.”	Nobody answered within Push lifetime (seconds).
“Too many requests. Use another method.”	The person reached Requests per 10 minutes.

Check it worked

Test the policy without signing anyone in. On SSO policies > Policies, select Test on the policy. The dialog “Test policy name” says “See what this policy would ask of one person. No one signs in and nothing is changed.” Enter a Username of someone who has paired a phone, leave Signed in with at Password or single sign-on, and select Run test. The result reads “More is needed: SSOGEN asks for a second factor.” and “Second-step methods this person could use now: Approve in SSOGEN Authenticator, SSOGEN Authenticator code, …”. A person who has paired nothing shows “…: none.”
Check the push service. Open Monitoring > System health. Under Setup health, the item Authenticator push (Firebase and Apple) should read “Push approvals work for Android and iPhone.” The other messages it can show are in the troubleshooting table.
Sign in as a person with a paired phone, in a private browser window, to an application that uses the policy (or to My Apps if the policy is the default). The page shows a number; the phone shows six; tap the match; you are in.
Find it in the audit log. Open Monitoring > Audit, open Advanced filters, enter authenticator.push_approved in Event type and select Search. The row reads “Authenticator push approved” in What with the person in Who.

Troubleshooting

What you see	What it means and what to do
System health: “Push approvals are turned off. People approve with the codes in the app.”	Push notifications: provided by SSOGEN is off under Settings > Authenticator. Turn it on, or leave it off deliberately: people open the app to approve.
System health: “This server got no answer from Google’s (fcm.googleapis.com) or Apple’s (api.push.apple.com) push service recently, so people open the app to approve. Allow outbound HTTPS (port 443) to it.”	The server cannot reach the push service. Open the firewall for outbound HTTPS to the hosts named in “What you need first”. Sign-ins keep working meanwhile.
System health: “Push approvals are not set up for Android or iPhone. People can still use codes.” or “Push approvals are not set up for Android (Firebase).” / “… for iPhone (Apple).”	This installation has no push service for that phone type. People on it open the app to approve.
Settings > Authenticator: “Cannot reach Apple/Google. Allow outbound HTTPS to api.push.apple.com, fcm.googleapis.com and oauth2.googleapis.com. Until then people open the app to approve.”	Same cause as the System health line above.
Settings > Authenticator: “Someone else changed this since you opened it. Reload and try again.”	Another administrator saved the page first. Reload, check the values, save again.
Settings > Authenticator: “Too many tries. Wait a minute and try again.”	Saves are rate-limited. Wait a minute.
Settings > Authenticator: “Could not save the Authenticator app settings.”	The save failed for another reason. Try again; if it continues, check Monitoring > System health.
Policy save: “Phone approval needs SSOGEN Authenticator approval as an accepted second factor, and a second factor no stricter than Required.”	You ticked Phone approval as a first factor without SSOGEN Authenticator approval under Required. Tick it, or untick phone approval.
Policy save: “Phone approval is not available for the console policy. Turn it off or use another policy.”	The policy is the Admin Console’s. The console never offers phone approval as a first factor.
Policy Test: “Second-step methods this person could use now: none.”	The person has paired no phone and set up no other method. Ask them to pair a phone, or let the policy offer set-up during sign-in.
Devices tab: “Unable to load this person’s phones.”	The list could not be read. Reload; if it continues, check Monitoring > System health.
Devices tab: “Your role doesn’t allow this.”	Your role cannot read this person’s phones. A Super admin, Directory admin or Read-only admin can.
Devices tab: the person’s row shows Push suspended	Push was paused after repeated denials or a report. The notice says until when; sign-in offers the person other methods meanwhile. A Super admin or Directory admin can select Clear push suspension. See Lost or replaced phone.
A person gets no notification	Their phone’s Push column reads “Not registered” or “(disabled)”, or push is off or unreachable (above). They can still open the app: the request is waiting there.
Sign-in page: “This sign-in needs a second step, and no method is set up for your account. Contact your help desk.”	The policy requires a second factor, the person has none, and the policy does not offer set-up at sign-in. Change If the person has no second factor, or have them pair a phone under My Account.