Every integration between two SaaS applications is a standing credential, and the choice between connecting apps directly and routing them through an integration platform decides whether those credentials are scattered across dozens of vendors or concentrated in one place. Direct SaaS-to-SaaS integrations leave OAuth grants and API keys in each connected vendor's infrastructure, outside your direct control and often outside your inventory. An integration platform as a service (iPaaS) pulls those credentials into one connection store you administer, which improves visibility but creates a single high-value target. This guide compares the two architectures on token concentration, blast radius, visibility, offboarding and failure modes, then sets out controls for each and a way to decide. It is for SaaS security, identity and integration platform owners. For hardening a platform you already run see Securing the iPaaS and integration platform itself; for periodic review use the SaaS and OAuth Integrations Health Check.
Key takeaways
- The real question is where the tokens live. Direct integrations store refresh tokens and keys with each third-party vendor; an iPaaS stores them in one connection store under your administration.
- Blast radius differs in shape, not just size. A compromised direct integration vendor exposes every customer tenant it connects to; a compromised iPaaS tenant exposes every system your organisation connected through it.
- Visibility is easier with an iPaaS, but only for what goes through it. Direct grants made by users through consent screens bypass the platform entirely, so you still need SaaS-side discovery.
- Offboarding fails differently. Direct grants are orphaned when the person who consented leaves; iPaaS connections are orphaned when the flow is abandoned but the connection is kept.
- Controls must follow the token. Least-scope grants, dedicated integration users, rehearsed revocation and data-movement logging apply to both, implemented in different places.
The short answer
Use direct SaaS-to-SaaS integrations when the pair is simple, the vendor offers a well-scoped native connector, and the data flow is stable. Use an iPaaS when you have many integrations, need transformation or orchestration, or want central inventory, change control and logging for integration credentials. Most organisations run both: the decision is which integrations to route through the platform, and how to govern the ones that stay direct. Whatever the split, treat each integration as a non-human identity with an owner, a scope, an expiry and a revocation path. See the SaaS OAuth App Governance Guide for the governance model.
Side-by-side comparison
| Dimension | Direct SaaS-to-SaaS integration | iPaaS-mediated integration |
|---|---|---|
| Where credentials live | In the connected vendor's infrastructure (the app holding the grant) | In the iPaaS connection store, administered by your team, operated by the platform provider |
| Who creates the grant | Often an end user or app admin through a consent screen | A platform builder or connection owner |
| Token concentration | Scattered: one or a few grants per vendor, many vendors | Concentrated: many grants in one tenant |
| Blast radius of provider compromise | All customers of that vendor, for the scopes that vendor holds | All systems connected through your tenant, if the platform or tenant is compromised |
| Inventory source | Each SaaS app's connected apps or consent records | The platform's connection list, plus SaaS-side records |
| Change control | Vendor-defined; you see a consent event, not the logic | Your flows, environments and promotion process |
| Logging of data movement | SaaS-side API audit logs only, where available | Platform run history plus SaaS-side logs |
| Offboarding risk | Grant persists after the consenting user leaves | Connection persists after the flow is retired |
| Third-party risk scope | Many small vendor assessments | One critical vendor assessment plus connected apps |
Direct SaaS-to-SaaS integrations in depth
Threat model and architecture
A user or administrator in application A authorises application B, usually through OAuth. B's back end stores an access token and a refresh token, or an API key, and calls A's API on a schedule or when events occur. Your organisation never holds the credential; B does, alongside the same credentials for every other customer. An attacker who reaches B's credential store can replay tokens against every connected tenant. MITRE ATT&CK describes the theft and use of such tokens as T1528 Steal Application Access Token and T1550.001 Application Access Token, and the registration of a malicious integration as persistence under T1671 Cloud Application Integration. See the MITRE ATT&CK T1671 Cloud Application Integration guide.
Failure modes
- Vendor-side token theft: in the Salesloft Drift breach, OAuth access and refresh tokens held for a chatbot integration were used to export Salesforce data from many customer tenants. The lesson for customers is that the scope you granted defines what can be taken.
- Over-scoped consent: integrations ask for broad read and write scopes because it is simpler for the vendor, and users accept. RFC 9700 states that access token privileges should be restricted to the minimum required.
- Consent phishing: a malicious app looks like a direct integration. See the Consent Phishing and Illicit OAuth Grants Guide.
- Invisible sprawl: grants are spread across every SaaS admin console, so nobody has a complete list.
iPaaS-mediated integrations in depth
Threat model and architecture
The iPaaS holds a connection to each application, typically an OAuth grant or API key bound to an integration user, and runs flows that read from one connection and write to another. Your team administers who can build, which connections exist and how flows are promoted. The provider operates the runtime and the connection store. A compromise of a builder or administrator account, of the platform's own infrastructure, or of a customer-hosted agent gives access to every connection in scope. The iPaaS Compromise Playbook covers response.
Failure modes
- Tier 0 store treated as a tool: builder accounts without phishing-resistant MFA, shared admin logins and no review of who can create connections.
- Shared super-connections: one high-privilege connection reused by many flows, so a single flow edit can read or move everything that connection reaches (OWASP NHI9:2025 NHI Reuse).
- Flow edits redirecting data: anyone who can edit a production flow can add a new destination, exfiltrating over a sanctioned channel (ATT&CK T1567 Exfiltration Over Web Service).
- Personal credentials in connections: builders authorise connections with their own accounts, which then break or, worse, persist with the builder's full rights (OWASP NHI10:2025 Human Use of NHI).
Token concentration and blast radius
Concentration is not automatically worse. It trades many medium risks you cannot see for one high risk you can defend and monitor. The deciding factors are who operates the store and what you control.
| Compromise scenario | Direct integrations | iPaaS | What limits the damage |
|---|---|---|---|
| Integration vendor's back end breached | Tokens for your tenant and every other customer replayed | Only if the iPaaS provider itself is breached | Narrow scopes, IP allow listing or sender-constrained tokens where the SaaS supports them, fast revocation |
| One user's account taken over | Attacker can consent new apps if user consent is open | If the user is a builder: edit flows, create connections | Admin consent workflow, builder role separation, MFA |
| Admin of the integration layer compromised | Not applicable as a single point; per-app admins matter | Every connection and flow in the tenant | Few named admins, separate admin accounts, alerting on connection and role changes |
| Customer-hosted agent host compromised | Not applicable | Credentials to internal systems held by the agent | Hardened host, outbound-only, per-agent credentials, segmentation |
| Integration abandoned | Grant remains active at the vendor | Connection remains in the store | Expiry and inactivity review, owner attestation |
RFC 9700 also recommends audience-restricting access tokens to a specific resource server and protecting public-client refresh tokens by sender-constraining or rotation. Most SaaS APIs give customers limited choice over these properties, so scope, integration-user permissions and network restrictions are the levers you actually control. See the OAuth Refresh Token Rotation and Expiry Guide.
Visibility and offboarding
- Direct grants: discovery has to happen in each SaaS application's connected apps, consent or API token records, or through a SaaS security posture tool reading them. Platform-specific procedures are in How to Inventory third party oauth apps in google workspace and How to review Salesforce connected apps and integration users.
- iPaaS connections: the platform's connection list is a ready inventory, but it lists connections, not their real permissions. Join it to the integration user's rights in each target application.
- Offboarding a person: for direct grants, disabling the user does not always revoke grants they made; check the target platform's behaviour and revoke explicitly. For an iPaaS, reassign connections owned by the leaver to a team-owned integration user before disabling. See the NHI Offboarding and Decommissioning Guide (OWASP NHI1:2025 Improper Offboarding).
- Offboarding an integration: revoke at the token issuer, not just in the client. RFC 7009 defines a revocation endpoint; when a refresh token is revoked, an authorisation server that supports access token revocation should also invalidate access tokens from the same grant, so short-lived access tokens may still work for their remaining lifetime where it does not.
Controls per option
| Control area | Direct integrations | iPaaS |
|---|---|---|
| Grant approval | Restrict user consent to low-impact permissions from verified publishers; route the rest to an admin consent workflow | Only connection owners may create production connections; approval recorded |
| Identity used | Dedicated integration user per vendor where the target app allows it, not an employee account | Dedicated integration user per connection or per system, never a builder's personal account |
| Scope | Narrowest scopes offered; reject vendors that require full admin scopes without justification | Narrow integration-user permissions; separate read and write connections where practical |
| Network | IP restrictions on the integration user or API client where the SaaS supports them | Pin platform egress IPs in target allow lists; outbound-only agents |
| Change control | Re-approval when a vendor requests new scopes | Environment separation and approved promotion of flows |
| Logging | SaaS API audit logs filtered by integration user | Platform audit log and run history, plus SaaS-side logs |
| Review | Quarterly attestation per grant by business owner | Quarterly attestation per connection and per admin or builder |
| Revocation | Per-app revocation runbook, tested | Bulk revocation runbook for every connection, tested |
| Supplier risk | Tier vendors by scope and data; assess the high-scope ones | Treat the iPaaS provider as a critical supplier |
Worked scenario
A company has 140 direct integrations discovered across its CRM, collaboration suite and code hosting, 30 of them holding broad read scopes, plus an iPaaS running 60 flows on 25 connections. A review finds 18 direct grants whose consenting users have left, and four iPaaS connections authorised with builders' personal accounts. The team moves the eight highest-scope data syncs into the iPaaS behind dedicated integration users with narrowed permissions and IP restriction, revokes the orphaned direct grants, and restricts user consent to low-impact permissions with an admin workflow for the rest. It then treats the iPaaS as tier 0: two named admins, separate admin accounts, alerts on connection creation, and a rehearsed bulk revocation. The result is fewer, narrower tokens, most in a store the company monitors. The figures are illustrative.
How to implement
- Inventory both estates: export connected apps and grants from each major SaaS application and the connection list from the iPaaS; record scope, identity used, owner and last use.
- Classify by blast radius: rank each integration by data sensitivity and scope breadth; the top tier gets attention first.
- Remove what is orphaned: revoke grants and connections with no owner or no use in a set period, after confirming with the business; keep a record so a broken integration can be re-authorised.
- Close the consent door: restrict user consent and enable an admin approval workflow in each identity provider and major SaaS application, testing first with a pilot group.
- Decide the routing rule: define which integrations must go through the iPaaS (for example, any touching regulated data or needing write access across systems) and which may stay direct.
- Harden the iPaaS as tier 0: follow the controls in the table above before migrating high-scope integrations into it.
- Rehearse revocation: for one vendor and for the whole iPaaS tenant, time how long full revocation and re-authorisation take.
- Review quarterly: owner attestation, scope drift and new grants since the last review.
Decision guidance
- Small organisations with a handful of integrations: direct integrations with tight consent settings and a simple register are usually enough; an iPaaS adds a critical system to secure.
- Organisations with dozens of integrations or heavy data movement: route high-scope and regulated flows through an iPaaS for inventory, change control and logging, and keep low-risk native connectors direct.
- Highly regulated sectors: prefer the architecture that gives provable logs of data movement and timely revocation, which usually favours the iPaaS for sensitive flows.
- When the vendor offers only broad scopes: mediate through an iPaaS with a narrowly permissioned integration user where possible, so the broad grant is not held by a third party you cannot monitor.
- When the iPaaS team is thin: concentration without administration is worse than scattering; build the platform controls first.
Detection and measurement
- Monitor: new consent grants and scope changes, connection and role changes on the iPaaS, API calls by integration users from unexpected IPs, and volume spikes in exports (NIST SP 800-53 SI-4, AU-6). See How to detect use of a stolen OAuth refresh token.
- KPI 1: share of integrations with a named owner and review date.
- KPI 2: number of grants or connections with broad or admin scopes, trending down.
- KPI 3: orphaned grants and connections found per review.
- KPI 4: time to revoke all tokens for one vendor, and for the whole iPaaS tenant, in rehearsal.
- KPI 5: share of iPaaS connections using dedicated integration users rather than personal accounts.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02, PR.AA-01, PR.AA-05 | Inventory of services; managing service identities and credentials; least privilege |
| NIST CSF 2.0 | GV.SC-04, GV.SC-07, DE.CM-06 | Prioritising suppliers, managing their risk, monitoring external service providers |
| NIST SP 800-53 Rev 5 | AC-2, AC-6, IA-5, SA-9, CA-3 | Account management, least privilege, authenticator management, external services, information exchange |
| MITRE ATT&CK v20 | T1528, T1550.001, T1671, T1567 | Token theft and use, malicious integrations, exfiltration over web services |
| OWASP NHI Top 10 2025 | NHI1, NHI3, NHI5, NHI7, NHI9, NHI10 | Offboarding, third-party NHI, overprivilege, long-lived secrets, reuse, human use |
| IETF | RFC 9700 (BCP 240), RFC 7009 | OAuth security best current practice; token revocation |
Common failure patterns
- Assuming the iPaaS sees everything: user-consented direct grants never appear in its connection list.
- Accepting vendor default scopes: broad scopes held by a third party set the ceiling on a vendor breach, as the Salesloft Drift breach showed.
- Revoking in the client only: deleting a connection without revoking the grant at the issuer leaves a working token.
- Builders as administrators: production flows edited directly, without approval, by people with access to every connection.
- No revocation rehearsal: the first bulk revocation happens during an incident, and takes days.
Practitioner checklist
- Inventory direct grants in every major SaaS application and connections in the iPaaS.
- Assign an owner, scope rationale and review date to every integration.
- Restrict user consent and enable an admin approval workflow.
- Use dedicated integration users, never personal accounts, for connections.
- Define which integrations must be routed through the iPaaS.
- Run the iPaaS as a tier 0 system with few admins and approved flow promotion.
- Revoke at the token issuer and confirm with a test call.
- Rehearse revocation for one vendor and for the whole iPaaS tenant.
- Alert on new grants, scope changes and connection changes.
Standards and references
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- IETF: RFC 7009 OAuth 2.0 Token Revocation
- OWASP: Non-Human Identities Top 10 2025
- MITRE ATT&CK: T1528 Steal Application Access Token
- MITRE ATT&CK: T1671 Cloud Application Integration
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: OAuth and SaaS integration breaches, OAuth Apps vs Integration Service Accounts, Security Requirements for Selecting an Integration Platform (iPaaS), How to audit Zapier, Make and n8n connections and credentials.