Google does this. Slack does this. Native Twitter apps do this. Yes, other apps may ask for your username and password from within the app, but they’ve made a conscious choice for lower security. We made a conscious choice for higher security.
Yes. Nevertheless, more often than not, we find a solution to those things which avoids us having to compromise your security for convenience.
Having worked in this field for quite a long time, especially around various authentication schemes for numerous internet protocols (WinGate), I would have to suggest that there’s nothing that prevents an equally secure system from being set up to make this entirely transparent and independent of browsers and even web servers.
Browsers are not magic, and don’t magically inherit extra security that no other app or protocol can access. Even OAuth can be implemented in custom code using http without a browser. But using OAuth was a choice, and there are plenty of secure authentication mechanisms available.
Also, OAuth typically only provides real value when you are using some kind of syndicated providers, e.g. using your google or facebook credentials to authenticate. I didn’t notice this in Steinberg, but maybe it’s there (it’s been a while since I created my account).
In fact I would argue that adding the attack surface of the browser / webserver ecosystem to your activation system could potentially reduce security. All you need is a new zero-day attack to come out (these browsers receive a lot of attention from hackers) and your whole system could be compromised.
I understand it is appealing to use off-the-shelf components to add things like OAuth. So it may be harder to make a different kind of system, especially since Steinberg is not a network software company with crypto experience etc.
In the end, even when the system works perfectly, it’s pretty clunky but that’s not the end of the world. It can just be quite tricky to troubleshoot issues around this if it doesn’t work.