Your Vendor Questionnaire Doesn't Ask the Right OAuth Questions

The OCC and Federal Reserve have been talking about “4th party risk” for a few years now. It shows up in examination findings. It comes up in guidance. Bank risk officers have heard the term.

What nobody has figured out is how to actually manage it.

OAuth token chains are one of the clearest examples of how 4th party risk executes in the real world. And most vendor management programs, including ones that were built to satisfy examiner expectations, aren’t built to catch it.

The Vendor of My Vendor Is My Vendor Too

This is exactly what regulators mean when they say “4th party risk.” Here’s how it plays out technically, and why it’s so hard to catch.

Attackers compromise a mid-tier SaaS tool. Not your direct vendor, something downstream. A support platform, an integration layer, a workflow tool. That tool has access to data from your actual vendor, maybe support case histories, API credentials, integration configs. Your vendor used it to manage customer accounts.

Inside that data are OAuth refresh tokens. Tokens that your vendor issued to connect into your environment.

Those tokens get used. Your systems get accessed. And you find out about it the way you find out about most third-party breaches: late, and from someone else.

The reason this works is simple. Your vendor’s vendor isn’t in your questionnaire. You’ve probably never thought about them. But they had a credential that reached your systems, and when they got hit, that credential came with them.

The vendor of your vendor of your vendor is, effectively, your vendor too. The chain doesn’t care that you never signed a contract with them.

Why MFA and SSO Don’t Save You Here

This is the part that frustrates people when I explain it.

Standard security controls protect authentication. When a user logs in, MFA kicks in. When an employee accesses a system, SSO enforces the right identity policies. Those controls work for human-initiated access.

OAuth refresh tokens aren’t human-initiated. They’re machine-to-machine. Once issued, they operate on their own schedule, often indefinitely. They authenticate silently, in the background, with no login prompt and no MFA challenge.

A refresh token doesn’t expire because no one logged in with it. It just keeps working until someone explicitly revokes it.

That means a token issued two years ago, from an integration your team set up and mostly forgot about, is still live. And if it ends up in the wrong hands through a downstream breach, there’s nothing in your standard security stack standing between that token and your data.

The Industry Is Starting to Catch Up. Slowly.

To be fair, some vendors are recognizing this. Salesforce has been pushing for stronger OAuth practices, including PKCE (Proof Key for Code Exchange), refresh token rotation, and TTLs on refresh tokens. The idea behind rotation is simple: every time a refresh token is used, it gets replaced with a new one. If an old token shows up somewhere unexpected, you know it’s been stolen. TTLs force tokens to expire on a defined schedule instead of living indefinitely.

These are good controls. They should be table stakes for any platform that issues OAuth grants into customer systems.

But here’s the problem: most of the SaaS ecosystem wasn’t built this way. OAuth was designed for convenience and developer speed, not security. Refresh tokens that never expire were a feature, not a bug. The assumption was that tokens would be stored securely by well-intentioned developers building well-reviewed integrations. That assumption has not held up.

We’re now trying to retrofit security onto an authorization model that was never designed with third and fourth party exposure in mind. Which is, of course, how most things work in tech. We build fast, we scale, and then we spend the next decade figuring out what we broke.

The difference here is that the blast radius of getting it wrong runs through your entire vendor ecosystem.

The Four Questions Your Questionnaire Is Missing

Most vendor security questionnaires cover the basics well. Encryption, access controls, incident response, SOC 2 status. Those are fine. But they don’t address OAuth exposure, and that’s where the attack surface lives now.

Here are three questions to add to every vendor assessment for any vendor that integrates into your systems via OAuth:

1. Which other applications have OAuth access into the data you hold on our behalf?

You want a list. Not a description of their integration policy. An actual list of third-party applications that hold tokens with access to your customer data, your systems, or your API. If they can’t produce this, they don’t have visibility into their own OAuth exposure, which is itself a problem.

2. How quickly can you revoke a downstream token if one of those applications is compromised?

This is the response question. If a tool in their integration ecosystem gets breached, how fast can they cut off its access? Is there a process? Who owns it? Has it been tested? The answer tells you a lot about how seriously they’ve thought about this.

3. Are tokens scoped to least privilege, or are they Allow All?

Not all OAuth tokens are created equal. A well-scoped token can read a specific resource. A poorly scoped one can do nearly anything. Ask whether their integrations follow least-privilege principles, and ask them to show you the scopes on their highest-access tokens. Vague answers mean broad access.

4. Do you support refresh token rotation and TTLs on refresh tokens?

This is where you find out if they’ve kept up. Rotation means every time a refresh token is used, it’s replaced with a new one, so a stolen token has a short window before it’s invalidated. TTLs force tokens to expire on a defined schedule instead of living forever. These aren’t exotic controls. They’re increasingly standard. If a vendor hasn’t implemented either, their token management is operating on 2015 assumptions.

If a vendor can’t answer these in writing, you have a third-party risk problem that’s currently disguised as a procurement checkbox.

What This Looks Like in Practice

The good news is you don’t have to rebuild your entire vendor management program to address this. Start with your highest-risk integrations.

Look at which SaaS vendors have OAuth connections into your core systems: your CRM, your cloud infrastructure, your data warehouses, your customer platforms. For each of those, ask the three questions above. You’ll quickly find out which vendors have thought about downstream token exposure and which haven’t.

For vendors that can’t answer clearly, you have a few options: require them to provide answers before renewal, limit the scopes of their existing tokens, or require periodic token rotation as a contract term.

You should also be doing your own audit. Most cloud platforms and SaaS applications have an OAuth app management console. Pull it up. Look at what’s authorized. You’ll probably find apps that were connected years ago for projects that no longer exist, with permissions that were never reviewed again. Revoke what you don’t recognize or no longer use.

The Contract Piece

None of this works without the right contract terms.

Your vendor agreements should require notification if any application in their integration ecosystem experiences a security incident. They should give you the right to audit OAuth connections on request. And they should include explicit language about what integrations require your approval before a new OAuth grant is issued.

Most contracts don’t have any of this. That’s a gap worth fixing at the next renewal.

The Regulatory Gap

Examiners have been citing 4th party risk for years. What they haven’t given banks is a way to operationalize it. The guidance says you’re responsible for understanding the risks introduced by your vendors’ vendors. It doesn’t say how.

OAuth token mapping is one practical answer. It’s not the whole solution, but it’s a concrete starting point that connects regulatory language to actual attack mechanics. When an examiner asks how you manage 4th party risk, “we map OAuth grant chains for our critical vendors and require token scoping attestation” is a far better answer than “we review our vendors’ vendor questionnaires.”

It’s also more defensible, because it’s tied to something real.

A Risk Category That’s Only Getting Bigger

SaaS sprawl isn’t slowing down. Every new tool your vendors adopt is a potential link in a chain that ends at your data. The perimeter is gone, and the OAuth graph, who can access what through what token issued by whom, is the new attack surface.

Your questionnaire was built for a different threat model. The regulators already know this is a problem. Now you need a way to actually do something about it.

If you want help auditing your vendor OAuth exposure or updating your third-party risk program to cover downstream token risk, reach out to Vaughn Cyber Group. This is exactly the kind of gap we help organizations find before someone else does.