OAuth is an open standard for authorisation that lets one application access a user's data or perform actions on another service without ever seeing that user's password. Instead of handing over credentials, the user grants a limited, revocable permission called an access token, issued by the service that holds the data once the user approves the request. A calendar app reading a Gmail inbox, a marketing tool posting to a client's Facebook Page, or an AI agent adjusting bids inside a Google Ads account all rely on the same mechanism. The protocol exists because the alternative, typing a real password into a third-party app, hands that app everything: the ability to change the password, read everything, act forever. OAuth narrows the grant to specific actions, for a specific window, revocable without changing the account holder's own login.

The roles and the exchange

OAuth 2.0, the version in near-universal use, defines four participants: the resource owner, the person whose data is at stake; the client, the requesting application, whether a script, a mobile app or an AI agent; the authorisation server, which authenticates the resource owner and issues tokens; and the resource server, the API holding the protected data. One company often runs both servers, as Google does for Gmail, but the roles stay distinct because some deployments split them. The exchange follows standard steps: the client redirects the resource owner to the authorisation server, which shows a consent screen listing the access requested; on approval, the server returns an authorisation code via a browser redirect; and the client exchanges that code, with its own client identifier and secret, for an access token at a separate token endpoint, a step happening server-to-server so the token never crosses the user's screen. The client attaches the token to every API call as a bearer credential, and the resource server checks its validity before responding.

Grant types cover different situations: the authorisation code grant suits applications with a user present and a backend able to keep a secret; the client credentials grant skips the user for machine-to-machine calls, the pattern behind most server-side ad platform integrations; and the device authorisation grant serves browserless hardware via a short code entered on a second device. Two older grants exposed tokens in URLs or required apps to handle raw passwords, and both are dropped from the emerging OAuth 2.1 consolidation.

A scope is a named permission requested at the start of the flow. Google's advertising API exposes its entire surface behind a single scope covering all of Google Ads; its newer Data Manager API authenticates through a separate scope, one reason the two integrations cannot share credentials inside the same Google account. Access tokens are deliberately short-lived, often expiring within an hour, to limit damage if one leaks, and refresh tokens solve the resulting inconvenience: a longer-lived credential agencies configure once and rely on for months.

Where OAuth sits in an advertising stack

Advertising platforms sit at the centre of an ecosystem of agencies, bid management tools, reporting dashboards and, increasingly, AI agents, all needing programmatic access without the account owner sharing a login. OAuth makes that access auditable and revocable. Calling the Google Ads API requires OAuth application verification through a Google Cloud project, a developer token, then walking a user through consent to obtain a refresh token; Google acknowledged significant delays processing those applications in February 2026, a backlog in the review layer rather than the OAuth exchange itself.

Agentic access has put the same plumbing in a new context. When Meta opened its ads Model Context Protocol server, the interface AI systems use to call advertising APIs, to all developers in July 2026, OAuth through Facebook Login for Business became one of two supported authentication paths. X's launch the following month tightened the grant further, permitting only one OAuth grant per application-user pair to stop one agency running parallel unauthorised agents against a single advertiser's credentials. The protocol's own authorisation specification, revised on July 28, 2026, deprecated Dynamic Client Registration in favour of pre-registered clients an administrator configures in advance.

Origin and evolution

OAuth began as an ad hoc fix to a specific problem. Around November 2006, Blaine Cook, then chief architect at Twitter, was building an OpenID implementation and looking for a better way to let third-party applications reach the Twitter API without users handing over their passwords. The prevailing pattern was blunt: to let a service import Flickr photos, a user typed their actual Flickr password into the importing app, which then held a permanent credential with no way to distinguish reading photos from deleting the account. Cook contacted Chris Messina, and a discussion group formed in April 2007, drawing engineers from Google and AOL, and published the first OAuth Core 1.0 specification that October. The IETF standardised a revised version as RFC 5849 in April 2010, published as an informational document rather than a binding standard, reflecting the specification's origin in informal collaboration.

OAuth 1.0's signature-based design, requiring clients to cryptographically sign every request, proved difficult to implement and prompted a full rewrite. RFC 6749, published in October 2012, obsoleted RFC 5849 and replaced request signing with bearer tokens sent over encrypted connections, lowering the implementation barrier at the cost of making a leaked token equivalent to a leaked password for its lifetime. The rewrite proved contentious: Eran Hammer, the standard's primary editor, withdrew his name from the specification in 2012 shortly before publication, citing concerns about the working group's direction. Later RFCs patched gaps rather than replacing that document: RFC 6750 defined bearer token usage, RFC 7636 introduced PKCE in 2015 for apps without a client secret, and RFC 8628 later added the device flow. An in-progress consolidation, OAuth 2.1, folds those additions into one successor specification, still a draft.

Why it matters to marketers

Nearly every integration a marketing team relies on, a bid management platform pulling Google Ads data, a dashboard reading Meta spend, a CRM pushing conversions to a DSP, authenticates through OAuth, so the standard's security properties become the marketing stack's security properties. The most consequential recent illustration did not originate in adtech. Beginning around August 8, 2025 and continuing roughly ten days, attackers stole OAuth and refresh tokens belonging to Drift, a marketing chatbot integrating with Salesforce through an app called SalesDrift. Google's Threat Intelligence Group, tracking the actor as UNC6395, found the stolen tokens let attackers query Salesforce data across hundreds of corporate instances without a username or password, since the OAuth grant itself was the only credential required. Confirmed victims included Cloudflare, Palo Alto Networks and Zscaler. Nothing about OAuth failed technically here: the tokens worked exactly as designed, and the compromise happened a layer up, in how the issuing platform protected them.

Limitations and open disputes

Bearer tokens carry a weakness by design: possession is authorisation. A token leaking into a log file or a compromised integration grants its holder everything the token was scoped to do, with no further check. Refresh tokens compound the exposure by staying valid indefinitely until revoked, exactly what made the Salesloft Drift compromise so damaging: attackers did not need to move quickly, since the stolen tokens did not expire on their own.

A long-running criticism concerns scope granularity, or its absence. Google's advertising API places its entire surface, campaigns, budgets, audiences and reporting, behind one scope; an integration needing only read access requests, and receives, the same permission as one that reallocates budget. Adoption of finer-grained scoping across major ad platforms has been inconsistent, so the practical boundary many marketing teams rely on is closer to blanket account access than a genuinely limited grant.

Distinguishing OAuth from adjacent terms

OpenID Connect is an identity layer built on OAuth 2.0 that answers who a user is, returning a signed identity token alongside the access token. OAuth alone answers only what an application can do, and says nothing about identity; conflating the two was a recognised source of early security bugs.

FedCM is a browser-level standard for the sign-in prompt, mediating federated login without third-party cookies. It answers how a user logs into a website; OAuth answers what an application can then do against an API, and the two commonly operate together.

API keys are simpler, static credentials, a single string presented on every call with no built-in expiry and no per-user consent step. OAuth tokens are scoped to a specific user's approval and can be revoked individually; several platforms have moved from API keys to OAuth to gain that granularity.

SAML is an older, XML-based standard predating OAuth that solves a distinct problem, single sign-on across an organisation's internal applications. SAML asserts identity in one signed document per session; OAuth issues a token presented repeatedly over an integration's life, and the two are not interchangeable.

Recent developments

Cloudflare shipped MCP-specific traffic detection and pre-registered OAuth client support on August 14, 2026, responding directly to the deprecation of Dynamic Client Registration. Account-security requirements tightened in parallel: Google began requiring a passkey, a device credential that cannot be shared, for sensitive Ads account actions from July 15, extending that requirement to new OAuth refresh token generation from August 5, a change that forces agencies previously running shared logins to assign individual accounts to whoever performs sensitive actions. The IAB Tech Lab's Agentic Advertising Management Protocols initiative, formally named on February 26, 2026, treats AI agent authentication as a first-class governance concern and continues tracking overlap between competing approaches; its own count found thirteen overlapping functions between its protocol and a rival Ad Context Protocol as of August 20, 2026, a sign that standardisation around agent authentication remains unsettled.

Timeline

  • November 2006: Blaine Cook begins looking for a delegated authentication method for the Twitter API
  • April 2007: OAuth discussion group forms, joined by contributors from Google and AOL
  • October 2007: OAuth Core 1.0 specification published
  • April 2010: IETF publishes OAuth 1.0 as RFC 5849, an informational document
  • 2012: Eran Hammer withdraws as primary editor of OAuth 2.0 shortly before publication
  • October 2012: RFC 6749, The OAuth 2.0 Authorization Framework, published, obsoleting RFC 5849
  • October 2012: RFC 6750, Bearer Token Usage, published alongside RFC 6749
  • 2015: RFC 7636 introduces PKCE for public clients unable to hold a client secret
  • 2019: RFC 8628 defines the device authorization grant
  • April 2024: Google moves Sign in with Google onto the FedCM standard
  • August 8-18, 2025: Attackers steal OAuth and refresh tokens from Drift in the Salesloft supply-chain breach
  • October 17, 2025: Chrome retires most Privacy Sandbox APIs; FedCM survives
  • December 9, 2025: Google launches the Data Manager API, authenticated via OAuth 2.0 with a dedicated scope
  • February 26, 2026: IAB Tech Lab formally names the Agentic Advertising Management Protocols initiative
  • April 29, 2026: Meta opens write-capable ads MCP access
  • July 15, 2026: Google requires a passkey for sensitive Google Ads account actions
  • July 16, 2026: Meta opens its ads MCP server to all developers, with OAuth via Facebook Login for Business
  • July 28, 2026: Revised MCP specification deprecates Dynamic Client Registration in favour of pre-registered OAuth clients
  • August 5, 2026: Google requires a passkey to generate new Google Ads API OAuth refresh tokens
  • August 24, 2026: X launches its ads MCP server, limiting each application-user pair to one OAuth grant

Summary

Who: Every major advertising platform operating an API - Google, Meta, Amazon, X, Microsoft - issues OAuth-based access to developers, agencies and, increasingly, AI agents. Standards bodies including the IETF, which maintains the core RFCs, and the IAB Tech Lab, which governs advertising-specific authentication protocols, oversee its evolution.

What: An open authorisation standard that lets an application obtain a scoped, revocable, time-limited access token to act on a user's behalf against an API, without that application ever holding the user's password.

When: Conceived informally in November 2006, formalised as OAuth 1.0 in 2007 and standardised as RFC 5849 in 2010, then rewritten as OAuth 2.0 and published as RFC 6749 in October 2012, with security and mobile-specific extensions such as PKCE following in 2015 and continuing through 2026.

Where: Embedded in essentially every advertising API integration, from Google Ads and Google's Data Manager API to the newer wave of AI agent connections through Model Context Protocol servers at Meta, X, Google and Amazon.

Why: OAuth exists to replace password-sharing with a narrower, auditable, revocable grant of access, letting the marketing technology ecosystem's dense web of integrations, dashboards, bid managers and now autonomous agents operate against live advertising accounts without any of them holding a real login credential.