Call Salesforce API from Apex and not fail Security Review

Question

For years I have used Salesforce APIs from within Apex. Mostly to enhance my apps with Setup automation. So I used the Tooling and Metadata API from code snippets that used UserInfo.getSessionId() and looked like that:

private HTTPResponse createSObject(String fragment) {
    HttpRequest request = new HttpRequest();

    request.setEndpoint(URL.getOrgDomainUrl().toExternalForm() + '/services/Soap/u/53.0');
    request.setMethod('POST');
    request.setHeader('Content-Type', 'text/xml; charset=UTF-8');
    request.setHeader('SOAPAction', 'ignored');
    request.setBody('<?xml version="1.0" encoding="UTF-8"?>.... 
                     <sessionId>' + UserInfo.getSessionId() + '</sessionId>');

    return new Http().send(request);
}

Also, many other well-known, widely used OSS libraries use this approach. The best example is the Apex Metadata API from Andy Fawcett.

Now a former customer and apparently many other long-time ISV partners, failed a Security Review with similar code:

Unauthorized use of SessionID

Please use OAuth, (try JWT flows and look into admin pre-authorization). Do not touch user credentials in a managed package.

I have no clue what they want. Add a Connected App, Named Credential, and a ton of other metadata for a simple API loopback.

Please advise how to do it right.

Answer 1

The OAuth flow we used for our AppExchange app is Web Server Flow for Web App Integration. There are various types of flows that can be used as per your requirements; we used Web Server Flow for Web App Integration.

1. Once the subscriber installs the application in Salesforce, it lands on a custom app's screen where they are asked to authorize themselves; they click on a button that redirects the user to the login page, and the OAuth flow kicks in.
2. After providing login details, the user sees the app permission screen.
3. Users can review these permissions and allow or deny them.
4. Once they allow, Salesforce OAuth flow grants an authorization code in the callback URL
5. Based on this authorization code, we can request an access token
6. Now, the app's logic can use this access token to make various API calls to Salesforce services like tooling API, metadata API, etc
7. This access token has a scope per the permissions selected on connected app settings.

Answer 2

This solution passed Security Review

TL;DR

Our final decision was:

• Connected App created on client's Partner Business Org (PBO)
• Make it Pre-authorized by Admins + JWT Token flow
• Custom Metadata + UI to store secret key for JWT

Intro / Problem description

Our team had to analyze potential solutions which will be:

• secure & controlled by Admins of the Orgs,
• possibly invisible to the end users.

The solution is a Connected App, but what exactly does it mean?

Connected App allows us to control connections from External App to our Salesforce Org resources. It uses scopes, OAuth policies, IP ranges and other parameters to limit unwanted traffic and operations. Admins can verify and give/revoke/monitor access at any time.

Following question - which OAuth Flow to use?

• Web Server Flow

  • each user needs to authenticate via browser,
  • authorization code needs to be retrieved (callback URI),
  • refresh token needs to be stored safely per user,

• JWT Bearer Token Flow

  • no user interaction is needed,
  • admin needs to authorize the App.

The assumption was to make it invisible to the users, therefore, we chose JWT Bearer Token, although it's designed to handle Server-to-Server integration.

But there was another question to be answered - should we use a central Connected App created on our Partner PBO or create a new Connected App for each customer using this package?

Packaged Connected App:

• Connected App is installed with the package,

• manuals steps - client id, client secret and certificate private key are created by customer's Admin,

• OAuth policies can be set by the customer and adjusted in the first go,

• new UI/instructions must be provided to store the client id, secret and private key in Custom Metadata to be used in the code.

Central Connected App:

• Admin can install the Connected App on their org to use it and to manage the OAuth policies (self-authorization vs. pre-authorization; assigning profiles, permission sets etc. for pre-authorization),

• client id, client secret and certificate private key are distributed in the app

• a limited number of manual steps - required one is Admin approval

Create a Connected App for each customer:

• customer Admin needs to create a new Connected App based on provided instructions,

• client id, client secret and certificate private key are created per customer (with Connected App),

• OAuth policies are set by the customer and adjusted in the first go,

• new UI/instructions must be provided to store the client id, secret and private key in Custom Metadata to be used in the code.

We finally decided to move on with the last option as it seems more secure and we had problems with packaging the Connected App. It passed Security Review. However, after some research we prefer the Packaged Connected App, as this requires less manual steps for Admins.

Answer 3

Solutions

We have been working towards a few solutions here:

A. Named Credentials & Auth. Provider Setup per Org

Auth. Provider specifies a url, and a named credential specifies the URL of a callout endpoint and authentication parameters for a user in one definition. This will take a customer about 10 minutes to setup and one account to operate as a sort of "System Account" to perform all interactions with the REST API. Note that if this account is deactivated, then user will be blocked from using the functionality that relies upon it.

B. Oauth Consent Flow per Org

Alternative route that involves creating a connected app in each customer environment. In this connected app, we provide a callback url to the VisualForce page. In this example, the user must actively participate in an Oauth Consent flow.

Additional Comments

This has been impacting us significantly as well. We have 2 packages which have faced this issue either by UserInfo.getSessionId() or !$Api.Session_ID.

We have built up a lot of great functionality that leverages REST API, Tooling API, UI API, Metadata API, etc.

After a lot of experimentation from our team, we have found that when our 150+ customers upgrade our package, they will have to create some form of metadata involving connected apps, named credentials, auth. providers, etc.

This setup is something that will be error prone, and frankly hard to explain to customers (as evidenced by the discussion in this thread). If it's not setup correctly, mission critical functionality they have been relying upon for 6+ years will stop working with no workaround in the name of security.

Also, throwing open an Oauth flow in our application after our users already authenticated could be negatively perceived by our user base and will likely raise more security concern. "I just authenticated, as i've always done, why do I need to do this again? Is this legit or am I being hacked?"

Alternatively, with a named credential approach, we will lose some audit tracking on the named user (fixed one security problem but created a data integrity one instead that is significantly more important to our customers).

These mitigations are too disruptive in nature.

Salesforce has made great strides in REST API usage over the past few years (adjusting REST API daily limits, UI API, Composite API, Composite Graph API, GraphQL support, etc.). We have embraced these new capabilities and delivered value to our customers with it, which has allowed us to mutually grow with Salesforce. This new enforcement feels like the rug being pulled out from beneath us with, from my point of view, no equivalent alternative and an under-appreciated impact to the user experience.

In the short term, I believe this should be reconsidered as an enforcement, in the long term, we need some alternative without such technical lift.

Many fantastic new features are first accessible via REST API. It feels like a significant gap that we need to leverage Session Id in the first place to access these resources for code that is already running in the instance.

It would be great to if Salesforce can prioritize solutions of how all of these resources could be exposed for us to call from within Salesforce (In Apex or even LWC), where the authentication is taken out of our hands (similar to how it works with Salesforce Functions).

I don't want to add architectural complexities to our package so that I can use UserInfo.getSessionId, I want to not have to use it at all...

Answer 4

This is part of the JWT Token Client code from my PoC.

This code uses a Named Certificate. This is great for testing in unmanaged code. I'd need to find another way of providing the certificate from Protected Custom Metadata. The certificate would be company proprietary and must be kept secure.

This idea (Package Certificate Idea) suggests that what using Managed Certificates is not possible. No certificate, no use of the Auth.JWS class. I can manually build a JWT and manually create the signature using the Crypto classes, but it's messier to do.

This code could be usable in a managed package if each Org created their own Connected App and provided the Certificate and Client ID through settings. That sounds horrific though.

    // This may be test.salesforce.com
    String tokenEndpoint = 'https://login.salesforce.com/services/oauth2/token';

    Auth.JWT claims = new Auth.JWT();
    claims.setAud(tokenAudience);
    claims.setIss(settings.OAuthClientId__c);
    claims.setSub(UserInfo.getUserName());
    claims.setAdditionalClaims(new Map<String, Object>{ 'scope' => 'api' });

    Auth.JWS token = new Auth.JWS(claims, settings.OAuthCertificateName__c);
    String tokenString = token.getCompactSerialization();

    Auth.JWTBearerTokenExchange bearer = new Auth.JWTBearerTokenExchange(tokenEndpoint, token);

    return bearer.getAccessToken();

Further to Robert's answer I have tried to create a Web Flow.

I have manually invoked this

https://builder-sagittarius-3050-dev-ed.scratch.my.salesforce.com/services/oauth2/authorize?response_type=code&client_id=REDACTED&redirect_uri=https%3A%2F%2Ftest.salesforce.com%2Fapex%2FRCTest

The OAuth grant was fine, but I am (as requested) redirected to the login page and asked to log in again. I enter my username and password (which is ugly as part of an oAuth flow) and am directed to the VF Page with a code parameter.

Second time in my oAuth grant was automatic and I appeared straight at the login page. So even if the app is granted then the user has to log in every time a token is requested.

Answer 5

IMHO You need to create a connected App inside the managed package; better if you use a certificate and enable the Oauth flows. then implement the JWT bearer flow to get a new access token previous (you can use the platform cache to store it for a while) and call the metadata API

Why do you need to do this?

You have created a managed package that is doing metadata changes on the user's behalf (that is because you are using the SessionId). There is no way to track that changes were done by a 3rd party app(your package) with the user's approval. That is the purpose of creating a connected App

Answer 6

Since first looking at this I have been developing approaches that we can use to solve this problem. Two such processes have been JWT and Web Flow.

Salesforce suggested a JWT based solution using a single master key which is stored in the developer's packaging org. I have shied away from this because, no matter how good our internal security is and no matter how much we limit who can access our packaging orgs, the thought of a Single Master Key that can access all customer orgs from anywhere on the Internet and be used to act as an administrator on those Orgs is just too scary to contemplate.

My JWT solution uses a local key installed and controlled by the administrator. This takes the key out of our control, and therefore removes the non-repudiation aspect of using keys, but it gives a simple to implement means of continuing to access the auth while satisfying the requirement of using a Connected App. It brings the cost of an extra post-install admin task. So this is the solution for "We have to get this in fast with minimal code change"

The other solution is to use a Web Flow. My web flow uses a very simple server sitting somewhere external. My sample code (linked below) is an Express server, but a production system would of course look at more production ready solutions. The sample is designed to be easy to deploy and explore.

The Web Flow brings the advantage that it is far more user friendly and it offers the Salesforce admin the control they desire. The sample explores a couple of different questions, and does not really reflect our final solution.

• Do we use Refresh Tokens to allow access at any time? The sample can but a final solution may choose not to.
• What happens if we need to store lots of user tokens? A solution is provided for discussion. I have found that we don't need this in our situation. I believe this solution is secure, but have not taken it to Security Review.

The code samples are here:

https://github.com/financialforcedev/mdapi-oauth-demo