Document generation tools like Conga Composer sit in a strange position inside a Salesforce org. They need enough access to pull opportunity, quote and account data into a merge template, but they typically live outside Salesforce’s own trust boundary, running as a browser extension or an external merge server. That gap between “needs data” and “isn’t actually part of Salesforce” is exactly where session ID based authentication becomes a liability, and where OAuth earns its place as the default.
Understanding the Session ID Risk in Conga Composer Integrations
Older Conga Composer configurations authenticate API calls using the current user’s Salesforce session ID rather than a dedicated credential. The session ID is the same token Salesforce issues when a user logs into the browser UI. It is meant to authenticate that one browser tab for that one session, not to be handed to a third party as a standing API credential. When Composer’s merge server receives that session ID, either through a URL parameter or a hidden form field, it is effectively holding a copy of the user’s live login for as long as that session remains valid.
The practical risk is not theoretical. A session ID transmitted this way can end up in browser history, in proxy or load balancer logs, in error tracking tools that capture full request URLs, or in the developer console during debugging. Anyone who obtains a valid, unexpired session ID can replay it against the Salesforce API and act with the same permissions as the original user, with no additional authentication step and no way for Salesforce to tell the difference between the real user and the replay. Salesforce’s own session security settings, covered in the Salesforce Help documentation, describe several of these controls, including binding sessions to the originating IP range and forcing relogin after certain events, but none of those controls change the underlying fact that a session ID is a broad, unscoped credential rather than a purpose built one.
Composer’s design choice to reuse session IDs for merge and document generation calls made sense historically, before OAuth 2.0 became the standard integration pattern across the Salesforce ecosystem. It avoided a separate authentication step for the user. The tradeoff is that every Composer call inherits the full scope of whatever the logged in user can see and do, rather than being limited to the specific objects a document merge actually needs, such as read access to a quote and its line items.
Why OAuth Replaces Session ID Authentication
OAuth 2.0, the authorisation framework defined in IETF RFC 6749, separates “who is logged in” from “what this specific integration is allowed to do.” Instead of forwarding a live session ID, an OAuth based integration registers as a Connected App inside Salesforce, requests specific scopes, and receives its own short lived access token once a user has explicitly approved the request. That distinction matters because it changes what happens when a credential leaks.
Under the session ID model, the flow looks like this: the browser holds a live session ID for the logged in user; that session ID gets sent to the vendor’s merge server as a bearer credential; the vendor server then calls the Salesforce API using the borrowed session ID; and the credential stays valid until the user logs out or the session naturally expires, with no scope restriction on what it can touch in the meantime. Under the OAuth model, the flow is different at every step: the Connected App requests access rather than borrowing an existing session; the user approves that request once through a consent screen; Salesforce issues a scoped access token plus a refresh token tied to that specific app; and the vendor’s server can only call the API within the scope it was granted, with the access token expiring quickly and remaining revocable from Setup at any time, independent of whether the user is still logged in.
That last point is the one most teams underrate. Revoking a leaked session ID usually means forcing the affected user to log out, which disrupts their whole working session. Revoking an OAuth token for a specific Connected App is a single administrative action in Salesforce Setup, under Connected Apps OAuth Usage, and it does not touch the user’s own login at all. The blast radius of a compromised credential shrinks from “everything this user can see” to “whatever this one integration was scoped for.”
How to Migrate a Connected App from Session IDs to OAuth
Migrating Conga Composer, or any comparable document generation or reporting tool, off session ID authentication is a scoped project rather than a single toggle. It touches Salesforce configuration, vendor configuration, and a testing window where both paths need to keep working for existing users.
Registering the Connected App and Defining Scopes
Start in Salesforce Setup under App Manager and create a new Connected App with OAuth settings enabled. Define the callback URL the vendor’s server will use, then select scopes deliberately rather than accepting the defaults. A merge tool that only needs to read quote and account data should request scopes such as api and refresh_token, not full, which grants broad access equivalent to whatever the authorising user can do across the whole org. The refresh_token scope matters specifically because it lets the vendor request a new access token without prompting the user again, avoiding a fallback to less secure workarounds once the short lived access token expires. Under Manage Connected Apps, set the OAuth policy to “Admin approved users are pre-authorized” and assign it through a permission set, rather than leaving it open to any user who happens to click through the consent screen, so access stays auditable at the org level.
Rotating Off Legacy Session Calls Without Breaking Document Generation
Once the Connected App exists, the vendor side of the configuration needs to switch its authentication method from session ID passthrough to the OAuth authorisation flow, which for a server side tool like Composer usually means the web server flow with a stored refresh token rather than a flow that depends on the browser. Run both paths in parallel for a defined cutover window, routing a small subset of merge templates through the new OAuth connection first, and compare successful merges, error rates, and API call volumes between the two. Once the OAuth path is stable, disable the legacy session based configuration option inside Composer’s own admin settings, then confirm through Salesforce’s API usage logs that no further calls are arriving tagged against the old session based method. Leaving the old path enabled “just in case” defeats the point of the migration, because any browser extension or logging tool that still captures session IDs remains a live exposure until that switch is fully off.
Hardening Salesforce Beyond OAuth Adoption
OAuth adoption closes the specific session ID exposure path, but it is not the only control worth having in place around third party integrations. Session settings in Salesforce Setup, under Session Settings, can lock sessions to the originating IP range and enforce a maximum session length, which reduces how long any leaked credential, session based or otherwise, stays usable. Transport Layer Security should be enforced on every outbound call so that tokens cannot be intercepted in transit, and a Content Security Policy on any Salesforce hosted pages that embed third party scripts limits where those scripts are permitted to send data.
Salesforce Shield’s event monitoring and transaction security features add a detection layer on top of prevention. Event monitoring logs API call patterns per user and per Connected App, which makes it possible to spot a token being used from an unfamiliar IP range or at a volume that does not match the vendor’s normal merge activity. Transaction security policies can then act on those patterns automatically, for example blocking or flagging API activity that falls outside an expected pattern for a given Connected App. None of this replaces OAuth as the underlying authentication model, but it gives an administrator visibility into how a given token is actually being used once it has been issued, which a bare session ID model does not offer in the same structured way.
A monthly connected app audit closes the loop. Review every Connected App listed under Setup, check which ones still show session based usage patterns rather than proper OAuth grants, confirm scopes still match what each integration actually needs, and remove any Connected App that has not made an API call in the last audit period. Integrations accumulate over time as teams trial new tools, and an unused Connected App with a live refresh token is exactly the kind of forgotten access path that turns up in a security review months later.
Compliance and Vendor Risk Management for SaaS Teams
For SaaS and FinTech teams operating under frameworks like SOC 2 or UK GDPR, the authentication model behind a Salesforce integration is not a purely technical detail, it is part of what an auditor or a data protection assessment will ask about. UK GDPR’s accountability principle, summarised in the ICO’s guidance for organisations, expects organisations to be able to demonstrate that access to personal data is controlled and traceable, not just that a breach has not happened yet. A Connected App with defined scopes and a revocation path is a much easier thing to demonstrate control over than a session ID that could theoretically be sitting in a log file somewhere.
Vendor risk reviews should treat authentication method as a specific line item before any contract is signed, alongside the usual data processing and subprocessor questions. Ask a prospective vendor directly whether their Salesforce integration uses OAuth with scoped Connected App access, or whether it still relies on a session based or credential sharing pattern. Salesforce’s AppExchange Security Review process, and the Connected App risk scoring visible in Setup, both give a concrete reference point for that conversation rather than relying on a vendor’s own marketing claims. Third party monitoring platforms such as Drata or Secureframe can also continuously check that connected integrations still match an organisation’s approved authentication policy, flagging drift if a vendor silently reverts to a less secure method after a product update.
Equanax has recorded an 86 percent reduction in fixable sync errors across the RevOps and CRM environments it has worked on. Tightening authentication scope on third party integrations is one of the general mechanisms that tends to reduce that category of error, alongside cleaner field mapping and validation rules, though the two are separate points rather than one causing the other.
Getting this right is a shared responsibility between Salesforce administrators, security, and the RevOps or sales operations team that actually owns the tools in question. RevOps teams are often the ones who first request a new Salesforce integration for quoting or reporting, which puts them in a good position to insist on OAuth as a baseline requirement rather than treating it as something security bolts on afterwards. Trailhead’s Security Basics module is a reasonable starting point for a RevOps team that wants to understand the underlying Salesforce access model well enough to ask vendors the right questions during evaluation.
Related Reading
Frequently Asked Questions
What exactly is exposed when Conga Composer uses a Salesforce session ID instead of OAuth?
The user’s live session ID gets forwarded to Composer’s merge server as a bearer credential. Anyone who obtains that session ID before it expires, whether through a logged request URL, a proxy log, or a browser developer console trace, can replay it against the Salesforce API with the same access as the original user, with no scope limit and no separate authentication check.
Does moving to OAuth mean Conga Composer stops working the way users expect?
No, but it does change how it authenticates behind the scenes. Users approve access once through a consent screen when the Connected App is set up, and after that the integration runs on scoped access and refresh tokens rather than the user’s browser session, so day to day document merging continues without the user needing to reauthenticate constantly.
What Connected App scopes should a document generation vendor actually request?
Only the scopes the integration genuinely needs, typically api for data access and refresh_token so it can renew its access without a full scope grant like full, which grants access equivalent to whatever the authorising user can do across the org. Reviewing requested scopes against what the vendor’s use case actually requires is a core part of applying least privilege to a Connected App.
How is Salesforce Shield different from OAuth for this problem?
OAuth controls how an integration authenticates and what scope it is granted in the first place. Salesforce Shield’s event monitoring and transaction security features sit on top of that, giving administrators visibility into how a token is actually being used afterwards, including flagging unusual API call patterns tied to a specific Connected App.
Do compliance frameworks like SOC 2 or GDPR actually require OAuth specifically?
Neither framework names OAuth directly, but both expect demonstrable, traceable control over access to personal data. A Connected App with defined scopes and a clear revocation path is far easier to evidence during an audit or data protection assessment than a session ID that could theoretically persist in a log file with no defined expiry or scope.
For more on this, see the Salesforce archive, including Automate PandaDoc Salesforce Quote-to-Contract Sync, Automating Salesforce Reporting with n8n and Google Data Studio, and Automate Salesforce Quote-to-Contract Workflow with n8n for RevOps Efficiency.
Leave a Reply