mirror of
https://github.com/PrefectHQ/fastmcp.git
synced 2026-08-24 14:34:17 +02:00
* Add comprehensive keyring integration tests Prevents OS keyring pollution during testing by adding a global mock in conftest.py. Tests verify keyring behavior across platforms and fallback scenarios without writing to the actual system keyring. - Add global mock_keyring fixture to tests/conftest.py - Add TestOAuthProxyKeyring class with 6 keyring-specific tests - Remove try/except ImportError for keyring (now required dependency) - Add keyring extra to py-key-value-aio dependency - Clean up extraneous implementation comments in oauth_proxy.py * Update OAuth keyring documentation Update all OAuth-related documentation to reflect keyring-based key management: - Add version badges to jwt_signing_key, token_encryption_key, and client_storage parameters - Standardize "Default behavior (`None`):" formatting with backticks - Ensure consistent messaging about development-only defaults across all docs - Update oauth-proxy.mdx, oidc-proxy.mdx, http.mdx, storage-backends.mdx, and upgrade-guide.mdx
53 lines
2.3 KiB
Text
53 lines
2.3 KiB
Text
---
|
|
title: Upgrade Guide
|
|
sidebarTitle: Upgrade Guide
|
|
description: Migration instructions for upgrading between FastMCP versions
|
|
icon: up
|
|
tag: NEW
|
|
---
|
|
|
|
This guide provides migration instructions for breaking changes and major updates when upgrading between FastMCP versions.
|
|
|
|
## v2.13.0
|
|
|
|
### OAuth Token Key Management
|
|
|
|
The OAuth proxy now issues its own JWT tokens to clients instead of forwarding upstream provider tokens. This improves security by maintaining proper token audience boundaries.
|
|
|
|
**What changed:**
|
|
|
|
The OAuth proxy now implements a token factory pattern - it receives tokens from your OAuth provider (GitHub, Google, etc.), encrypts and stores them, then issues its own FastMCP JWT tokens to clients. This requires cryptographic keys for JWT signing and token encryption.
|
|
|
|
**Default behavior (development):**
|
|
|
|
By default, FastMCP automatically manages keys based on your platform:
|
|
- **Mac/Windows**: Keys are auto-managed via system keyring, surviving server restarts with zero configuration. Suitable **only** for development and local testing.
|
|
- **Linux**: Keys are ephemeral (random salt at startup, regenerated on each restart).
|
|
|
|
This works fine for development and testing where re-authentication after restart is acceptable.
|
|
|
|
**For production:**
|
|
|
|
Production deployments must provide explicit keys and use persistent storage. Add these three things:
|
|
|
|
```python
|
|
auth = GitHubProvider(
|
|
client_id=os.environ["GITHUB_CLIENT_ID"],
|
|
client_secret=os.environ["GITHUB_CLIENT_SECRET"],
|
|
base_url="https://your-server.com",
|
|
|
|
# Explicit keys (required for production)
|
|
jwt_signing_key=os.environ["JWT_SIGNING_KEY"],
|
|
token_encryption_key=os.environ["TOKEN_ENCRYPTION_KEY"],
|
|
|
|
# Persistent network storage (required for production)
|
|
client_storage=RedisStore(host="redis.example.com", port=6379)
|
|
)
|
|
```
|
|
|
|
All three are required for production. The keys accept any secret string and should be different from each other.
|
|
|
|
**More information:**
|
|
- [OAuth Token Security](/deployment/http#oauth-token-security) - Complete production setup guide
|
|
- [Key and Storage Management](/servers/auth/oauth-proxy#key-and-storage-management) - Detailed explanation of defaults and production requirements
|
|
- [OAuth Proxy Parameters](/servers/auth/oauth-proxy#configuration-parameters) - Parameter documentation
|