External Integrations (Getting Started)

Next: Split System, Previous: Command Line Utility, Up: Kiss Getting Started Guide (June 28, 2026) [Contents]

9 External Integrations ¶

Kiss ships with built-in support for connecting your application to systems beyond itself — both calling external services and being called by them — as well as integrating with modern AI tooling. This chapter notes that these facilities exist; full details, including class names, configuration, and worked examples, are in the Kiss book.

Integrating With External Systems
LLM Integration
Security

9.1 Integrating With External Systems ¶

REST Client — make HTTP calls out to third-party APIs.
REST Server — accept inbound HTTP calls from external systems and webhooks for clients that do not speak the Kiss JSON-RPC protocol.

9.2 LLM Integration ¶

LLM Providers — built-in support for OpenAI, Anthropic, and Ollama.
MCP Server — expose application tools to AI assistants via the Model Context Protocol.
MCP Client — consume tools from a remote MCP server, with optional OAuth 2.1 authentication.
Embeddings Database — vector storage for retrieval-augmented generation (RAG).

9.3 Security ¶

OAuth 2.1 Resource Server — validate bearer tokens issued either by this same Kiss app acting as the authorization server (see the next bullet) or by an external provider such as Auth0, Okta, Keycloak, Microsoft Entra, or Google. When configured, MCPServerBase subclasses automatically require valid tokens; no code change is needed. Configuration lives in application.ini; the discovery document is published at /.well-known/oauth-protected-resource.
OAuth 2.1 Authorization Server — issue tokens directly from Kiss: authorization-code flow with mandatory PKCE, token endpoint with refresh-token rotation, dynamic client registration (RFC 7591), and the RFC 8414 metadata and JWKS endpoints. Persists clients, refresh tokens, and signing keys to a private SQLite database that is independent of the application’s main database — no shared schema, no operator setup beyond pointing at a file path. Enabled by a single application.ini key.
OAuth 2.1 Client — obtain tokens from a remote OAuth 2.1 server and present them on outbound calls. Kiss drives the authorization-code + PKCE flow with automatic discovery (RFC 9728 -> RFC 8414 / OpenID Connect) and dynamic client registration when no ClientId is configured, captures the redirect at a built-in callback servlet, and refreshes access tokens automatically. Multiple remote providers are supported, each declared in its own [OAuthClient name] section of application.ini. Cached registrations and tokens are stored in the same oauth.db the authorization server uses.

Each of the three roles is inert until configured and runs independently or together. See OAuth.md at the repository root for the full how-to on all three, and the Kiss book for the in-depth treatment.