Avoiding exposing sensitive information in class

Question

I've to call a rest API(Class exposed as rest resource in the same org) from Batch class.

For that I've get session Id for authenticaiton

I'm using SOAP API Login method to get Session ID which In turn, I use in my Rest API call for authentication as shown below

req.setHeader('Authorization', 'OAuth ' + userSessionId);

Issue is : for SOAP API Call to generate session ID, I've to store Username and password in batch class or somewher in salesforce(probably Custom setting etc). I'm pretty issue- it is not right practice to store passwords in such a way.

On further researching, I found this thread which provide guidlines how to store sensitive information. I'm thinking to use crypto class but would like to know if there is any easy/simpler way out there.

I'm also thinking probably another way as to use 'OAuth Token' for authentication. For which I've to create connected APP to get client ID and Client Secret. This could avoid username and password totally and therefor no need to encyrpt anything Would that be fine and effecive?

Please suggest what would work best in such scenarios.

Thanks!

Answer 1

The OAuth 2.0 JWT Bearer Token Flow allows a session ID to be obtained for a user based on a certificate shared by the client and the authorization server. Unlike most other OAuth 2.0 flows, no password is needed. This avoids having to prompt for a password in a browser or having to have a stored password. So the flow works well for server to server interactions.

I've posted some Apex code that supports this flow here An Apex implementation of the OAuth 2.0 JWT Bearer Token Flow.

PS If you are making the call to your own org and are happy that the call should use your User then you can just use your current session obtained from ID from UserInfo.getSessionId().

Answer 2

The best way to store secure credentials is to create a managed package in a dev org that contains a protected custom settings object for your credentials, as well as a global class and method to set these credentials either from anonymous apex or a visualforce page. Protected custom settings are completely invisible from outside the package, only an apex method within the package would be allowed to access the settings in code. You would then upload a managed release of the package and install into your org.

The reason that this is recommended over a custom setting (not in a managed package) in your own org is because any user with View Setup and Configuration (a relatively common perm) can view custom settings records.

An alternative would be a custom object with encrypted fields but there are a few more minor security holes in this approach, not to mention that you have to burn a SOQL to retrieve, than the managed package route.