Android push approval for Autharky

Where it fits in Autharky

Autharky already has the right server-side boundary. After password or brokered login, it checks for configured factors and blocks at stageNeedSecondFactor. Today TOTP and passkeys are alternatives.

A push approval becomes a third choice at that same stage.
Success adds push or duo to the browser session's OIDC amr.
The approval must only complete a challenge bound to the already password-authenticated browser; it must never create a login by itself.
PostgreSQL-backed sessions and ceremonies already give us multi-instance-safe state. No Redis is needed.

The realistic options

Recommended first

1. Duo Mobile

Duo Mobile exposes Approve and Deny in the Android notification. Duo Free supports up to ten users, and Universal Prompt has an official Go SDK.

Autharky keeps primary login and OIDC issuance. Duo handles enrollment, push delivery, phone policy and the second-factor ceremony.

Cost: backend integration, callback/state handling, factor UI and tests. No Android development.

Trade-off: SaaS dependency and a Duo-hosted browser prompt. Number-entry and biometric policies are safer but no longer pure one-tap drawer approval.

Fast prototype

2. ntfy

The existing ntfy Android app can show arbitrary HTTP Approve/Deny actions. It is open source and self-hostable, so Autharky could publish a 60-second one-time callback without building an app.

Catch: this proves possession of a delivered bearer callback, not a device-held private key. The generic action also does not guarantee authenticated device unlock.

Private HTTPS, deny-by-default ACLs, per-user topics and one-time tokens reduce risk. They do not make it cryptographically device-bound MFA.

Poor fit

3. privacyIDEA

privacyIDEA has a mature signed push protocol and open-source authenticator. Enrollment creates a keypair; server challenges and phone responses are signed.

Its current app performs approval in an in-app dialog rather than offering the requested notification actions. It also introduces a second authentication server beside Autharky. Forking the large Flutter app is more machinery than a small dedicated client.

Middle ground

4. Installable PWA

Web Push and a service worker can show Android notification buttons with no app store and automatic updates.

Browser support is less uniform, and the web platform does not expose the same reliable device-unlock and hardware-backed signing controls as native Android. Useful for an experiment, not the preferred security boundary.

Option	Drawer actions	Self-hosted	Security	Best use
Duo Mobile	Yes	No	Strong, mature	First implementation
ntfy	Yes	Yes	Bearer-action	Personal UX prototype
privacyIDEA	Not directly	Yes	Strong	Existing privacyIDEA estate
Autharky app	Yes	Mostly	Strongest control	Long-term self-control

If we build the Autharky app

A small dedicated Android client is feasible. It should treat FCM only as a wake-up transport and make the device's cryptographic key—not the notification payload—the factor.

Enrollment

The authenticated Security page creates a short-lived, single-use enrollment QR.

The app generates a non-exportable P-256 signing key in Android Keystore.

The app sends its public key, device name, push token and enrollment proof to Autharky.

Autharky stores a tenant/user-scoped device. Removal revokes it immediately.

Authentication

After primary login, Autharky creates a random challenge bound to tenant, user, browser session, client, nonce and a 60–90 second expiry.

FCM delivers a high-priority signed challenge with no reusable credential.

The app verifies Autharky's signature and shows client, time/IP context and a short number also visible in the browser.

Approve and Deny are native notification actions. On Android 12+, Approve requires device authentication before execution.

The device signs its decision and posts it to Autharky.

Autharky verifies the enrolled public key and atomically changes pending to approved or denied. The original browser consumes approval once and records push in amr.

Non-negotiables: one outstanding challenge, resend cooldown, number matching, rate limits, audit events, device removal, token rotation, fallback factors, replay protection, tenant/session binding and atomic concurrent approval/denial handling.

FCM data is not end-to-end encrypted by default. Send only a signed opaque challenge and minimal display data, or encrypt the payload to the enrolled device. Never put a reusable Authorization header or approval secret in a notification.

No Play Store is required

Android officially supports installing a signed release APK from a website or email after the user allows that source.
Firebase says an FCM Android app does not need to be deployed through Google Play, although the device needs Google Play services.
Keep the APK signing key safely backed up; all future updates must use it.
For a few friends, host signed APK releases with checksums and version notes. A private F-Droid repository or updater can come later.
Google's developer-verification rollout includes a free limited-distribution path for up to 20 authorized devices. Recheck the 2026–27 rollout before release.

For devices without Google services, use UnifiedPush or authenticated polling. The phone still needs to reach Autharky's public HTTPS issuer.

Recommendation

Integrate Duo Universal Prompt first. It matches the requested notification behavior and validates Autharky's factor selection, callback, AMR, enrollment and recovery model without mobile work.
If SaaS is unacceptable, use ntfy only as a labeled UX spike. Do not present its bearer-action model as equivalent to a signed device approval.
Then build the focused Autharky Android client if self-control is worth the maintenance. Keep TOTP and passkeys as recovery alternatives and include number matching even when approval stays one-tap.

Android push approval as optional 2FA