Store password locally. Where? How to pass it securely?

The user enters login and a password, and this data goes to the server. How can I securely pass it? Should I use a secure protocol like https or ssl?

Yes! You need to pass the data in a security way, using TLS for example.

If the credentials are correct I need to save this data to the local machine. Should I use a local database file, a binary, or just a text file? Where to store this file? And I bet I need to encrypt this. Also I need to decrypt it later, but for decryption I need some additional data (some key, probably), right? Where to store this additional data?

You can generate a key instead of the password, so for example, in the authentication the server returns a KEY (random bits) save that in a database with the ID of the user, and you store that KEY localy, but in the server you know who that belongs to. Then, in the second login, you send that key to the server, that checks if its valid (belongs to that user) and not expired.

At some point I need to pass this information to another process. I already have tcp communication between processes established. Is this enough for passing? Should I pass it encrypted or decrypted.

Again, you pass only the key. You can encrypt, but its realy hard to avoid all the types of attacks your system may suffer.

HTTPS or a custom protocol using TLS for encryption is the correct way to securely communicate with a remote server, assuming you implement it correctly and exit if something isn't right with certificates (I've seen mobile apps that despite using HTTPS, accepted my self-signed certificate right away without even asking the user, making the whole "security" pointless).

Storing the credentials securely on the machine is a lot harder because if your app can decrypt them, so can malware running with the same privileges as your app - any protection would just be security by obscurity and won't stop a dedicated attacker, it may only protect against common "stealers" which are mainly designed to steal browser profiles (history, session cookies) or personal files (for possible identity theft) and won't steal the actual app binary so the attacker won't know how the saved credentials were encrypted, or even if he has the app's binary he may just not care because reverse-engineering is time consuming and requires experience (note that malware developers often aren't the ones who actually deploy them and collect/resell the stolen data).

You may derive a key from the hardware like pbkdf2(sha512(OSname+OSversion+CPUmodel+MACaddress)) and use that as a key to encrypt the credentials, which can be retrieved on the same machine but won't benefit an attacker if he only stole the encrypted credentials and the app's binary unless he has still access to the machine to go back and get that same value

There is no need to use encryption for inter-process communication on the same machine, if an attacker can intercept that communication he already has control of the machine (at the same privilege level that the app uses, if not higher) which means you can read what I said above about not being able to defend against that.