function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
max_overloadmax_overload 

Consumer secret exchange (encryption best practices)

I have a general question for any security minded experts out there. Currently have a requirement to securely manage the exchange of a "secret" between a client application (generally exists in SFDC) and a known, trusted webservice. I'd like to validate that the subscriber (client) is valid using some method of secure authorization, then respond with an encrypted secret.

The secret will be used to unlock a document (in simple terms).

 

Looking for past experiences / best practices for doing this. I don't want to be dependent on subscriber orgId and session callback proxy to validate that the caller is valid if at all possible.

 

Example flow:
 
Client App (wants a secret to unlock a file) --> 
Calls a trusted web service (https) --> 
Needs to send the web service some kind of authorization package to get the secret -->
-->Authority receives something
 
# Is this a MAC? SHA256/512?
# Should this be a piece of encrypted data specific to the client (like a clientId which the Authority would know already??) using something like AES256 algorithm with a managed initialization vector and cipher block chaining??
# Should this be a unique digital signature (RSA/RSA-SHA1) for the clientId already known by the Authority that could be verified by using a shared private key?
 
-- Authority does something to validate that the Client application is authorized to receive the secret
<-- Authority sends the secret as an encrypted digest that the client "salt" can decrypt??
--> Client receives encrypted package, decrypts somehow (using managed IV with salt as private key?) and uses the "secret" to unlock the document.