No it's not okay for some kind of services.
Upon user connection with login password, generate a key derived from his/her password to encrypt data for this user and keep it in a session on the server.
That way, each user will have a unique key. This derived key must not be reversible, this is the main point. Using hash_mac or other hashing method with salt and/or master key will allows this.
Use this key to encrypt the generated API Secret using AES 256 with a random iv for each user.
2.bis Use this key to generate the real encryption key at the very last moment and encrypt the API method using the same way as in 2. to avoid in memory floating passwords.
3. Store the iv in the data base along with the user id and app id in a dedicated table
4. Store the encrypted API Secret in the database in the appropriate table.
Now when the user connect to his control panel you can recreate the key, fetch the iv, decipher the API Secret for this user and display it in clear text. You also display the key and ask for both when making API Call so that you can verify the App Secret.
If you want to avoid to display the key and not have to request it on API call you can also for authentication use the same method as for login. Meaning you can create another table to store a random key/salt for each client app and store a hash_mac version of the API Secret. Thus only the API ID and API Secret are required to authenticate API Request. but it's more work.
This is practically the same as @Polynomial answer.
This way it's very very difficult for someone hacking your server and database to steal your users credentials and make api call on their behalf. You can now assess that if a request has been accepted from a API client it's the right client or it's their leakage.
If the user loses his password then you regenerate a new API Secret and Key from his new password.