Apps (server side) don't need to handle keys or tokens at all. Everything can be done client side like it's done on dtube and steemit. It works really well this way. Nobody ever gets your key, you don't need to delegate any authority to anyone.
You actually introduce security holes that didn't exist before SteemConnect, so calling it more secure it a total joke.
Only good point for SteemConnect is that it makes it easy for noob developers to start creating something on steem, without having to code a proper key storage and verification system for their apps.
There is 2 differents ways. Both have advantages and downsides.
Not everything, for example you canot do scheduled post on client side.
You also need to know how to do a proper key storage with auth, some app failed on this and we canot expect every app will know how to do it properly.
You need to have your code reviewed (be open source) or be trusted in the community not everyone is dtube and steemit.
The app may get it, if the server is hacked like was Utopian the hacker could log users keys and force users to update their keys in the end. With SteemConnect we don't store key, the hacker may get an
access_tokenwhich expire after 7 days or get manually revoked but users keys are not exposed.May you always succeed in helping others
First you say client side do not need key handling, then you say they should code a proper key storage ...
Isn't it contradictory ?
It really depends on a purpose of the app. For an interface like Steemit or DTube there is no need to store keys on the server side nor access tokens. But there are certain types of apps that need that, and as far as I know, it is way more secure to store OAuth2 tokens than private keys.