Before OAuth, a third-party app that needed a user's data would ask for that user's password and keep it, "typically a password in clear-text", and the only way to cut the app off was to change the password (RFC 6749, §1). OAuth 2.0 replaced that model: the app gets a token, and the password stays with the service that issued it.

OAuth matters as soon as your product needs to read or write data in another system the buyer owns, such as their CRM, calendar or file storage. It sets what your product can touch and how the buyer cuts it off.

What the standard says it does

The RFC's abstract is short enough to quote: the framework "enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."

In call language, that's two situations. In the first, a person at the buyer clicks "connect", lands on their CRM's own login page, sees a list of what your product is asking for and approves it. Your product never sees their password. In the second, there's no person in the loop; your product gets access as itself, for background jobs.

What your product receives either way is an access token. The RFC describes it as "a string representing an authorization issued to the client", and adds that tokens "represent specific scopes and durations of access".

Scopes are the part admins read

A scope is the named permission your product asks for, such as read access to contacts or write access to calendar events. The RFC lets the requesting app name the scopes it wants and lets the authorization server tell it which ones it actually granted, which may differ from what was requested (§3.3).

Say Northwind, a hypothetical buyer, is connecting your product to its CRM. Their admin will look at the consent screen and ask why your product wants write access to every object when it only creates tasks. Know the exact list of scopes your integration requests, and know which feature needs each one. If one of them is broader than the feature needs, say so and find out whether it can be narrowed. An admin who spots an unexplained scope on a consent screen can hold up the whole rollout.

Revoking access and what happens to tokens

The other thing admins care about is the exit. Because access runs through a token rather than a stored password, the buyer can revoke your product's access on their side without changing anyone's credentials. Find out what your product does when that happens, including whether anyone is alerted when syncs start failing. Then find out whether data already pulled across stays in your product; that's a data-retention question, so check what your DPA says about it.

Token lifetimes matter too. Under §1.5 of the RFC, a refresh token lets your product get new access tokens without asking the user again, so the connection outlasts any single access token. The same section describes it as "a string representing the authorization granted to the client by the resource owner", meaning whoever approved the connection, and what happens when that account is deactivated depends on the provider. Google Workspace says "Suspending a user resets the user's sign-in cookies and OAuth tokens" (Google Workspace Admin Help), and Microsoft Entra ID issues a new token on refresh only "If the user is still authorized" (Microsoft Learn). So with Google, suspending the user resets their tokens, and with Microsoft, the next refresh fails once the user is no longer authorized. Find out whose account each connection runs under. If your product can connect through a dedicated integration user, tell them; the connection then doesn't depend on one employee's account.

Where OAuth stops

OAuth and single sign-on both send someone to a login page, which is why they get confused. SSO is about your users logging in to your product with their company identity; OAuth here is about your product getting permission to reach into another system. They can appear in the same deal and answer different questions. SAML and SCIM belong to the SSO side, and we've written about handling SSO questions.

OAuth also isn't the integration itself. It's the permission layer in front of an API, so the questions about what data moves, how often and in which direction still need answering. Those are API questions, and we've written about them separately.

Practising the answer

VoiceVocab's "The foundations" course covers APIs and how software connects, and "Cloud & security" covers authentication and permissions, so a consent-screen question sits across both. You answer out loud and get written feedback on accuracy, clarity and relevance to the buyer. Start with the "APIs & integrations" lesson; a free account opens it.

Put the scope list from your integration's documentation, or from your product team, into a short table: one scope per row, with the feature that needs it beside each.