Vercel’s April 2026 incident was not a network breach. It was three hops through already-granted application access: a compromised third-party AI app, a corporate Google Workspace account, then internal environments and environment variables. No firewall bypass required.

That pattern is not unique to Vercel. In the November 2025 Salesforce-connected app incident, Gainsight’s postmortem, based on Mandiant’s investigation, documented 285 tokens from a single integration, some issued as far back as October 2017. In 2022, GitHub disclosed attackers abusing stolen OAuth user tokens issued to Heroku and Travis CI to access private repositories.

Different incidents, same exposure: long-lived delegated access is still scattered across app-specific systems the enterprise cannot inventory or shut down quickly.

Most responses to incidents like these focus on long-lived credentials, visibility, and auditing. Those are real problems. They are also symptoms.

The deeper failure is authority placement.

Rotating credentials and auditing grants improves operations inside each OAuth island. It does not change the fact that every new integration creates another island with its own authority to mint, renew, and revoke access. The failure is not bad operations inside each island. The failure is a model that keeps creating islands and placing authority inside each one independently. Enterprise SaaS has never really fixed that layer.

Single Sign-On (SSO) centralized login, but it did not centralize delegated access across apps. Each new integration still tends to create another client, another credential or refresh-capable artifact, another approval surface, and another vendor-local revocation workflow. The result is another OAuth island.

Enterprise SaaS needs to move from point-to-point OAuth integration to OAuth federation. For services and workloads, the model is already mature enough to adopt now. For user-delegated cross-app access, Cross-App Access (XAA) is the right standards direction. The goal is not foreign-token portability. The goal is issuer-signed assertion in, local access token out, with more of the governance around long-lived delegated access moved upstream to the enterprise issuer.

Why OAuth Islands Are A Real Security Problem

Imagine an internal assistant that reads a Jira issue, updates Salesforce, and posts the result to Slack.

What sounds like three useful connections is, from an enterprise security perspective, usually three separate sources of long-lived delegated access outside the enterprise Identity Provider (IdP).

An OAuth island is an app-specific system for long-lived delegated access outside the enterprise IdP, with its own client, credential, grant, renewal, and governance lifecycle. The enterprise did not gain one governed cross-app access plane. It inherited another OAuth island to inventory, govern, and shut down.

Every integration creates another OAuth island outside the IdP. That is why separate integrations are a real security problem. The issue is not that one OAuth flow is too complicated. The issue is that point-to-point integration keeps manufacturing hidden trust inventory outside the IdP, one app at a time.

When an OAuth grant creates long-lived delegated access, the enterprise has effectively created a new standing access path. The prompt is brief. The access it creates often is not.

Multiply that by the estate, not by one demo flow. Three apps in one workflow means three OAuth islands. Ten important workflows across the same SaaS estate do not create one shared control plane; they create dozens of long-lived delegated access relationships with different clients, scopes, storage locations, and revocation paths. Add app marketplaces, internal brokers, Zapier-style automation, and other integration runtimes, and the hidden trust inventory grows faster than most security teams can enumerate it.

Trust is often granted in a moment and exploited months or years later. That is why the Gainsight timeline matters. Gainsight’s postmortem documented 285 tokens from a single integration spanning eight years.

Nudge Security’s research finds an average of 16 OAuth grants per employee, four of them carrying data-sharing permissions. In a thousand-person organization, that is sixteen thousand OAuth grants. No security team manually governs that.

That is the operational meaning of an OAuth island. It is not just another integration. It is another place where access has to be found, understood, and shut down under pressure. Security teams do not just have to ask “was this token stolen?” They have to ask which app created it, where the credential or refresh-capable artifact is stored, which runtime is still holding it, which vendor console controls revocation, whether the grant is still renewable, and whether downstream automation copied the same access into another system.

Attackers no longer need network adjacency if long-lived delegated access already gives them application adjacency. Once a standing grant or refresh-capable path exists across apps, lateral movement becomes an authorization problem as much as a network problem.

Production systems and sensitive data should not sit one low-friction third-party authorization away from external tooling.

Each island also inherits the same technical weaknesses: shared secrets instead of asymmetric client authentication, bearer-style artifacts reusable if copied or stolen, sparse governance APIs, and no single revocation surface. These are not independent problems to fix vendor by vendor. They are what failed authority placement looks like in production. Fixing them inside each island separately is the credential hygiene response. Moving authority upstream is the federation response.

That sprawl did not happen by accident. Product-led growth, app marketplaces, and one-click integration flows made OAuth adoption frictionless by design. Every “Connect with [SaaS]” button shortened time to value and quietly extended the enterprise security perimeter. Any control that depends on a user remembering to mark the right secret, pick the right scope, or revisit the right admin screen has already failed at SaaS scale.

The problem is not one bad vendor or one misconfigured flow. It is an operating model that manufactures more long-lived delegated access than the enterprise can see, govern, or shut down.

What OAuth Federation Means Here

OAuth federation means issuer-signed assertion in, local access token out. A downstream SaaS authorization server accepts an issuer-signed assertion from an enterprise issuer as input to mint its own local access token. The SaaS still decides local authorization and still issues its own tokens. What moves upstream is more of the client authentication, grant governance, and renewal authority. That is a narrower and more viable move than asking every SaaS to accept every other vendor’s access token.

SSO federation centralizes login. OAuth federation centralizes more of the governance around long-lived delegated access. That distinction matters because the enterprise IdP often already governs authentication, but not what happens later inside each SaaS product when a client requests a grant, stores a refresh token, or keeps renewing access for months. Enterprises often think they centralized trust when they bought SSO. In practice, they centralized login while long-lived delegated access kept proliferating underneath it.

In practice, that means the enterprise issuer becomes the place where more client authentication, assertion issuance, and renewal authority live, while the SaaS remains the place where resource-specific authorization happens. The issuer can decide which clients or workloads are even eligible to request assertions, under what conditions assertions may be issued, how keys are managed, whether risk signals block issuance, and when renewal authority should stop. The SaaS still decides whether the presented assertion is acceptable for its own APIs and what token it is willing to mint from it. That separation is what makes the model viable: governance moves upstream without turning every SaaS into a passive resource server for foreign tokens.

That shift changes the blast shape in incidents like Vercel, Gainsight, and GitHub. Federation does not erase local access-token risk, but it reduces how much standing delegated access has to live in vendor-local systems in the first place. Fewer shared secrets and refresh-capable paths have to be recreated app by app, renewal authority moves closer to the issuer the enterprise already governs, and shutdown depends less on visiting every vendor console one by one.

Two deployment lanes matter here. Workload and service federation is already possible in many cases with generic assertion grants such as RFC 7523. User-delegated cross-app federation is the harder problem, and that is where XAA matters most. XAA is being standardized in the IETF through Identity Assertion Authorization Grant (ID-JAG). OAuth federation is the broader architectural pattern; XAA is the user-delegation standards direction inside it.

Workload And Service Federation

For workloads, services, and many agent-to-SaaS cases, the excuse phase is over. Assertion grants such as RFC 7523 already let a client present an issuer-signed assertion to a SaaS token endpoint and receive a local access token in return. That is issuer-mediated federation for machine access. It moves key management, workload identity, and assertion issuance upstream while the SaaS keeps control of its tenant, scopes, and API contract.

In a concrete service flow, a CI job, backend service, or agent runtime can obtain an issuer-signed assertion from the enterprise issuer, exchange it for a local access token, and avoid storing another shared secret in a runtime or build system. The SaaS still mints the token and still enforces its own API policy. The same model works for a deployment pipeline that needs to open a Jira ticket, update a status page, and post to Slack without embedding three separate vendor secrets in the build system. That is already enough to replace many shared-secret integrations with a more governable model.

Buyers should start treating that as baseline machine-access support, not as advanced federation plumbing. If a SaaS product still requires every service, pipeline, or agent runtime to register another app-local client and store another long-lived secret, the customer is still being asked to operate another OAuth island.

XAA For User Delegation

For user delegation, XAA is the SSO moment for cross-app access. If OAuth federation is the architecture, XAA is the clearest standards expression of that architecture for user-delegated cross-app workflows. It is the right bet because it standardizes trust reuse, not token sharing. The enterprise keeps the issuer relationship it already operates. The downstream SaaS keeps its own authorization server and its own local access tokens. The resource server does not have to learn another vendor’s access-token format or accept a foreign token directly. The workload and service lane is more mature today. The user-delegation lane has now become urgent enough that XAA should be treated as the next enterprise default, not as a distant standards project.

Consider the Jira/Salesforce/Slack assistant from the opening. Today that workflow requires three separate user-delegated authorization setups: the user redirected into Atlassian for consent and a Jira-local refresh token, redirected into Salesforce for consent and a Salesforce-local refresh token, and redirected into Slack for consent and a Slack-local refresh token. Three vendor consoles to configure. Three standing delegated grants to govern. Three separate revocation paths when the workflow is decommissioned or the user’s access changes.

As those workflows multiply across an enterprise and agents begin running them continuously on users’ behalf, the user-delegation surface compounds the same way the workload surface does. XAA addresses this directly: the user authenticates once to the enterprise issuer, and each downstream SaaS accepts the resulting identity assertion as the input to its own local delegated grant. The approval surface consolidates at the enterprise issuer. The standing grant state moves upstream. The three downstream SaaS products still mint their own local access tokens and still enforce their own API policy, but the enterprise controls the authorization input rather than rebuilding it separately inside each one.

The downstream SaaS should be able to treat an enterprise-issued identity assertion as the input to a local delegated grant, instead of forcing every cross-app workflow back through another isolated vendor-local authorization setup.

For XAA-style user delegation, the comparison looks like this:

Notice what does not change. In XAA, the downstream SaaS still decides what scopes, tenant rules, and resource access it will allow. That is the key bet: change the grant path without giving up downstream authorization or asking resource servers to accept foreign tokens.

Why XAA is the right bet:

• It reuses issuer trust the enterprise already established for SSO instead of rebuilding long-lived delegated access inside every app.
• It preserves downstream SaaS sovereignty because the SaaS still mints and enforces its own token.
• It avoids foreign-token portability, so resource servers do not need to accept another vendor’s access token format.
• It gives the market an incremental adoption path instead of requiring a full inter-vendor re-architecture before anything improves.

This is why OAuth federation beats more point solutions. The enterprise should not have to rebuild the same access model separately inside Atlassian, Salesforce, Slack, and every other SaaS product just to let one approved workflow cross app boundaries. OAuth federation is not valuable because it removes every downstream token risk. It is valuable because it centralizes the parts of the model that are most expensive to govern and most inconsistently implemented across vendors. Without federation, the enterprise inherits the OAuth maturity of every vendor it authorizes.

Why Agents Change the Economics

Point-to-point OAuth integration survived because the integration set was bounded. Human-operated SaaS deployments had a finite set of important apps, a finite set of approved integrations, and a slow enough rate of change that organizations could tolerate too many vendor-local clients, secrets, grants, and refresh paths without the whole model collapsing. Agents break that assumption. As argued in OAuth for Open-World Ecosystems, agents do not operate in closed worlds. They discover tools and protected resources at runtime, encounter authorization servers they were never pre-configured to know, and expand the number of token acquisition paths far faster than any human integration team can manage manually.

That changes the economics as much as the security model. In a point-to-point world, every new tool, app, or API means another client registration, another secret or key, another consent or approval surface, another renewal path, another audit record, and another incident-response dependency. When one human workflow turns into fleets of agents and sub-agents traversing dozens or hundreds of apps and resources, the trust surface does not grow linearly. It compounds.

Agents do not simply make the old model noisier. They make it operationally bankrupt. Organizations hit a form of authorization bankruptcy: more long-lived delegated access relationships than they can inventory, review, rotate, or revoke before the next wave is already in production. At that point, failing to federate stops being tolerable architecture debt. It becomes an existential scaling problem.

This is also why the adoption chicken-and-egg is finally breaking. Historically, apps were reluctant to pay the implementation cost of federation for one or two IdPs, and IdPs were reluctant to invest until enough apps supported it. Agents are collapsing that standoff because neither side can afford to keep building point-to-point trust at agent scale.

Model Context Protocol (MCP)’s Enterprise Managed Authorization and similar platform moves are building OAuth federation into the agent integration layer because the alternative does not scale. Agents force the market to confront what enterprise SaaS could previously postpone: point-to-point long-lived delegated access is no longer economically or operationally viable as the default.

SSO followed the same pattern. It became table stakes because SaaS moved application identity outside the reach of Active Directory and the corporate network, and the old model no longer scaled. Over time, SSO stopped being a premium feature and became part of the baseline for serious enterprise software. Long-lived delegated access is now in the same position one layer down. SSO solved the question of who signed in. It did not solve who can keep acting later across app boundaries. Agents are forcing that question into the open.

What The Transition Looks Like

This is a staged transition, not a single cutover.

Now: use generic assertion grants where vendor support exists. RFC 7523 already gives workloads, services, and many agent-to-SaaS integrations a path where a client presents an issuer-signed assertion at a SaaS token endpoint and receives a local access token in return. That does not solve the whole end-to-end problem, and it does not eliminate all per-product registration. But it is real progress away from per-app shared secrets and toward upstream trust. It also enables more just-in-time enterprise access flows, where services, pipelines, and agents can obtain short-lived access when needed instead of depending on long-lived credentials that were provisioned in advance.

Next: adopt XAA as the standards direction for user-delegated cross-app access. The current IETF work for that is ID-JAG. It supports the same enterprise outcome, upstream trust with downstream local access-token issuance, but vendor support is less mature. The service and workload lane is more mature today. The user-delegation lane is mature enough in standards shape, market need, and buyer pressure that XAA should now be treated as the direction to build toward. It can support architectures where approval and governance move closer to the enterprise identity layer, but the exact approval and consent model remains a deployment choice, not something the protocol guarantees by itself. The pattern also extends beyond the workforce IdP to CIAM platforms and internal service identity wherever the downstream authorization server already trusts an issuer for SSO and subject resolution. See ID-JAG Beyond the Enterprise IdP.

The transition has three layers. Now is assertion-based federation for workloads, services, and many agent integrations inside today’s SaaS reality. Next is stronger standardization for user-delegated cross-app access through XAA, with ID-JAG as the current IETF work. Later is the broader open-world agent problem, where clients discover tools and authorization servers at runtime and OAuth has to keep evolving beyond today’s mostly closed-world SaaS assumptions. That later stage does not make the urgency any less. It makes the need to stop building new islands even clearer.

Pieces of this are shipping today, but unevenly. Okta’s Cross-App Access docs show a user-delegated path that still assumes an existing app relationship, Microsoft Entra shows workload identity federation in production, and Salesforce shows JWT Bearer support with prior approval. That is not the finished cross-SaaS end state, but it is enough to prove the building blocks are real and deployed.

The important market point is that enterprises do not need to wait for a perfect end state to change direction. The transition can start anywhere a SaaS token endpoint is willing to accept an issuer-signed assertion instead of forcing another shared secret or another long-lived vendor-local credential. Each time that happens, one more integration moves from another OAuth island toward an issuer-mediated model. The strategic shift is cumulative even before the market reaches a fully standardized cross-app model.

For workloads and services, adopt issuer-mediated federation now. For user-delegated cross-app access, adopt XAA as the standards direction.

What OAuth Federation Does Not Do

OAuth federation is scoped by design, not by compromise. It changes where long-lived delegated access is governed. It does not replace every control in the stack, and it should not. That scope is what makes the model viable for downstream SaaS adoption.

• It does not remove local authorization. Downstream SaaS products still decide what scopes, tenant rules, and resource access they will allow. The SaaS keeps its authorization server and its own local access-token policy.
• It does not eliminate registration. Some SaaS products will still need local trust configuration to accept issuer-signed assertions. Federation reduces ongoing credential sprawl; it does not collapse setup to zero.
• It does not rescue weak issuer governance. Moving authority upstream only helps if the enterprise identity layer actually governs clients, workloads, approval, and renewal well. A poorly governed issuer just centralizes the failure point without reducing the risk.
• It does not create a single global kill switch. Cutting off issuer-side assertion issuance or renewal authority is more powerful than hunting vendor consoles one by one, but local access tokens may still need to expire, be revoked, or be subject to tenant-side controls.
• It does not eliminate token risk at the edge. Local access tokens still benefit from short lifetimes, sender-constraint, and stronger runtime controls.

These are not objections to federation. They are the design choices that make the model work: the enterprise takes more control of the grant path, the SaaS keeps control of resource authorization, and neither side has to give up what it owns. The right mental model is “federate the grant, keep the token local.”

Stop Building Islands

The April 19, 2026 Vercel incident did not create this problem. It made it harder to ignore.

The immediate step is practical: pull an inventory of active OAuth grants and refresh-capable artifacts across your top SaaS integrations, ask when the oldest credential was issued, and ask whether you could cut off renewal without visiting every vendor console. If you cannot inventory, revoke, and shut down long-lived delegated access centrally, you are still operating OAuth islands. But inventory is triage, not the strategy. It tells you how many islands you already have. It does not change the model that keeps creating new ones.

The strategic shift is now clear. For workloads and services, issuer-mediated federation should be a baseline enterprise requirement. For user-delegated cross-app access, XAA should become the standards answer. Chief Information Security Officers (CISOs), identity leaders, and security buyers should force both shifts into the market: make OAuth federation part of the Request for Proposal (RFP), part of vendor security reviews, and part of renewal conversations. That means asking directly: Can you accept issuer-signed assertions and mint local access tokens for workloads and services today? Do you support XAA, or do you have a credible XAA path for user delegation? Do you expose asymmetric client authentication, grant inventory, centralized revocation, and emergency shutdown paths? The core buyer question is not whether each vendor runs its island well. It is whether the island still has to exist.

After SSO standardized login, enterprise SaaS should standardize cross-app access around the same pattern: issuer-signed assertion in, local access token out.

Vendors that still require another app-local client, another stored long-lived artifact, and another vendor-local revocation path for each workflow are not offering a stronger default. They are asking customers to carry another OAuth island. The market does not need better-run islands. It needs vendors to stop building them.