If you need to log into a foreign account of someone else, you need his username and password. There's no way around that. You can't hash or encrypt1 them, you need the plain values.
Of course that's a nightmare, as the users need to disclose their credentials to you. They trust that you're not abusing them. Assuming that you are not intentionally abusing them (like selling them on the black market as a part of your business model), you need to prevent leakage. That includes data breaches in your infrastructure or database admins being able to access them. So the best practice here would to not store them at all. Your companies business is to help the user with filling out forms, not providing a password manager service. To "make it easier for [the users] to remember" their credentials is not your job.
One solution might be to write a browser extension for your users to install. They log into those foreign account themselves, on their machine, and your plugin does its work there. Your server does never even come into contact with the credentials. (Of course the user still needs to trust the extension not to spy on them).
If that's not an option and the work, including the login, needs to be done at your server, then you still should not store the user credentials. Just forward them to the foreign login service, and then only store the session token that is to be used with the API in your database for as long as you need it. If the database is breached, the attacker might be able to hijack the sessions (worse enough), but he does not get the plaintext password. Have the user provide the credentials again if your server needs to login multiple times.
1: Of course you should always encrypt any sensitive data when storing it anywhere, but ultimately the key to it has to reside somewhere on your server, to which a presumed attacker might gain access as well.