You don't really describe this step very well:
If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database.
Exactly how is that 128-bit key created? That should be a very slow process, otherwise you are providing a side-channel to brute-force user passwords. The way it would work is an attacker gets their hands on your database. Rather than try to brute force the bcrypt hashes, which would be very time consuming, they get to work on the encrypted passwords. They simply brute-force the user password to get keys that appear to work (ie: the decrypted text looks like passwords, whatever that means). This will be a fast attack because encryption is fast.
You need to make the 128-bit key creation a slow process. The best way to do this is probably to use bcrypt. But, as you have probably figured out, you don't want to use the bcrypt value that you've stored in the DB for authentication as that would not be a safe way to store encryption keys. I suggest that you keep a second salt for each user. You then use that salt, plus their clear-text password, in a call to bcrypt to generate the 128-bit encryption key.
When a user changes passwords, you should either wipe or reencrypt all of the encrypted passwords. This is needed because users frequently change passwords when they are concerned that their password has been compromised. So you better wipe the data that was encrypted with the compromised password. Though this, of course, won't help if the attacker already got a copy of the database before the password change.
Another security measure you could add is to pepper (search for "pepper" in this answer) the encryption key. The pepper should be a truly random bit string (no, your cat's name doesn't qualify) that you store someplace else. That is, it is not in the database. Use of a pepper will prevent an attacker who gets both a copy of your database and a user's password, from decrypting the user's data as they will still need the pepper. Remember that a pepper is only as helpful as it is secure. Putting it in your source repo is probably a bad idea.