Mobile push authenticator stage

[mnaiman]

Is your feature request related to a problem? Please describe. I know there is support for Duo for having 2FA with mobile push notifications. Duo is paid service, which doesn't align with open source nature of Authentik.

Describe the solution you'd like It would be great to have similar functionality of mobile push notifications, because rewriting OTP/HOTP codes are too user unfriendly compared to confirming notification on mobile phone, like eg Microsoft Authenticator is doing.

There is already complete mobile app developed by privacyIDEA project for their MFA server at https://github.com/privacyidea/pi-authenticator and published eg here https://play.google.com/store/apps/details?id=it.netknights.piauthenticator&hl=en&gl=US

Therefore it would be sufficient to publish that stage and compliant API as privacyIDEA server, or fork mobile app and create custom API.

[RoboMagus]

Perhaps a generic interface that could be used for 2FA approval? I can imagine calling a script / webhook to be useful for many potential 2FA methods.

[mnaiman]

Generic interface for 3th party integrations could be useful too. My idea was about to replace Duo mobile authenticator with Authentik mobile authenticator, which would be more user friendly for end users.

[sevmonster]

Just wanted to throw some cents into the ring:

Mobile push notifications are non-trivial, especially if you are trying to stay away from proprietary services. Anything on Android that isn't FCM will have to exist on a spectrum of increased battery usage or faster/more reliable delivery of notifications. Few apps have ever done it well, Signal and Ntfy (if you use WebSockets) are good examples. Even then, they will only approach but not surpass FCM. Never seen privacyIDEA before but if it can be as responsive as Signal that will be a huge achievement.

Additionally, even if you are OK using FCM, every server operator will need to provide their own Firebase keys, and build and ship the app themselves with those keys. Either that or a centralized cloud server could set up under e.g. goauthentik.io that relays messages to FCM on your behalf. That approach has been taken before and can be a good way of keeping data out of Google's hands (i.e. only provide URLs/hashes that the authentik cloud server can process) but it still introduces yet another data broker into the mix, and a new service to support.

Lastly, running your own reliable push notification server is also difficult, privacyIDEA or otherwise. If you have more than a handful of users you need to ensure there are enough resources allocated for constant connections with all users at once. Good luck with that if you're hosting from home, most ISPs will throttle you hard or enforce connection timeouts.

And of course, no matter the direction taken here, implementing this will ultimately incur a lot of technical debt, either on authentik development or on the server operator. The amount grows steadily as you head away from a basic FCM setup, which is naturally the easiest to implement, but also the least privacy friendly and offers the least control to server operators.

The easiest method to develop that would not involve locking anyone to any specific ecosystem (e.g. privacyIDEA, FCM, or home-grown app) would indeed be to have a generic interface like @RoboMagus suggested.

I don't say any of this to dissuade, just providing some context. Obviously I have no idea how Apple does it, I can only ignorantly speak on Android...

[BeryJu]

Apple is very similar to FCM, all notifications have to go through apple. These requirements have stopped me from implementing this before, as either all authentik instances would require their own FCM/Apple setup (which is 100$ a year), with their own apps (to use that specific accounts FCM/Apple push (not sure about this point), and need to be publicly accessible, or there would have to be a central authentik push gateway, with one set of apps, similar to how Home-assistant does this.

This is currently one of the features we're planning to implement on the "enterprise" version of authentik, as it will require a central hosted service for these push notifications, and quite a decent amount of development time for the apps. The current plan is to make those apps and the gateway open source, so people that have an Apple developer account/FCM can still deploy it themselves

[mnaiman]

Yes I agree, but we dont have to stay away from proprietary services, because Google and Apple services are proprietary by nature. Is just about opening Google account for Firebase, and updating 2 keys in authentik config to use them and its working. Centralized servers are not necessary, always better to use native services for Google and Apple.

I dont know about Apple pricing, but Google is free https://firebase.google.com/pricing

You can use Google FCM to send push notifications to Apple either https://firebase.google.com/docs/cloud-messaging/ios/client

So its just about some generic interface (agree, that generic is always better) and mobile app where you can attach device to user and send FCM key to app during provisioning.

[mnaiman]

If you take a look how privacyIDEA is doing auth push notifications, code is here https://github.com/privacyidea/pi-authenticator/blob/master/lib/utils/push_provider.dart

Its provider for Google/Apple using FCM.

This app would be nicely adaptable (branding/icons/config) without changing much of codebase, because it has same purpose.

[sevmonster]

Yes I agree, but we dont have to stay away from proprietary services, because Google and Apple services are proprietary by nature.

The point I was trying to make with that is that some users (myself included) do not want to use Google or Apple proprietary services. They are not the only option. If I ever were to implement push notifications, I would take the more difficult path of implementing my own self-hosted solution, as I described above. I do not use Google services on my phone, I do not have a Google account, and I will not start using either just for FCM. One of the great benefits of open source software and self-hosted solutions is that you are not locked in to specific software vendors and opaque cloud services.

Is just about opening Google account for Firebase, and updating 2 keys in authentik config to use them and its working. Centralized servers are not necessary, always better to use native services for Google and Apple.

It might always be better from an ease of use and performance standpoint, but there are other things to consider.

Unless I am mistaken, Firebase keys are provided for both the mobile app and server. This is how it worked when I last looked into it. This means you need to either:

1. Ship a mobile app with your Firebase keys, and add the server keys to authentik.
2. Use pre-built mobile app with baked-in keys provided by Authentik Security, and have the authentik server send messages to a cloud service which contains the private Firebase keys. The cloud service then forwards the message to Firebase.
3. Use a pre-built app that can receive the Firebase key (apparently privacyIDEA can do this) and provision the app when setting up the connection to authentik. I didn't previously consider this as an option, but it makes sense. In theory you could also use whatever app you wanted as long as you could extract the keys for it, as long as all the interfaces were generic. However this also potentially opens up a security vulnerability where a malicious server could send their own Firebase keys, though this is far-fetched. I also don't know how this complies with Google/Apple terms, maybe they don't like this approach.

In any of the above cases however, you are still widening your attack surface by sending confidential information (be it a link or API endpoint to confirm the request, or a one-time code) through a cloud service. You can argue this is safe because you can trust Google, Apple, or Authentik Security, and most people have Google/Apple proprietary code running on their devices anyway, but some people may find this to be an unacceptable risk depending on their threat model or personal preferences. This is possible to mostly mitigate by building an API for the server that sends data to the app, and only send an index pointing to that encrypted data on the server through the messaging platform. Of course you would then either need some kind of authentication mechanism between the app and the server, or have the data be sent encrypted with the client processing the ability to decrypt it.

So its just about some generic interface (agree, that generic is always better) and mobile app where you can attach device to user and send FCM key to app during provisioning.

I would probably use Ntfy with a link to whatever callback authentik needs to complete the authentication. That would also allow users to receive the notifications on whatever device they wanted and not be limited to a smartphone app. It's probably my favorite human-readable message transport; MQTT for machine-readable.

[nicerloop]

So its just about some generic interface (agree, that generic is always better) and mobile app where you can attach device to user and send FCM key to app during provisioning.

I would probably use Ntfy with a link to whatever callback authentik needs to complete the authentication. That would also allow users to receive the notifications on whatever device they wanted and not be limited to a smartphone app. It's probably my favorite human-readable message transport; MQTT for machine-readable.

It seems to me that combining Web Push API with WebAuthn would provide a nice streamlined and modern MFA authentication through mobiles, without any device-specific application.

ntfy is already capable of pushing notifications through various means, including mobile application and web application. It would be really nice to be able to use it with Authentik.

[sevmonster]

It seems to me that combining Web Push API with WebAuthn would provide a nice streamlined and modern MFA authentication through mobiles, without any device-specific application.

WebAuthn (Passkeys etc) is so well supported on stock mobile devices right now I think that may be a good option. Should be easier to implement with native libs, and at least on Apple devices, your passkeys are synced to your account and as such all of your devices. However, if memory serves, I believe the current native WebAuthn implementation on Android is shipped with Google Play Services, which sucks. Chrome requires that in order to use WebAuthn, and support is currently flaky to nonexistent on Firefox. Would love to be corrected on any of this as the last time I looked into it was quite a while ago.

As for WebPush, I have never gotten it to work on any device ever when I've intentionally tried to use it. Only ever seen it work when end users were getting spammed with advertisements.

ntfy is already capable of pushing notifications through various means, including mobile application and web application. It would be really nice to be able to use it with Authentik.

I would push for this, or perhaps Apprise. Apprise is a fantastic library and has great support for Ntfy and many other services. This would also give authentik end users a huge amount of freedom in their chosen notification provider. It's also Python so it would easily work with the authentik stack. Even with an authentik-provided app or other solution implemented, I would still recommend Apprise for the sheer utility.

[BeryJu]

We've started some work on this with https://github.com/goauthentik/authentik/pull/6359, but due to other things coming up we haven't had time to work on it more. However there are workarounds with WebAuthn and using a mobile device as a passkey