Core Philosophy
When Auth Matters
Authentication in MCPs shines when you already have:- An existing API with user accounts
- A database with access control
- Scopes and permissions defined
- A working SaaS with authenticated users
Don’t create a separate auth system for MCPs. Use your existing OAuth provider — same client ID, same tenant, same everything.
The Architecture
Setting Up Authentication
Install@leanmcp/auth:
Provider-Specific Dependencies
- Clerk
- AWS Cognito
- Auth0
Provider Setup
Clerk (Recommended)
Clerk is the easiest option, especially if you plan to add payments later.AWS Cognito
If you’re using Amazon Amplify, use the same client ID and user pool:Auth0
Protecting Tools
Method-Level Protection
Class-Level Protection
Protect all methods in a service:The authUser Object
When using@Authenticated, a global authUser variable is injected containing the decoded JWT:
- Clerk
- AWS Cognito
- Auth0
Client-Side: Passing Tokens
Clients pass tokens via_meta.authorization:
Adding Payments
The Challenge
Previously, you’d pass Stripe session data to your frontend via API. With MCPs, you need to:- Create a payment session
- Return the payment URL via MCP
- Let the agent show it to the user
Using Elicitation for Payments
Trigger payment flows with elicitation:Handling Webhooks
Webhooks remain unchanged. Your existing Stripe webhook handler works the same:Checking Subscription Status
Complete Example
Error Handling
Summary
Auth Examples
See working auth examples
Elicitation Guide
Learn about elicitation
OAuth Client
Browser-based OAuth flows with PKCE
OAuth Server
Build authorization servers with provider proxy

