Conversation
ae12267 to
7319561
Compare
|
Very cool |
- OAuth tokens = Access Token that belongs to an OAuth client - One table (oauth_clients) + one column (oauth_client_id) - Stateless authorization codes via MessageEncryptor (60s TTL) - Implicit grants (token exists = grant, revoke = delete tokens) - Dynamic client registration for MCPs - Token lifetime: no expiry, explicit revocation only - Scope mapping: space-delimited OAuth scopes → permission enum - Security: PKCE required, loopback-only DCR, rate limiting - RFC compliance: 6749, 6750, 7636, 7591, 8252, 8414, 9728 Authorization flow with PKCE (S256 only) - Consent screen showing client name and requested scopes - Stateless authorization codes via MessageEncryptor Token endpoint - Authorization code exchange with PKCE verification - Issues Identity::AccessToken linked to OAuth client Revocation endpoint (RFC 7009) - Revoke access tokens by value - Always returns 200 per spec
Discovery endpoints (RFC 8414): - /.well-known/oauth-authorization-server - /.well-known/oauth-protected-resource Dynamic Client Registration (RFC 7591): - POST /oauth/clients for MCP clients - Loopback redirects only (127.0.0.1, localhost, [::1]) - Rate limited to 10 requests/minute
View and revoke OAuth client access at /my/connected_apps. Scoped through identity's OAuth tokens for proper authorization. Links from access tokens index for discoverability.
Use Fizzy from your favorite LLM. Even use Fizzy as a coordination bus for your agents, workflows, and skills. Fluent, fast, no bloat. Simple, purposefully bare-bones trial-balloon implementation with no new abstractions or modeling. (Rails' take on MCP should elegantly satisfy what we're after here, but this isn't the PR for it.) Model Context Protocol 2025-06-18 with streamable HTTP. Resource responses are concise to limit token bloat and keep context window creep under control. Endpoints: - GET /.well-known/mcp.json - Discovery with OAuth server reference - POST /mcp - JSON-RPC requests with bearer token authentication Tools (create_board, create_card, update_card, move_card) for workspace management. Resources for reading accounts, boards, and cards via fizzy:// URI scheme. Builds on OAuth 2.1 support for seamless authentication.
|
Is this going to get merged in soon? Any expected timeframe? |
MCPs eat a ton of context and don't integrate cleanly with RESTful APIs. But LLMs are great at operating CLI tooling! So for coding assistants, most folks are moving to skills and CLIs over MCPs: #2358 (@robzolkos has a great Fizzy CLI and skill you can use today.) However, for non-CLI and non-local LLM integration, MCP remains the only option. We're weighing whether it's worth the clunky RPC layer before committing to it. |
|
hey @jeremy I just synced upstream with our fork and was looking at this (again 😄). At ZAR we use fizzy, and we did add similar boilerplate . under load we had hiccups and connection drop. Then we found ActionMCP which the author helped implement in our apps. I would be happy to copy our local code to align fizzy codebase, so we don't have to keep managing the divergence and open a clean PR instead. |
|
Pursuing this outside of the main Fizzy app. Stay tuned. |
4 participants
Use Fizzy from your favorite LLM. Even use Fizzy as a coordination bus for your agents, workflows, and skills. Fluent, fast, no bloat.
This is a simple, purposefully bare-bones trial-balloon implementation with no new abstractions or modeling. (Rails' take on MCP should elegantly satisfy what we're after here, but this isn't the PR for it.)
Model Context Protocol 2025-06-18 with streamable HTTP. Resource responses are concise to limit token bloat and keep context window creep under control.
Endpoints:
Tools (create_board, create_card, update_card, move_card) for workspace management. Resources for reading accounts, boards, and cards via fizzy:// URI scheme.
Builds on OAuth 2.1 support for seamless authentication: #2296