Critical architectural corrections to properly implement secure token brokering:
## Key Changes:
1. **Removed Dual Token Concept**: MCP server no longer generates its own JWTs.
Instead, it acts as a token broker using IdP-issued tokens with proper
audience validation.
2. **Strict Audience Isolation**:
- Tokens with `aud: "mcp-server"` can ONLY authenticate to MCP server
- Tokens with `aud: "nextcloud"` can ONLY access Nextcloud APIs
- No tokens have multiple audiences (security boundary violation)
- Compromised MCP tokens cannot access Nextcloud directly
3. **Linked Authorization Pattern**: Single OAuth flow obtains a master
refresh token capable of minting tokens for different audiences as needed.
This solves the challenge of needing both MCP authentication and Nextcloud
access from a single user authorization.
4. **Token Broker Implementation**:
- Validates incoming tokens have `audience: "mcp-server"`
- Uses stored refresh tokens to obtain `audience: "nextcloud"` tokens
- Never exposes Nextcloud tokens to MCP clients
- Maintains short-lived cache for performance
5. **PKCE and Native Client Updates**:
- Proper 302 redirects (no HTML pages)
- Complete PKCE verification in token endpoint
- IdP tokens returned directly (not MCP-generated)
6. **Security Enhancements**:
- Comprehensive audience validation examples
- Token exchange pattern documentation
- Keycloak configuration for audience mapping
- Trust boundary diagrams
This architecture maintains strict security boundaries while enabling the
MCP server to act on behalf of users for both authentication and resource
access, following OAuth best practices and enterprise security standards.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Chris Coutinho
14a8f70503