Authentication
MCP Pay includes a full OAuth 2.0 server with PKCE support, enabling MCP clients like Cursor, Claude Desktop, and other AI tools to securely connect to your paywalled MCP servers.
Supported Authentication Providers
Users can authenticate using:
- Google - Sign in with Google account
- GitHub - Sign in with GitHub account
No passwords or API keys to manage—users authenticate with their existing accounts.
How MCP Client Authentication Works
When a user adds your MCP server to their client (e.g., Cursor), the following OAuth flow occurs:
┌──────────────┐ ┌─────────────────┐ ┌──────────────────┐
│ MCP Client │────▶│ SolvaPay OAuth │────▶│ Google/GitHub │
│ (Cursor) │ │ Server │ │ Login │
└──────────────┘ └─────────────────┘ └──────────────────┘
│ │ │
│ 1. Authorize │ │
│─────────────────────▶ │
│ │ 2. Redirect to login │
│ │────────────────────────▶
│ │ │
│ │ 3. User authenticates │
│ │◀────────────────────────
│ │ │
│ 4. Auth code │ │
│◀───────────────────── │
│ │ │
│ 5. Exchange token │ │
│─────────────────────▶ │
│ │ │
│ 6. Access token │ │
│◀───────────────────── │
Flow Steps
- MCP client initiates OAuth - Client requests authorization with PKCE challenge
- Redirect to hosted login - User sees a branded login page with your provider branding
- User authenticates - User clicks "Continue with Google" or "Continue with GitHub"
- Authorization code returned - SolvaPay redirects back to the MCP client with an auth code
- Token exchange - Client exchanges the code for an access token
- Authenticated - Client can now make tool calls with the access token
Dynamic Client Registration (DCR)
MCP Pay supports Dynamic Client Registration, allowing MCP clients to automatically register themselves as OAuth clients. This means users can simply paste your proxy URL into their MCP client, and the client will handle all OAuth setup automatically.
How DCR Works
- User adds your proxy URL to their MCP client
- Client discovers the OAuth endpoints via MCP protocol
- Client registers itself using the DCR endpoint
- Client receives client credentials
- Client proceeds with standard OAuth flow
The DCR endpoint is available at your proxy URL and follows the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591).
Benefits of DCR
- Zero configuration - Users just paste a URL
- Automatic setup - No manual client ID/secret management
- Standard protocol - Works with any DCR-compatible client
Hosted Login Page
When users authenticate, they see a branded login page that includes:
- Your provider logo and name
- Your brand colors
- Google and GitHub sign-in buttons
- Automatic account creation for new users
No additional configuration is needed—the login page automatically uses your provider branding configured in Settings > Pages.
First-Time Users
When a user authenticates for the first time:
- Their account is automatically created
- They're assigned your default (free) plan
- They're redirected back to their MCP client
- They can immediately start using tools
OAuth Scopes
The OAuth server supports standard OpenID Connect scopes:
| Scope | Description |
|---|---|
openid | Required for OpenID Connect |
profile | Access to user's name and avatar |
email | Access to user's email address |
Custom Protocol Support
MCP clients often use custom URL protocols for OAuth callbacks:
cursor://- Cursor IDEclaude://- Claude Desktopvscode://- VS Code extensions
MCP Pay fully supports these custom protocols, ensuring seamless authentication across different MCP client applications. The OAuth server correctly handles redirects to these custom schemes.
Token Lifecycle
Access Tokens
- Used to authenticate tool calls
- Short-lived for security
- Automatically refreshed by MCP clients
Refresh Tokens
- Used to obtain new access tokens
- Longer-lived than access tokens
- Revoked when user logs out or subscription is cancelled
Security Considerations
PKCE (Proof Key for Code Exchange)
All OAuth flows use PKCE to prevent authorization code interception attacks. This is especially important for public clients like desktop applications.
Token Storage
- Tokens are securely stored by the MCP client
- Access tokens are never exposed in URLs
- Refresh tokens enable persistent sessions
Session Management
Users can manage their active sessions through the customer portal, including:
- Viewing connected clients
- Revoking access to specific clients
- Signing out of all sessions
Troubleshooting
Authentication Fails
If users can't authenticate:
- Verify your MCP server is active in the console
- Check that the proxy URL is correct
- Ensure the user's browser allows popups (for OAuth redirect)
Token Expired
If tool calls fail with authentication errors:
- The MCP client should automatically refresh the token
- If refresh fails, user may need to re-authenticate
- Check if the user's subscription is still active
DCR Not Working
If Dynamic Client Registration fails:
- Verify the MCP client supports DCR (RFC 7591)
- Check client is using the correct proxy URL
- Review client logs for specific error messages
Next Steps
- Hosted Pages - Configure checkout and customer portal
- Best Practices - Plan configuration and security tips