goauthentik
Enhance the SMS authenticator: multiple instances per user, multiple users per phone number
Is your feature request related to a problem? Please describe.
I am using the SMS authenticator for sending auth tokens via Telegram and Signal messages. With the Generic web-hook interface and a small Node-RED flow linking to a Telegram or a Signal API endpoint, this basically works well. For Telegram, a custom prompt explaining the user how to get their Telegram ID (which is used instead of the phone number) is needed, but that is no problem due to the flexibility of authentik's prompts.
However, there are a couple of rough edges that might be improved upon, especially for non-technical end-users:
- It is currently possible to setup multiple SMS authenticators per user, such as, both a Telegram and a Signal account, for instance. Only a single one of these is presented upon login, though, seemingly at random. Since the label is always "SMS (Tokens sent via SMS)", the user cannot tell which one it is. This is a minor point if you have both (or all) messenger accounts on the same device anyway, but might be undesirable when the user has, say, a personal and a work device with separate accounts and can only use one of them at some point.
- Setting up SMS authenticators for different user accounts with the same effective Signal or Telegram destination is only possible with a workaround: For Signal, which uses a phone number, that same phone number needs to be formatted slightly differently for each use, e.g. "+491234567890" vs. "+49 123 4567890" or "0123 4567890" (for a German phone number). For Telegram, one might add spurious characters to the ID, which are stripped by the external API glue code (e.g., "123456789" vs. "123456789x"). This is unnecessarily cumbersome. My specific use case is a regular user account and the akadmin account, both of which I would like to secure with 2FA using the same messenger account. Other cases of multiple-account users seem reasonable as well.
Describe the solution you'd like
For 1., my favored solution would be for all SMS authenticator instances to show up on the selection page. Instead of just "SMS", the user-configurable name of the specific instance should be shown to be able to tell them apart. The default being "SMS Device", this would not change much for the current use as a (unique) SMS authenticator, but would allow users to rename their devices to "Signal on +491234567890" or "Signal work phone" etc.
For 2., my favored solution would be to simply allow re-use of already-in-use phone numbers.
Describe alternatives you've considered
For 1., the obvious alternative is to disallow multiple instances of the SMS authenticator service per user. This should then be enforced at the point of configuration, i.e., trying to setup a second SMS authenticator should be prevented with an error message like, "You need to remove your existing SMS authenticator before configuring a new device". A similar result might be achieved with an appropriate authentik policy, but this shouldn't be necessary for a condition that is forbidden in any case.
For 2., if multiple use of the (exact) same phone number string is not desired, a more informative error message should be given. Currently, trying to enter a duplicate phone number at the configuration stage results in the following runtime error
'AuthenticatorSMSChallengeResponse' object has no attribute '_errors'
Traceback (most recent call last):
File "/authentik/flows/views/executor.py", line 298, in get
stage_response = self.current_stage_view.get(request, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/authentik/stages/authenticator_sms/stage.py", line 117, in get
response._errors.setdefault("phone_number", [])
^^^^^^^^^^^^^^^^
builtins.AttributeError: 'AuthenticatorSMSChallengeResponse' object has no attribute '_errors'
I do not see any advantages of these alternatives, though.
Additional context
This is probably not specific to Signal and Telegram, which I happen to be using. Furthermore, similar issues might apply to cases of multiple instances of TOTP or Static Token authenticators per user, but I have not tried that.
I am using authentik version 2023.8.1.
Thank you for creating this great software and for taking the time to read this!
telegram also allows you to make bots and it would be possible to implement push confirmation in telegram, (for example, a request for approval or refusal of authorization comes)
@drpetersen Can you please share your complete solution, How did you configure signal with Node-RED flow to get TOTP code via Signal? Thanks.
- It is currently possible to setup multiple SMS authenticators per user, such as, both a Telegram and a Signal account, for instance. Only a single one of these is presented upon login, though, seemingly at random. Since the label is always "SMS (Tokens sent via SMS)", the user cannot tell which one it is. This is a minor point if you have both (or all) messenger accounts on the same device anyway, but might be undesirable when the user has, say, a personal and a work device with separate accounts and can only use one of them at some point.
This is definitely a bug, each SMS device should show up as a separate option
- Setting up SMS authenticators for different user accounts with the same effective Signal or Telegram destination is only possible with a workaround: For Signal, which uses a phone number, that same phone number needs to be formatted slightly differently for each use, e.g. "+491234567890" vs. "+49 123 4567890" or "0123 4567890" (for a German phone number). For Telegram, one might add spurious characters to the ID, which are stripped by the external API glue code (e.g., "123456789" vs. "123456789x"). This is unnecessarily cumbersome. My specific use case is a regular user account and the akadmin account, both of which I would like to secure with 2FA using the same messenger account. Other cases of multiple-account users seem reasonable as well.
One possible workaround for this would be to modify whatever is entered in a policy, however I dont think it makes sense to remove the default restriction of making a phone number globally unique
