2

I'm trying to integrate with an external system using Authentication provider and Named credential. For this, I've created an Auth. provider with just Auth URL, Callback URL and a plugin class. Client Id and secret remain empty since only username and password give me the access token.

The plugin class does all the work in handleCallback() method by passing username/password params in http POST request body to return the access token and refresh token. Exactly similar to this.

The named credential along with external credential (OAuth 2.0 protocol and Browser flow authentication type) leverages the Auth provider. And, then this named credential is used to do the callouts.

Everything works fine, I'm able to do various callouts using the named credential, and access token generation is automatically handled by Salesforce, but the challenge is that I'm storing the client username and password in this plugin class which I want to avoid. Could anyone suggest best way to handle this?

I want Salesforce to internally handle the access token generation (through my plugin class, which is happening now) and also store client credentials safely. Is there something very straightforward solution that I'm probably missing?

Few things to note:

  1. I tried creating external credential with "Custom" protocol -> added new principal of "Named Principal" type -> and stored username and password in authentication parameters. The problem here I faced was that I had to explicitly hit the token endpoint url from Apex using this named credential and store the token in some variable, and then use it for my further actual callouts. This somehow defeats the purpose of having named credentials since I'm handling access token fetching logic everytime while doing actual callouts.
  2. External Credential with "Basic Authentication" is not even possible because I'll have to rely on custom body with merge fields in Apex to get the access token (similar to point 1.)
9
  • and store the token in some variable, and then use it for my further actual callouts - what stops you from using Named/External Credential for these further callouts.
    – identigral
    Commented Apr 26 at 14:14
  • thanks @identigral! I can use named/external cred for these callouts, but the problem I'm having is that I first do the access token callout, store the access token myself, and then I the actual callout. I wanted to avoid this.
    – sfdcnewbie
    Commented Apr 26 at 14:17
  • If you associate Named Credential with External Credential, you can avoid that. See salesforce.stackexchange.com/questions/409484/… as an example. The help doc on API keys with NC/EC is also an example of this technique.
    – identigral
    Commented Apr 26 at 14:20
  • @identigral Maybe I'm missing your point here, but as for the first link, I don't have any Client ID/secret (as mentioned in my question). Also as for the second link, as mentioned in my note, I have to form custom body with merged fields using API keys in Apex to generate access token (I don't see "Custom Body" option like we have Custom Header in external cred)
    – sfdcnewbie
    Commented Apr 26 at 14:30
  • 1
    You're already writing Apex in your custom plugin. You can't avoid doing Apex if your request is not standard oAuth (requires some custom body and merging parameters).
    – identigral
    Commented Apr 26 at 14:45

1 Answer 1

0

Answering my own question:

I ended up encrypting the credentials and storing them in the custom metadata record linked to the Auth. provider. There seems to be no way of achieving this when it comes to custom OAuth:

  1. Issuing of Access token internally handled by Salesforce
  2. Storing of credentials in API keys

Either we have to write custom code to handle access token and store creds in API keys
OR
Write custom code to use credentials and get access token in plugin class and let Salesforce handle issuance part.

You must log in to answer this question.

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