2

What would be the best place to store access token and similar data in a Salesforce application? My apex class retrieves some data which is used for client authorization on some external API (it doesn't use OAuth2 or any standardized protocol, it has some custom protocol) and I need to keep it somewhere.

I was considering Session Cache, but it is only supported in Enterprise and Unlimited and Performance editions.

Improve this question
1

Your best choice outside of Named Credentials would be to store the token in a Custom Setting. Make sure that the field is encrypted using best practices so that the session can't be hijacked by users with sufficient access to see the token. Session Cache is a poor choice anyways, because it can be invalidated at any time, so you might end up needing to arbitrarily login again.

Edit: List Custom Settings have been deprecated. One might consider using Custom Metadata Types, which allows you to create a field that supports more than 255 characters for systems that have really long tokens.

Improve this answer
  • 1
    A big issue here is that its not possible to store a token that is longer that 255 chars :( – utm Apr 12 '19 at 18:06
  • char count on Marketing Cloud token I tried to save using this method was 306 – Cleverlemming Jun 12 '19 at 3:36
  • @Cleverlemming This is a relatively old answer. An updated version would say that Custom Metadata would probably be more appropriate; you can create a field that supports up to 131kb worth of text, easily large enough to handle practically any token. – sfdcfox Jun 12 '19 at 12:49
  • 2
    checked into custom metadata types and SF recommends not using them (or custom settings) for auth tokens outside of a managed package (developer.salesforce.com/docs/atlas.en-us.apexcode.meta/…). The following suggestion would make life easier: success.salesforce.com/ideaView?id=0873A0000003apqQAA. (@sfdcfox's extended discussion of token storage is useful: salesforce.stackexchange.com/questions/149921/…) – Cleverlemming Jun 12 '19 at 21:27
  • @Cleverlemming True enough. Thanks for the idea suggestion. As far as storing secrets, they should definitely be encrypted if this is your only option, as it is non-trivial for normal users to get access to the necessary key material to decipher the data. Until/unless we have a better solution (NC would definitely be ideal), we have to work with what we have. – sfdcfox Jun 12 '19 at 21:34

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.