Conga Composer Faces Scrutiny Over Salesforce Security Concerns

Conga Composer is under scrutiny in the Salesforce ecosystem after concerns were raised about how the product reportedly authenticates with Salesforce, prompting debate around legacy information patterns and modern security expectations.

The issue has sparked widespread discussion across the Salesforce community, with differing views on whether the behavior represents an unacceptable risk or more of an outdated design that is already being phased out. 

What Is Wrong With Conga Composer?

The discussion gained significant momentum after a LinkedIn post from Director of AutoRABIT, Pablo Gonzalez, quickly circulated. The post alleged that Conga Composer can, in certain scenarios, use a Salesforce Session ID to authenticate requests back to Salesforce rather than relying exclusively on OAuth.

A Salesforce session ID is a temporary token issued when a user logs in, allowing actions to be performed without repeated authentication.  Security best practices generally discourage passing session IDs to third-party vendors – especially when OAuth is there to provide stronger governance controls such as scoped access and auditing.

Pablo’s post argued that this mechanism bypasses Salesforce’s OAuth-based security model and could introduce risk, especially if session IDs are transmitted via URLs or handled without transparency. Pablo told his audience that their Salesforce orgs “may be at risk” if they use Conga Composer, later adding: “As someone who thinks about Salesforce security all day, this is deeply concerning.”

Screenshots from Conga’s own documentation were cited as evidence that session IDs could be passed to Conga services in some cases, intensifying concerns for security around the ecosystem.

Conga responded publicly to the claims, with Brian Farr, Vice President of Product Management at Conga, stating:

“At Conga, security and customer trust matter a lot to us. For Conga Composer, the recommended and standard way to connect to Salesforce is OAuth, which gives admins proper governance through connected apps and OAuth policies. 

“There are some legacy or optional Composer entry points that historically supported very specific, customer-driven use cases where a Salesforce session token could be supplied. That approach isn’t required for normal operation and isn’t something we recommend today. 

“When tokens are used in those scenarios, they’re handled only for the duration of the request. We don’t store Salesforce session tokens in permanent storage, and they’re protected in transit and while temporarily cached. 

“We also agree that putting sensitive tokens in a URL isn’t ideal, since URLs can show up in browser history or logs. That’s something we’re actively working to clean up as we modernize older flows and continue standardizing on OAuth-based authentication. 

“If anyone has questions about their specific setup or wants to double-check they’re using OAuth, our Support team can help.” 

SF Ben’s Technical Content Director, Peter Chittum, also supports Conga’s interpretation, acknowledging that while session IDs and OAuth tokens can both technically be used to access a Salesforce org, OAuth is the correct and expected approach today. 

Using session IDs reflects older Salesforce integration patterns that are now widely considered anti-patterns, but emphasized that Conga is clearly aware of this and is actively cleaning it up.

We have reached out to Salesforce and Conga for comment.

Final Thoughts

There is currently no evidence that Conga Composer has caused any immediate security threat to customers. However, the situation has highlighted how quickly legacy technical decisions can come under scrutiny as security expectations evolve.

For Salesforce customers, the key takeaway is understanding how third-party tools authenticate with their org and ensuring modern, well-governed methods like OAuth are being used.