🎯 Feature Request: Per-User Personal Credential Store for Gateways

Summary

Allow users to store personal credentials (API keys, bearer tokens, basic auth) for specific gateways via the Admin UI and REST API. These credentials are encrypted at rest and used automatically during tool invocation when available, falling back to the shared gateway auth if not.

Problem

Some upstream APIs behind MCP gateways require per-user credentials that cannot be shared:

• APIs that only support API key auth (no OAuth2), e.g. Freshservice PM endpoints
• APIs where each user has their own license-bound API key
• Services where OAuth2 is available for some endpoints but not all

Currently, the gateway supports:

1. Shared auth (auth_value on the gateway): one credential for all users — not viable when credentials are personal
2. OAuth2 per-user tokens: works well for OAuth-capable services, but not all APIs support OAuth2

There is no mechanism for a user to store a personal, non-OAuth credential that is automatically used during tool invocation.

Proposed Solution

DB Model: UserGatewayCredential

A new table storing per-user credentials with:

• gateway_id (FK → gateways)
• app_user_email (FK → email_users)
• credential_type: api_key | bearer_token | basic_auth
• credential_value: encrypted using existing EncryptedText (Argon2id + Fernet)
• label: optional description
• Unique constraint on (gateway_id, app_user_email)

REST API (/credentials/)

• POST /credentials/{gateway_id} — store/update credential (upsert)
• GET /credentials/{gateway_id} — check credential status (no secret exposed)
• DELETE /credentials/{gateway_id} — revoke credential
• GET /credentials — list all credentials for current user

ToolService Integration

During tool invocation, the auth resolution order becomes:

1. Per-user OAuth token (existing OAuthToken) — if gateway has OAuth configured
2. Per-user personal credential (UserGatewayCredential) — NEW
3. Shared gateway auth (gateway.auth_value) — existing fallback

This applies to both the Rust execution plan path and the Python MCP tool invocation path.

Admin UI

A "🔑 Credential" button on each gateway card opens a modal where users can:

• Select credential type (API key, Bearer token, Basic auth)
• Enter and store their credential (encrypted)
• View status and revoke

Benefits

• Zero code change for API consumers — credentials are used transparently during tool invocation
• Reuses existing encryption infrastructure (EncryptedText, EncryptionService)
• Consistent with existing OAuth token pattern — same per-user concept, different auth mechanism
• Solves real-world gap — many enterprise APIs still use API key auth alongside or instead of OAuth2

Relationship to Other Issues

• Complements [FEATURE][AUTH]: Universal MCP_TOKEN passthrough - gateway-managed auth header mapping for multi-tenant BYOK #3126 (MCP_TOKEN passthrough): that approach passes tokens per-request from the client; this stores them server-side
• Related to [EPIC][SECURITY]: API Key Lifecycle Management System #2598 (API Key Lifecycle Management): this focuses specifically on per-user credential storage, not shared key rotation

Implementation Reference

We have a working implementation on our fork that can serve as a basis for an upstream PR:

• forterro/mcp-context-forge branch feature/personal-credential-store