Your product has an OAuth flow so third parties can integrate. A user clicks approve on a consent screen, and from then on an application you did not write holds a token to their data, refreshing itself indefinitely.
That is a supply chain relationship your customer entered into in about four seconds, and in most products nobody can list them afterwards.
This post is what to build around third-party app access. For whoever is standing up an integrations platform, and for whoever is the customer on the other side of one.
The consent screen is the only control most users see
They read it for about a second, so what it says matters more than how many options it has.
Describe the access in the user's terms, not in scope names. "Read and send messages on your behalf" rather than messages.write. If your scopes are so coarse that the plain-language version sounds alarming, the problem is the scopes.
Show who is asking, with a verified identity where you can. A name and a logo anyone can set is not identification, and impersonating a well-known brand in a consent screen is a standard technique.
Distinguish user-scoped from workspace-scoped clearly. A user approving access to their own data is a different decision from approving access to everything their organisation holds, and a consent screen that blurs it is how one employee grants a stranger access to a company's documents.
Scope design decides the blast radius
Coarse scopes are the root cause of most of the damage. If the narrowest thing you offer is "read all data", every integration that needs one field gets everything, and a compromise of a small tool with ten users becomes a compromise of your customers' entire datasets.
Split by resource and by action, offer read separately from write, and make it possible for an app to request less. Then show, in the consent screen and in the management view, what was actually granted rather than what the app is capable of requesting.
Refresh tokens are the real grant
An access token expires in an hour and nobody cares. The refresh token is the durable credential, and unless you do something about it, it lasts forever.
Decide deliberately: an absolute maximum lifetime, an inactivity expiry, or both. An integration a customer stopped using two years ago should not still hold a working credential, and inactivity expiry is the control that handles it without anyone reviewing anything.
Rotate refresh tokens on use, and treat reuse of an already-used refresh token as a compromise signal, because it means the token exists in two places.
Give administrators a management view
The thing most products lack, and the first thing an enterprise customer asks for:
- Every connected application in the workspace, who approved it, when, which scopes, and when it last called your API.
- Revocation, per app and per user, that takes effect immediately.
- The ability to require administrator approval before any user can connect an app, and to maintain an allowlist.
That last control is what turns "our employees can connect anything" into a decision the customer's security team gets to make, and it is frequently the deciding factor in whether a large customer enables your integrations at all.
Watch the apps, because you can
You see things your customers cannot: an app whose call volume changes abruptly, an app calling from new infrastructure, an app requesting scopes it never used before, an app that has been dormant for months and wakes up.
At minimum, log every third-party call with the application identity and make that visible to the customer. It turns your audit log from a record of user actions into something that can answer what an integration did, which is the question after any incident involving one.
Have a path for when an app is compromised
It will happen, and the response is yours to run because your customers cannot.
Be able to revoke every token for a given application across all customers in one action. Be able to tell which customers were connected and what the app could reach. Then notify them with that specific information rather than a general advisory, because "an integration you use was compromised, here is what it could access in your workspace and when it last did" is actionable and a general notice is not.
Decide the policy in advance: do you revoke first and ask questions after, or wait for confirmation. Revoking first is usually right and it breaks working integrations for customers who were never at risk, so it is a decision to make calmly rather than at the time.
If you are the customer, not the platform
The same picture inverted. Review your connected applications across every platform you use, look at what they were granted rather than what you assumed, and remove the ones nobody can name. The list is usually longer than expected and contains at least one tool from a trial two years ago.
Then turn on administrator approval if the platform offers it. Every product mentioned above is one your own employees can connect things to.
The concession
Requiring administrator approval for every integration creates friction that undermines the reason integrations exist, and platforms that make connecting an app difficult see fewer of them, which is bad for the product and often bad for the customer.
The proportionate answer is to let the customer choose the posture, and to default to the safer one for workspace-scoped access while leaving user-scoped access open. A user connecting a tool to their own calendar is a different risk from a user granting an app read access to every document their company holds, and treating them identically means picking the wrong friction for one of them.
The implication
Every connected app is a third party holding a durable credential to your customer's data, approved by whoever clicked first, and usually invisible afterwards.
Whether an administrator can list them is the single question that separates an integrations platform an enterprise will enable from one their security team will block.
