3

I am again trying to understand what is the best possible option to securely making the apex callouts from a trigger to external application which supports OAuth2. I am not building any application/package here. I am very new to Salesforce and the integration with external system, so pardon me if I am asking a very lame question. I am kind of stuck not able to understand what is the right choice for my scenario. The end point supports the grant type Client credentials

grant_type=client_credentials
client_id=clientId
client_secret=clientSecret
tenant_id=tenant_id
resource=resource

As a POC I was able to harcode all the credentials in Apex and I was able to call external system with out any issues. As this not secure I tried exploring the options mentioned https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets

  1. I tried to use the named credentials but found that grant_type client_credentials is not supported as asked in the question here
  2. I tried to create the Custom metadata type and stored the credentials like below enter image description here but looks like I cannot store the credentials like above as they are not very secure.
  3. Read that I could also use a Custom object with the encrypted field also having the FLS to store these credentials and use it APEX
  4. Custom settings - I am not sure if I can use the Custom settings as when I tried to create a it I see the warning message where salesforce recommending to use the Custom metadata type enter image description here

We dont have the platform encryption turned on in our ORg, should we enable that to created the encrypted fields on the Cutom metadta dattype/object/ settings encrypt it and when we reterive in apex should we be decrypting them? Please suggest me what is the best option to use here and also store the access token retrieved so I can use it until it expired.

  • platform encryption aka Shield is encryption at rest and won't help you here. – cropredy Jun 1 at 18:28
  • @cropredy Do you say even I encrypt the field it is not going to help? – user81642 Jun 1 at 18:50
  • There is field encryption which masks; there is shield encryption which doesn't mask. I was referencing the latter. I think best practice is protected custom metadata if named creds don't work. – cropredy Jun 1 at 19:06
  • 2
  • @identigral The question is not a repeating one. so I just reopened it. At first glance, it looked duplicate but it is not. – Mohith Shrivastava Jun 2 at 2:05
3

If you are not building a Managed package solution, there are a couple of ways you can secure the keys.

  • Use custom objects with a Private Sharing model. Keep OWD Private, this way no one will have access to it except System admin and owner of the record. You can further secure it using the encrypted fields (Note this will not need a shield license). Using Shield just for this may not be the best bet.
  • The second alternative is to use encryption before you store the Oauth Client Secret. You can again keep the Client Secret in an encrypted field and use apex to access it and decode.
| improve this answer | |
  • I was able to create the custom object with the encrypted fields and was able to use those in the Apex class. One last question, is it secure that I can store the access_token and expiration retrieved into a encrypted field into same custom object and use them in subsequent calls? – user81642 Jun 1 at 21:26
  • 1
    Yes as long as you keep the org wise default to private. – Mohith Shrivastava Jun 1 at 21:27
  • I just raed in the developer.salesforce.com/page/Secure_Coding_Storing_Secrets on Encrypted Custom fields and it is mentioned that We do not recommend storing authentication data in encrypted custom fields, however these fields are suitable for storing other types of sensitive data (credit card information, social security numbers, etc). Shouldnt I be using the Custom fields for storing the Credentials? – user81642 Jun 2 at 19:37
  • 1
    @user81642 i still think encrypted fields are great candidate and you can obviously mix with the encryption key and use owd to limit access. Note that if you are concerned your data needs encryption at rest then shield comes which I think is overkill for this. I suggest you work with your IT team to figure this up – Mohith Shrivastava Jun 2 at 19:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.