OAuth

OAuth is an authorization framework that solves a specific problem: how does a user let application A act on their data inside service B without handing application A their service-B password? Instead of sharing credentials, the user approves a scoped grant, and the application receives a token that works only for the permissions the user agreed to.

The current widely deployed version is OAuth 2.0, with OAuth 2.1 consolidating its security best practices. Almost every "Sign in with Google" or "Connect your Slack workspace" button is an OAuth flow underneath.

In the common authorization-code flow, the application redirects the user to the service's authorization server, which asks the user to approve a list of scopes — say, read-only access to their calendar. On approval, the service redirects back with a short-lived authorization code, which the application exchanges for an access token (and usually a refresh token for renewing it).

Every subsequent API request carries the access token. The service can inspect it, enforce its scopes, and the user can revoke it at any time without changing their password. Scoping and revocability are the two properties that make OAuth safer than password sharing or long-lived API keys.

MCP servers that connect to user accounts — email, calendars, project trackers, design tools — typically authenticate via OAuth. The MCP specification adopts OAuth as the standard authorization mechanism for remote servers over Streamable HTTP, so a client like Claude Desktop can walk the user through granting access the first time it connects.

For local stdio servers, the picture is looser: many still take an API key or a pre-obtained OAuth token through environment variables in the client's config file, because there is no browser-based flow to hand off to.

These three mechanisms answer different questions and frequently coexist on one server. OAuth answers "whose data may this application touch, and with what permissions?" An API key answers "which developer account is calling?" — simpler, but unscoped and harder to revoke safely. x402 answers a question neither addresses: "has this specific call been paid for?"

A practical example: an MCP server that summarizes a user's inbox might use OAuth to read the mailbox on the user's behalf, and x402 to charge the calling agent $0.02 per summary. Authorization establishes permission; payment establishes commercial terms. Confusing the two is a common design mistake — an OAuth token proves consent, not payment.

As AI agents act for users across many services, delegated authorization becomes the consent layer of the agent economy: the user grants narrow, revocable access once, and the agent operates inside those bounds. On Loomal's marketplace, listings note how each server authenticates, so you can tell at a glance whether a server needs an OAuth connection, an API key, or nothing beyond an x402 payment.