Remote MCP and OAuth: How to Let Claude and AI Clients Securely Access Your Store
Executive summary
A remote MCP server lets an AI client such as Claude connect to your store over the network and act as a signed-in user, not an anonymous visitor. The hard part is not the tools, it is authentication. This guide explains the OAuth 2.1 flow that MCP clients expect, the endpoints you need, and the security model that keeps agent access safe and scoped to each user's real permissions.
Remote MCP is not WebMCP: the distinction that avoids confusion
These are two different things, and mixing them up causes real mistakes. WebMCP runs in the shopper's browser and exposes read-first tools to an in-page agent, with no login. A remote MCP server runs on your infrastructure and is reached over the network by an MCP client like Claude, connected as an authenticated user with that user's permissions.
- Where it runs. WebMCP (in-browser): In the shopper's browser, inside your page; Remote MCP server (this guide): Hosted server, reached over the network.
- Who connects. WebMCP (in-browser): An in-browser agent, for example a browser extension; Remote MCP server (this guide): An MCP client such as Claude, connected as a user.
- Identity. WebMCP (in-browser): Anonymous visitor, current session; Remote MCP server (this guide): Authenticated user via OAuth 2.1.
- Typical use. WebMCP (in-browser): Discover products, read content, run calculators; Remote MCP server (this guide): Account-level, permissioned actions on the user's own data.
You will often want both. WebMCP gets you discovered by shopping agents. A remote MCP server lets a customer or an internal team connect their account to Claude and work with their real data. For the WebMCP side, see WebMCP pillar post.
Why connect your store to Claude at all
Because your customers and your team increasingly work inside AI clients, and they want to reach their own data there. A merchant asking Claude "what were my top ten products last week and which are low on stock" is asking for an authenticated, account-scoped answer. That only works if your store exposes a remote MCP server the client can connect to, behind a login the user already trusts.
The real problem is authentication, not tools
Exposing a tool is easy. Letting an outside AI client act as a specific user, with that user's permissions and nothing more, is the hard part. MCP clients like Claude expect a standard OAuth flow so the user can grant access without ever handing over a password, and so you can scope, expire, and revoke that access. If you get the auth layer right, the tools are straightforward. If you get it wrong, you have built a data leak.
The OAuth 2.1 flow MCP clients expect
The standard shape is OAuth 2.1 Authorization Code with PKCE, using a public client with no shared secret. In plain terms:
- Discover. The client reads your metadata from well-known URLs to learn where to register and authorize.
- Register. The client registers itself dynamically and gets a client_id, with no secret.
- Authorize. The user is sent to your site, signs in with their existing login, and clicks Allow.
- Exchange. The client swaps the returned code, plus its PKCE verifier, for an access token and a refresh token.
- Call. The client sends the access token on every request. The token represents that user, with that user's permissions.
- Refresh. Short-lived access tokens are refreshed with a rotating refresh token.
PKCE with S256 is mandatory in this model, which stops an intercepted authorization code from being usable by anyone else. Tokens are audience-bound, so a token minted for your store cannot be replayed against a different service.
The endpoints you need
A compliant remote MCP authorization layer is a small, specific set of endpoints. This is the exact set Vortex IQ built and deployed:
- /.well-known/oauth-authorization-server. Purpose: Authorization server metadata discovery; Standard: RFC 8414.
- /.well-known/oauth-protected-resource. Purpose: Protected resource metadata; Standard: RFC 9728.
- /oauth/mcp/register. Purpose: Dynamic client registration; Standard: RFC 7591.
- /oauth/mcp/authorize. Purpose: User consent in the browser; Standard: OAuth 2.1 authorization code.
- /oauth/mcp/token. Purpose: Issue and refresh tokens; Standard: RFC 6749.
- /oauth/mcp/userinfo. Purpose: Token check and whoami; Standard: OpenID-style userinfo.
Everything is discoverable, so a well-behaved client only needs your base URL to find the rest.
The security model that keeps it safe
- The token acts as the signed-in user. It carries that user's org and role permissions, and nothing more. An agent cannot do what the user could not.
- PKCE S256 is required. No client secret is used or accepted, which suits public clients like desktop AI apps.
- Tokens are audience-bound. A token minted for your store is rejected everywhere else.
- Short lives and rotation. Access tokens expire in about an hour, refresh tokens rotate on every use, and authorization codes are single-use and expire in minutes.
- Revocable. Because access is per-user and per-client, you can cut off a client without touching anyone else.
Vortex IQ shipped this: live in Claude's connector directory
This is not theory for us. The Vortex IQ connector is live and listed in Claude's official connector directory, and any Claude user can add it. It runs the exact OAuth 2.1 flow described above: you add the connector, sign in with your existing Vortex IQ login, and approve a scoped connection. We built the full set of endpoints ourselves, dynamic client registration, discovery, authorize, token, and userinfo, with audience-bound tokens and PKCE.
Connecting takes a URL. In Claude, go to Settings, Connectors, Add custom connector, and enter https://app.vortexiq.ai/mcp. In Claude Code, run claude mcp add --transport http vortexiq https://app.vortexiq.ai/mcp. See the connect guide.
Once connected, and only for data your account can already see, the connector gives Claude access to:
- Store audit runs, with health scores and completion data
- KPI libraries and trend analysis across your integrations
- Active alerts and incident summaries
- Brand DNA voice and tone guidelines
- Kanban health-fix backlogs
Every response respects your existing permissions. The token acts as you, so Claude sees only what you would see. That is the payoff of getting the OAuth layer right: real, useful access, safely scoped.
How Vortex IQ helps
Vortex IQ, the AI Operating System for ecommerce, helps you get both halves of agent access right: the in-browser WebMCP layer that gets you discovered, and the authenticated remote MCP layer that lets your team and customers reach their own data from AI clients safely. We work across Shopify, BigCommerce, Adobe Commerce, and Magento, so the auth and access model does not have to be rebuilt per platform. Start with a free store audit, or see how we monitor agent and bot traffic in Nerve Centre.
Frequently asked questions
What is a remote MCP server?
A remote MCP server is a hosted service that exposes tools to AI clients like Claude over the network. Unlike in-browser WebMCP, it authenticates the user with OAuth, so the client acts as a specific signed-in person with that person's permissions.
Why does MCP need OAuth?
Because an outside AI client must act as a specific user without ever seeing their password, and you must be able to scope, expire, and revoke that access. OAuth 2.1 with PKCE is the standard MCP clients like Claude expect, and it keeps access per-user and revocable.
What is PKCE and why is it required?
PKCE, Proof Key for Code Exchange, ties an authorization request to the client that started it, using a one-time verifier and its hash. With S256 required, an intercepted authorization code is useless to an attacker, which is essential for public clients like desktop AI apps.
Do agents get full access to my store?
No. The token represents the signed-in user and carries only that user's existing org and role permissions. An agent cannot perform an action the user could not perform themselves, and access can be revoked per client at any time.
Is this the same as connecting Claude to a database?
No. A remote MCP server exposes controlled, named tools behind authentication, not raw database access. The user consents to a scoped connection, and every call runs as that user through your own permission checks, not as an all-powerful service account.
Can I build this on any platform?
Yes. The OAuth 2.1 and MCP standards are open and platform-neutral. The work is standard auth engineering: metadata discovery, dynamic client registration, an authorize and token flow with PKCE, and audience-bound tokens. Vortex IQ can help you stand it up across platforms.
Key takeaways
- A remote MCP server lets AI clients like Claude connect to your store as an authenticated user, which is different from anonymous in-browser WebMCP.
- The hard part is authentication. MCP clients expect OAuth 2.1 Authorization Code with PKCE and a public client.
- You need a small, specific set of endpoints for discovery, registration, authorization, tokens, and a token check.
- The token must act as the signed-in user, be audience-bound, short-lived, rotating, and revocable.
- Vortex IQ has shipped this: the connector is live in Claude's official directory, using this OAuth 2.1 flow, scoped to each user's permissions.
Sources
- Vortex IQ connector in Claude's directory: https://claude.ai/directory/connectors/vortex-iq
- Vortex IQ, connect Claude guide: https://docs.vortexiq.ai/integrations/claude-mcp/connect-claude
- Model Context Protocol, official site and spec: https://modelcontextprotocol.io
- OAuth 2.1 Authorization Framework (IETF draft): https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1
- RFC 7591, OAuth 2.0 Dynamic Client Registration: https://datatracker.ietf.org/doc/html/rfc7591
- RFC 7636, Proof Key for Code Exchange (PKCE): https://datatracker.ietf.org/doc/html/rfc7636
- RFC 8707, Resource Indicators for OAuth 2.0: https://datatracker.ietf.org/doc/html/rfc8707
- RFC 8414, OAuth 2.0 Authorization Server Metadata: https://datatracker.ietf.org/doc/html/rfc8414
- RFC 9728, OAuth 2.0 Protected Resource Metadata: https://datatracker.ietf.org/doc/html/rfc9728
---