What Is OAuth 2.0? Amazon MCP Authorization Explained

OAuth 2.0 is an authorization framework that lets an Amazon seller grant a registered application limited, revocable access without sharing an Amazon password. Amazon authenticates the seller, agentcentral receives the delegated authorization, and the downstream MCP client receives only its agentcentral connection details, not the seller's Amazon credentials.

OAuth answers what an application may access; authentication determines who the user is. Treat the consent screen as one step in a controlled delegation flow, not proof that every downstream client or employee has been identified correctly.

Table of Contents

• Why OAuth Is Not Login
• What Are the Four Roles in an OAuth Flow?
  • Resource owner
  • Client
  • Authorization server
  • Resource server
• Main Grant Types and When to Use Them
  • Authorization code and PKCE
  • Client credentials
  • Device authorization
  • Refresh tokens
• Tokens, Scopes, and Revocation in Practice
• Security Best Practices for 2025 and 2026
  • Apply the baseline to MCP clients
• Connecting Seller Central to agentcentral via OAuth
• Common Pitfalls and Misconceptions
  • Signals that deserve investigation
• Operational Checklist for Safe OAuth Adoption

Why OAuth Is Not Login

Most developers misuse the phrase OAuth authentication. OAuth 2.0 was standardized in RFC 6749, published by the IETF on October 13, 2012, replacing and obsoleting OAuth 1.0, RFC 5849. The standard defines delegated authorization, not a complete identity system. RFC 6749 describes the framework's roles and token flow, while OpenID Connect supplies the identity layer when an application needs to establish who the user is.

Authentication answers, “Who is this person?” Authorization answers, “What may this application access or do for this person?” In a Seller Central connection, Amazon may authenticate the seller during the browser interaction, but the OAuth result authorizes a client to use approved resources. A separate identity assertion is needed if the client must reliably identify the seller as a user.

The Seller Central to agentcentral example makes the difference concrete:

• Authentication: Amazon verifies the seller during the sign-in interaction.
• Authorization: The seller approves access to selected Amazon resources.
• Delegation: The client receives tokens instead of the seller's password.
• Control: The seller or platform can limit, rotate, or revoke that access.

Practical rule: A consent screen proves that permission was granted for a client and resource relationship. It doesn't, by itself, prove that the application has implemented user identity correctly.

OAuth's value is that third-party access can exist without credential sharing. A seller can authorize an MCP data layer to retrieve reporting data while keeping the Amazon password outside that application. The authorization can be limited, stored separately, and revoked without changing the seller's primary password.

OAuth has evolved since RFC 6749. RFC 9700 was published in January 2025 and updates the OAuth 2.0 threat model and security guidance, demonstrating that the framework remains actively maintained more than a decade after standardization. The RFC 9700 record is particularly relevant to older integrations that still treat implicit or password-based flows as acceptable defaults.

What Are the Four Roles in an OAuth Flow?

OAuth becomes easier to operate when each participant has one job. In the Seller Central to agentcentral flow, the four roles separate identity verification, permission issuance, data hosting, and client behavior.

Resource owner

The resource owner is the Amazon seller or business account owner whose protected data sits in Seller Central and related Amazon services. This role controls whether a client receives permission. An agency operator may initiate the setup, but the relevant authorization still belongs to the seller or account holder with authority to approve the connection.

Client

The client is the application requesting access. In this workflow, agentcentral can act as the hosted MCP data layer that connects clients such as Claude, ChatGPT, OpenClaw, Cursor, and other MCP-compatible systems to structured Amazon seller data. The client doesn't receive the seller's password. It receives an authorization result that it can present when requesting permitted resources.

Authorization server

The authorization server authenticates the seller during the authorization interaction, displays or applies the permission decision, and issues authorization artifacts. For Amazon selling integrations, this role is associated with Amazon's Login with Amazon and Selling Partner authorization process. It handles the authorization decision, not the seller's orders, inventory records, or advertising payloads.

Resource server

The resource server hosts the protected data and evaluates the access token presented by the client. The Selling Partner API is the relevant resource server for SP-API data. It checks whether the request is permitted before returning the requested resource or accepting an authorized operation.

A typical handoff looks like this:

1. The seller starts a connection from the client or hosted MCP setup.
2. The client sends the browser to Amazon's authorization endpoint with its registered redirect URI and requested scopes.
3. Amazon authenticates the seller and obtains consent.
4. Amazon sends an authorization code to the registered callback.
5. The client exchanges that code for tokens.
6. The client presents an access token to the resource server for an allowed API request.

The separation protects each boundary. The authorization server doesn't need to inspect API payloads, and the resource server doesn't need the seller's login credentials. The client coordinates the flow, but its authority is limited by the token and the resource server's enforcement.

This model makes scoped delegation possible. A seller can identify which application was authorized and which Amazon roles or permissions were granted. agentcentral action history records supported guarded writes; read activity and other downstream operations require client or server telemetry. That is materially different from handing an agency a shared password and trying to reconstruct activity from a general account history.

Main Grant Types and When to Use Them

RFC 6749 defines four core grant types, authorization code, implicit, resource owner password credentials, and client credentials. Production systems also commonly discuss device authorization and refresh-token behavior as distinct implementation patterns. The right choice depends on whether a human approves access, whether the client can protect a secret, and whether the target Amazon service supports that flow.

Authorization code and PKCE

Authorization code is the normal pattern when a seller approves access in a browser. Public OAuth clients should use PKCE when the authorization server supports or requires it, as current OAuth security guidance recommends. Amazon SP-API seller authorization follows Amazon's registered Login with Amazon callback and state workflow, so implement Amazon's documented parameters rather than adding unsupported fields. See the Selling Partner authorization workflow.

agentcentral handles the seller-facing Amazon exchange. Claude, ChatGPT, Cursor, and other downstream MCP clients use the agentcentral authentication path instead of receiving Amazon tokens.

Client credentials

Client credentials fit a backend service calling another backend without a human resource owner in the request. A scheduled inventory synchronization service might use this pattern for an application-owned API, but it isn't a substitute for seller authorization to private Seller Central data. If a workflow needs the seller's orders or reports, the application needs a user or account delegation model supported by the target API.

Device authorization

Device code is useful for a terminal, constrained environment, or device that can't present a conventional browser. A developer working from a headless environment may start authorization in the terminal and complete consent on another device. The separation creates phishing risk, so teams should enable it only when the identity provider supports it and the operational need is clear.

Refresh tokens

A refresh token lets a client request new access tokens without asking the seller to authorize again. It supports long-running MCP connections, but its longevity makes it sensitive. Refresh-token guidance explains that short-lived access tokens combined with refresh tokens can allow passive revocation after the current access token expires.

The implicit and password grants should not be selected for new deployments. Modern guidance treats them as unsafe legacy patterns, particularly for public clients and seller-facing integrations.

Tokens, Scopes, and Revocation in Practice

OAuth issues credentials, not identities. An access token is presented to a resource server for a permitted request. A refresh token is used to obtain another access token without forcing the seller through the consent interaction again. Since a refresh token is longer-lived, it normally deserves stronger protection than the access token it renews.

Bearer semantics raise the operational stakes. OAuth bearer-token guidance explains that any party possessing a bearer token can use it without proving possession of a cryptographic key. Tokens therefore belong in protected transport and storage, never in URLs or routine logs.

A scope is a capability boundary, not a user identity. A scope such as sellingpartnerapi::orders:read describes a narrow category of permitted access. It doesn't establish which employee is using the client, whether the employee still works for the seller, or whether the client's internal authorization model is correct.

That distinction matters for an MCP client. SP-API application roles and seller authorization govern Amazon access; agentcentral key-level domain and tool scopes separately govern what the downstream client can use. Configure only the tools required for the workflow, as described in agentcentral API key scoping.

Sender-constrained tokens reduce replay risk by binding a token to a client-held key. DPoP and mTLS are examples. They don't remove the need for secure storage, exact redirect validation, or careful scope design, but they make a stolen token less useful when the thief lacks the associated key.

Revocation needs an operator-visible outcome. If a seller disconnects the Amazon account or rotates an LWA credential, the integration should stop obtaining new access tokens, mark the connection unusable, and prevent downstream requests after existing access expires. A platform can also invalidate its own client credentials after suspicious activity. The most common integration failures often arise from scope mismatches, incorrect resource audiences, or stale connection state, not only from token theft. Operators should read the returned authorization context and audit records instead of interpreting every 401 as a password problem.

Security Best Practices for 2025 and 2026

A current OAuth baseline starts with PKCE on every public-client authorization-code flow. A local MCP client, browser-based application, or developer tool can't safely rely on a client secret stored on the seller's machine. PKCE links the authorization request to the later code exchange, reducing the value of an intercepted code.

Use exact redirect URI matching. A registered callback should match the request precisely, with no wildcard pattern that lets a rogue browser extension or modified client redirect the authorization code elsewhere. The same rule applies to staging and production. Separate registrations reduce the chance that a test callback receives a live seller authorization.

Apply the baseline to MCP clients

• Keep access tokens short-lived: A token that leaks from a notebook, process snapshot, or debug output should have limited utility.
• Rotate refresh tokens: Replace the refresh token during renewal where the provider supports rotation, and detect reuse of an older token.
• Use sender constraints where possible: mTLS can suit controlled first-party services, while DPoP can help browser-based agents bind requests to a client key.
• Reject legacy grants: The implicit and resource owner password credential grants should not be accepted as new defaults.
• Protect storage: Keep refresh tokens in a server-side vault when possible. Avoid browser localStorage for long-lived credentials.
• Control logs: Redact authorization codes, access tokens, refresh tokens, and sensitive JWT contents from application logs.

RFC 9700 consolidates current security guidance and supersedes RFC 6819. The OAuth security best-practice summary recommends PKCE, exact redirect matching, avoiding implicit and password grants, considering PAR for high-security deployments, and using sender-constrained tokens where possible.

For Amazon sellers, each control maps to a recognizable risk. A shared agency laptop can retain browser state, a leaked notebook can expose a credential, and a rogue extension can interfere with redirects. The MCP server security guidance gives teams a broader operational framework for protecting the MCP boundary, tool access, and audit records around these integrations.

Connecting Seller Central to agentcentral via OAuth

The connection starts when a seller selects Connect Amazon Account in an agentcentral dashboard or another authorized MCP setup. The browser opens Amazon's authorization URL with the requested Selling Partner permissions, which may cover areas such as notifications, orders, and reports. The seller remains on Amazon's sign-in and consent surface while the client waits for the result.

The end-to-end sequence is straightforward:

1. Connection request: The seller starts the connection in the hosted MCP environment.
2. Amazon redirect: The browser goes to Amazon's secure authorization and login experience.
3. Seller approval: Amazon authenticates the seller and displays the requested permissions.
4. Authorization code: The seller allows access, and Amazon redirects the browser to the registered callback with a short-lived code.
5. Token exchange: agentcentral exchanges the code for tokens, stores the refresh credential securely, and confirms the connection.

The callback should never treat the presence of a code as proof that an arbitrary user is authorized inside the application. The server must validate state, confirm the registered redirect, apply any provider-required PKCE check, exchange the code through the correct endpoint, and associate the resulting connection with the intended seller account.

Connection monitoring should record issuance, refresh failures, consent changes, disconnection, and credential rotation. For guarded writes, agentcentral action history records the submitted tool, target, reason, old and new values where available, and outcome. Read-call and tool-latency logs belong to the client or server observability stack; they are not part of agentcentral action history.

Operational boundary: agentcentral returns structured data, metrics, classifications, and source-provided fields. It can also expose guarded write tools with previews, idempotency controls, and old and new audit values where available, but the seller's agent or workflow decides what to do.

A seller can disconnect from Amazon or revoke the agentcentral client key. Application credentials can be rotated by authorized operators after suspicious activity. Amazon application roles and downstream tool scopes should remain narrow, expanding only when a workflow needs another resource. The Claude quickstart and setup-time guide show how the downstream MCP connection differs from the Amazon authorization step.

Common Pitfalls and Misconceptions

The first failure is calling OAuth login. A client may receive a valid delegated token without having a verified identity record for the person operating the browser. If an agent needs to know the user, the implementation needs an identity protocol and a reliable account-linking design, not just a successful consent redirect.

Broad scopes create a second problem. A seller may approve permissions that exceed the agent's actual task, then discover that a reporting workflow can access resources unrelated to reporting. A narrow scope such as sellingpartnerapi::orders:read communicates a more defensible capability boundary than a general request for every available operation.

Refresh-token storage causes another recurring exposure. Browser localStorage, plain-text notebooks, shell history, and verbose debug logs can all turn a delegated connection into a reusable credential. Server-side vault storage, redaction, rotation, and access review reduce that risk.

Signals that deserve investigation

• Unexpected continued access: A token still works after an Amazon marketplace disconnection or vendor removal.
• Misleading authorization errors: A 401 or scope error appears because the token audience, issuer, or requested resource doesn't match, not because the seller entered a wrong password.
• Agency offboarding gaps: An audit record shows access after the agency relationship ended.
• Wrong grant selection: Client credentials appear in a user-context workflow, or a password grant is used because it was easier to implement.
• Confused consent and login: The redirect is treated as identity proof, even though it only completes an authorization exchange.

OAuth “working once” proves very little. A safe integration must continue to enforce scope, audience, issuer, token storage, revocation, and audit behavior after the first successful connection. Those controls matter most when a seller changes agencies, a laptop is lost, or an MCP client is replaced.

Operational Checklist for Safe OAuth Adoption

Before approving an OAuth connection for Seller Central data, sellers, agencies, and developers should verify the following:

• Follow the provider's registered authorization flow: Use PKCE where the provider supports or requires it; use Amazon's documented callback and state workflow for SP-API seller authorization.
• Minimize access on both layers: Keep Amazon application roles and downstream agentcentral tool scopes limited to the workflow.
• Protect refresh credentials: Store them in a server-side vault, not browser storage or notebooks.
• Register exact callbacks: Reject wildcards and unregistered redirect URIs.
• Limit access-token exposure: Use short lifetimes and redact tokens from logs.
• Rotate refresh tokens: Add reuse detection and invalidate the connection after suspicious reuse.
• Log consent and revocation: Record timestamps, seller identity, client identity, scopes, and connection status.
• Review scope use: Compare granted permissions with actual tool activity during regular access reviews.
• Offboard immediately: Revoke access when an agency, employee, or vendor relationship ends.
• Validate token claims: Check issuer and audience on every JWT access token where applicable.
• Reject legacy grants: Do not accept implicit or resource owner password credentials for new integrations.

This checklist turns OAuth from a one-time login button into an operational control. The result is delegated access that remains predictable and auditable through staff turnover, vendor changes, credential rotation, and the tightening security guidance associated with current OAuth deployments.

agentcentral provides a hosted MCP data layer for connecting Claude, ChatGPT, OpenClaw, Cursor, and other MCP clients to structured Amazon Ads and Seller Central data, including inventory, orders, catalog, finance, ranking, and fulfillment records. Sellers and agencies can connect through OAuth, use scoped client keys, retrieve pre-materialized data quickly, and review guarded writes through audit logs. Visit agentcentral to connect an Amazon account and evaluate the OAuth-based MCP setup for the seller workflows that need controlled, repeatable access.