Using hashed string from data base in REST API calls

I've been asked to integrate a third party in a Mendix app, but the bearer token is based on the users' login credentials for said third party. I have no clue on how to securely make the call. I need the user to fill in their login credentials, of which the password I should save as a hashed string I guess? But when I want to make the REST call, I want to retrieve the password from the database in order to use it in the HTTP authentication header, but this field does not support hashed strings and there is no unhash function either.  How do I solve this? Do I just not hash the string? Is this secure?  Help me out please.  
1 answers

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!