A much smarter (since it's both more secure and poses less of a risk to users doing the forwarding) way to solve the same problem is to use missed calls (the last n digits of the caller ID are the OTP code).
WhatsApp does that in some countries on Android (where there's an API to read caller IDs of incoming calls).
It's absolutely bonkers to grant any app permission to this kind of information, even if the claimed use is legitimate. Just the normalization of that kind of access is causing damage to the overall security of the ecosystem.
We really, really need to come up with a better "proof-of-stake" mechanism standard for spam prevention and authentication, than abusing the legacy peering complexity of SMS/WWAN access.
This is also supported by Telegram, as well as sending codes via email (in select countries), see https://core.telegram.org/api/auth#code-types for the full list of authentication methods (which are chosen by the server, depending on the country of the user and some other heuristics).
If a 2FA password is configured, it is still required in order to login with a future auth token; however, even if it isn't set up, the fact that you have a future auth token means you have already logged in and then logged out on this specific device, so it's not a real issue (i.e. it's as if when logging out, you didn't actually log out but rather just hid the account in the UI, the future auth token is stored safely, in the same place as normal auth keys are + re-entering the 2FA password is still required).
