Create a generic end-user integration connection framework

[Medformatik]

Problem

Integration configuration is primarily instance-wide. Features that connect an individual user's account or data source currently need bespoke tables and services, making OAuth, secret storage, refresh, health, revocation, and account UI inconsistent.

Current state

• integration_config is unique per integration and serves administrator-managed settings.
• Better Auth has linked OSM/Mapillary accounts.
• Dawarich uses a dedicated personal_timeline_connection and encrypted credential flow.
• Integration manifests can declare credentialOwner: end-user, but the framework does not operationalize a generic per-user connection lifecycle.

Proposed solution

Add a generic end-user integration connection framework while keeping instance-level enablement and OAuth client configuration under administrator control. A connection should bind a user to an integration/provider account with encrypted credentials, declared scopes, refresh/revoke lifecycle, and privacy-safe health state.

Acceptance criteria

• Manifests distinguish instance enablement/configuration, system OAuth client secrets, and end-user connection credentials.
• A generic connection schema records user, integration, external subject, scopes, encrypted credential reference, status, timestamps, and metadata without plaintext secrets.
• The framework supports OAuth authorization-code/PKCE and API-token style connections with provider-specific adapters.
• Redirect/state/PKCE validation prevents CSRF, account-confusion, and redirect abuse.
• Server request context gives integrations an authorized user connection without exposing credentials to the browser or unrelated integrations.
• Refresh, expiry, re-consent, scope changes, revocation, provider errors, and account deletion have explicit lifecycle behavior.
• Users can connect, inspect status/scopes, reconnect, and disconnect from account settings.
• Admins can enable/disable a provider and configure the system client without seeing user tokens.
• Logs, metrics, health checks, and support diagnostics are redacted and tenant/user scoped.
• Authorization tests prevent cross-user connection lookup/use and confused-deputy requests.
• A migration/adoption plan evaluates Dawarich and linked accounts without forcing a risky flag-day rewrite.
• Developer documentation includes a reference provider and test harness.

Alternatives considered

One custom table/service per provider is initially quick but duplicates security-sensitive lifecycle code. Making all integration config user-scoped would incorrectly expose deployment-level settings.

Area

Integration framework, authentication, secret storage, account settings, API.

Dependencies

Credential and connected-data trust assumptions must remain consistent with #312.