Hey Nathan. In basis is this a construction you need to avoid.
Hashing is a technic that will 'transform' the value, but it isn't possible to get the original value back. This is ideal for login functionality, Mendix uses hashing for the login, because the same input value will always give the same hashed value. This way you can control if the password is correct. Hashing is available as function in the community commons module. So hashing is something you cannot use or the third party need to change to accept hashed values to validate the login.
Encryption is a more suitable technic, because you can encrypt the password and with the REST call you can decrypt the value and send the plain password with the REST call. In the appstore you can use the Encryption module. Encryption is less secure than hashing, because everyone who now the ecryption key can get all passwords if your entity access isn't right. To minimize the security risk no one should be able to have read rights on the password attribute and the password attribute can only be updated with the usage of a non-persistent entity.
Why do you need to avoid this construction? To realise the solution you need to ask the user to give their credentials and store this in the database locally. I don't know the possibility of the third party solution, but you need to get standard authentication credetials and give the username with each REST call to give the context the functionality needs to be executed or the user needs to login manual in the third party and your application will get a token to execute all calls (a token has in basic a short lifetime)
Ik hope this will give you some input!