It's transparent to the client, so if the server adds support, every client gains 2FA support. The server needs to check if 2FA is enabled, and if so, try the last 6 characters of the user provided text as the OTP and the rest as the password.
It's a pretty commonly used, and works very well, but requires user education on how to fill in their combined password. A proper API with distinct fields for password and OTP is cleaner, but requires protocol support.
Isn't that horrible UI-wise? The UI will ask for password and show '******'. The user then has to remove the last 6 stars and put in the OTP.
A dedicated question for the OTP would be much better. Also, the password manager would know to not save the password+OTP every time as a new password.
It is, but think of why you'd build this. You own the backend and need to add 2FA support. The various client software isn't written by you so you can't change them. This approach allows the client software to add an OTP field (concat the fields for the user) but doesn't require it (user must concat OTP on password manually).
Many of the places I've seen this used don't integrate well with software password managers. OS login screen, console apps, etc; typically not web apps. But this is a good criticism.
It's a pretty commonly used, and works very well, but requires user education on how to fill in their combined password. A proper API with distinct fields for password and OTP is cleaner, but requires protocol support.