Security Best Practices

This guide outlines security best practices when using oauth-mcp-proxy in production.


πŸ”’ Secrets Management

Never Commit Secrets

❌ BAD:

oauth.WithOAuth(mux, &oauth.Config{
    JWTSecret: []byte("my-secret-key"),  // Committed to git!
    ClientSecret: "hardcoded-secret",     // Committed to git!
})

βœ… GOOD:

oauth.WithOAuth(mux, &oauth.Config{
    JWTSecret:    []byte(os.Getenv("JWT_SECRET")),
    ClientSecret: os.Getenv("OAUTH_CLIENT_SECRET"),
})

Environment Variables

# .env (add to .gitignore!)
JWT_SECRET=your-random-32-byte-secret-key-here
OAUTH_CLIENT_ID=your-client-id
OAUTH_CLIENT_SECRET=your-client-secret
OAUTH_ISSUER=https://yourcompany.okta.com

Load with library like godotenv:

.gitignore


πŸ” JWT Secret Strength (HMAC Provider)

Minimum Requirements

Validation

Rotation

  • Rotate every: 90 days recommended

  • Process: Generate new secret β†’ Update config β†’ Deploy β†’ Update token generators

  • Zero downtime: Temporarily accept both old and new secrets during rotation


🌐 HTTPS in Production

Always Use TLS

❌ NEVER in production:

βœ… Production:

Get Certificates

Development:

Production:

Certificate Management


🎯 Audience Validation

Why Audience Matters

Prevents token reuse across services:

Token for Service A cannot be used on Service B (even with same issuer).

Configuration

HMAC Provider:

OIDC Providers:

  • Okta: Configure custom audience in auth server claims

  • Google: Use Client ID as audience

  • Azure: Use Application ID or custom App ID URI

Validation


πŸ”„ Token Caching & Expiration

Cache Behavior

  • Cache TTL: 5 minutes (hardcoded in v0.1.0)

  • Cache scope: Per Server instance

  • Cache key: SHA-256 hash of token

Token Expiration Recommendations

User tokens:

  • Short-lived: 1 hour

  • Refresh tokens: 7-30 days

  • Reason: Limits damage if compromised

Service tokens:

  • Medium-lived: 6-24 hours

  • Reason: Balance between security and token refresh overhead


πŸ›‘οΈ PKCE (Proof Key for Code Exchange)

Automatic Protection

oauth-mcp-proxy automatically supports PKCE (RFC 7636):

  • Prevents authorization code interception attacks

  • Required for public clients (mobile, desktop, browser)

  • Automatically validated when code_challenge provided

No Configuration Needed

PKCE is automatically enabled when client provides:

  • code_challenge parameter in /oauth/authorize

  • code_verifier parameter in /oauth/token


πŸšͺ Redirect URI Security

Native Mode (Client OAuth)

Localhost only for security:

Proxy Mode (Server OAuth)

Allowlist configuration:

Security checks:

  • HTTPS required for non-localhost

  • No fragment allowed (per OAuth 2.0 spec)

  • Exact match validation (no wildcards)


🎫 Token Security

Token Storage (Client Side)

Browser:

  • Use httpOnly cookies or sessionStorage (NOT localStorage)

  • Clear on logout

Mobile/Desktop:

  • Use OS keychain (macOS Keychain, Windows Credential Manager)

  • Never store in plain text files

CLI Tools:

  • Store in encrypted config files

  • Use OS-specific secure storage when possible

Token Transmission

Always use Authorization header:

Never:

  • In URL query parameters (logged in web servers)

  • In cookies without httpOnly flag

  • In localStorage (XSS vulnerable)


πŸ” Logging & Monitoring

What Gets Logged

oauth-mcp-proxy logs (with custom logger or default):

Info Level:

  • Authorization requests

  • Successful authentications

  • Token cache hits

Warn Level:

  • Security violations (invalid redirects)

  • Configuration issues

Error Level:

  • Token validation failures

  • OAuth provider errors

What NOT to Log

βœ… Safe: Token hash (SHA-256)

❌ NEVER log: Full tokens

Custom Logger for Production


🚨 Rate Limiting

Protect OAuth Endpoints


πŸ” Security Headers

OAuth handler automatically adds security headers:

Add application-level headers:


πŸ“‹ Security Checklist

Pre-Production

Regular Maintenance


🚩 Security Incidents

Token Compromise

If JWT secret (HMAC) leaked:

  1. Generate new secret immediately

  2. Update config and redeploy

  3. All existing tokens invalidated (users must re-auth)

  4. Review logs for suspicious activity

If client secret (OIDC) leaked:

  1. Revoke in OAuth provider (Okta/Google/Azure)

  2. Generate new secret

  3. Update config and redeploy

  4. Existing user tokens still valid (not affected)

Suspicious Activity

  • Multiple failed auth attempts β†’ Consider IP blocking

  • Unusual token usage patterns β†’ Review logs

  • Invalid redirect URI attempts β†’ Security violation logged


πŸ“š Additional Resources


🀝 Reporting Security Issues

Found a security vulnerability? Email security@[your-domain] or open a confidential GitHub Security Advisory.

Do NOT open public GitHub issues for security vulnerabilities.

Last updated

Was this helpful?