MFA without Apple or Google push

The platform-push model#

iOS does not let an application keep its own network connection alive in the background, and Android allows it only as a foreground service with a permanent notification. To wake an application that is not running, iOS and Android each provide a single system-wide channel: APNs on iOS, FCM on Android, the latter part of Google Play services. The phone maintains one persistent connection to the platform operator, and any server that wishes to reach an application on that phone sends its message to the operator, which forwards it.

A push-based authenticator uses this channel as follows. At installation the application registers with the platform and receives a device token. The token is uploaded to the MFA provider and stored against the user. For each sign-in, the provider’s server authenticates to the platform with its own credential — an APNs signing key or certificate, or an FCM service-account key — and submits a message addressed to that token. The platform delivers it, and the phone displays a notification on the lock screen.

Four properties follow from the architecture rather than from any one provider’s implementation:

• A third party sits in the delivery path. Every prompt is accepted, queued and forwarded by Apple or Google. The MFA server needs outbound connectivity to the platform’s endpoint, and the phone needs connectivity to the platform’s push service.
• Delivery metadata is visible to the relay. A sender can encrypt the payload, but it cannot hide from the relay that a given sender addressed a given device token at a given moment. Taken together, those records describe when each user authenticates, and to which service.
• Delivery follows the platform’s policy. Both services define priorities, collapse rules and throttling, and both describe delivery as best effort. A prompt can be delayed or dropped for reasons the MFA operator neither controls nor observes.
• The sender holds a long-lived platform credential. The signing key or service-account key that authorises sending must be stored, protected and rotated, and its loss or expiry stops delivery for every user at once.

Delivery over a device-held stream#

Ydentifi replaces the relay with a connection the phone makes itself. While the authenticator app is active, it opens a gRPC SubscribeChallenges stream over mutual TLS 1.3 directly to the deployment it was enrolled with. When a relying party issues a challenge, the deployment writes it down that stream. The phone presents the request, the user decides, and the signed decision returns over the same deployment through SubmitChallengeResponse. Where the user is already in front of a screen, the challenge can instead be shown as a QR code that the phone scans.

There is no device token in this design, because nothing is registered with a platform service. The authenticator app requests no push entitlement and holds no push token, and the server holds no Apple or Google credential. The only parties to a challenge are the relying party, the deployment that the operator runs, and the enrolled phone. The endpoints are documented in Device-facing gRPC, and the full exchange in The ceremony.

What changes#

• No authentication metadata leaves the operator’s infrastructure. Neither Apple nor Google receives a record that an authentication took place. Combined with opaque identities, the deployment itself holds no name, email or telephone number for the people it authenticates.
• The network requirement is one address. The phone needs to reach the deployment and nothing else. A deployment on a private network, reachable only from phones on that network or over its VPN, delivers challenges the same way as one on the public internet. The server makes no outbound calls in the authentication path.
• No platform credential exists to expire. There is no push certificate to renew, and no sender key whose compromise would let a third party send prompts to the whole user population.
• Delivery is observable end to end. A challenge waits in the deployment until the phone collects it or its lifetime ends, and its terminal state — approved, denied, expired or one of the others — is reported to the relying party over AwaitChallenge. No queue outside the operator’s control holds it.

What the design costs#

The platforms reserve background wake-up for their own push channels. Without one, the stream exists only while the app is active. Three consequences follow, and a relying party should design around them rather than discover them:

• No lock-screen prompt. A challenge does not announce itself on a locked phone. The relying party’s own interface has to tell the user to open the authenticator, at the moment the challenge is issued.
• The challenge lifetime has to allow for that step. A challenge lives for 60 seconds by default, set per call. If the app is not opened in time, the challenge ends EXPIRED and the relying party can issue another. See Limits & quotas.
• Approval is a deliberate act. The user opens the app because they started something. This also removes the condition that push-fatigue attacks depend on: a prompt that arrives unrequested on a lock screen and can be accepted with one tap. Number matching, requested per action, narrows the remaining case of a user approving a request without reading the screen it came from.

For sign-in, where the user is at the relying party’s screen, these costs are small. For approvals that must reach someone who is not expecting them, such as an out-of-hours sign-off, the process has to include a separate prompt to open the app.

Where it applies#

The design is aimed at operators for whom the relay is itself the problem:

• Regulated and sovereignty-bound organisations that must not route records of their users’ activity through a foreign platform operator.
• Restricted networks — government, defence, critical infrastructure, operational technology — where outbound traffic to Apple or Google is blocked or must be justified.
• Products that embed approval in their own app through the Swift device SDK and the embedding guide, and do not want their authentication path to depend on a push configuration they did not design.

The comparison with the common push and one-time-code model is set out on the product page. A local deployment runs in about five minutes with the quickstart, and every tier, including the free one, ships the same delivery path; see pricing.