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


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, 2020 at 18:28
  • @cropredy Do you say even I encrypt the field it is not going to help?
    – user81642
    Jun 1, 2020 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, 2020 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. Jun 2, 2020 at 2:05

2 Answers 2


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.
  • 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, 2020 at 21:26
  • 1
    Yes as long as you keep the org wise default to private. Jun 1, 2020 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, 2020 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 Jun 2, 2020 at 19:41

With Winter '23 the preferred approach would be to (safely) store your secrets as 'External Credentials' using the re-architected Named Credentials architecture.

See: https://developer.salesforce.com/blogs/2022/10/announcing-the-next-generation-of-named-credentials

And these exquisite examples from https://github.com/rossbelmont/named-creds-api-key

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .