I'm working on a Node.js app which requires the user to enter his API keys from a third party service (the service doesn't allow logging in via oauth). Right now i'm storing these in a .env file, so it needs to be entered on setup. I'd like te user to be able to set the keys once in the user interface (with a password) and then store them persistenly, so that when quitting the app and restarting again, the keys will still be there. How would i go about this? Do i encrypt the keys and store them in a db? Are there any other methods?
In general this is too much risk both for your users and you as the service provider. If these are valuable api keys that you want to store, your service becomes a good target. As you also noted, this is what oauth was invented for.
If you still decide to do this, you can trade some ux for more security. You should definitely encrypt api keys, but where to store the encryption keys so that it actually makes sense is always the question.
Think about how an attacker might get hold of these api keys (the threats), and that will help come up with adequate protections (mitigations to those threats).
For example, an attacker might access the database directly or offline, like from a backup, or through a compromised db server. For this, standard encryption at rest as provided by your dbms is good, especially if you use something like AWS and KMS to store the encryption keys. So you need encryption at rest, but that's not enough.
An attacker might compromise your app too, so transparent encryption doesn't help. You can for example encrypt your sensitive fields (ie. the api keys) on the app level, with unique keys associated with each user, stored securely in an appropriate service (like a HSM, or in something like Secrets Manager in AWS). This might still allow access to an attacker, but it's getting more difficult, and you get a lot more control and auditability over key access.
And to take it one step further, you cab derive keys from your users passwords with a proper key derivation function (like pbkdf2 or similar), and never store them in a database, only memory. This means logged in users' secrets might still be compromised by an attacker if they have access to server memory and/or network communications on the server's end (after tls is terminated), but secrets of offline users will still be secure, because even you don't have the key to decrypt them. This of course only works if you only need access to their api keys as long as they're present.