feat(auth): Implement Full-stack OIDC JWT Validation for CI/CD (SvelteKit + GitDB)

[foxkdev]

🎯 Objective

Implement an OpenID Connect (OIDC) JWT validation system to allow Secretless Auth for CI/CD runners interacting with our server. This feature requires a full-stack implementation in SvelteKit, including the authentication logic (backend) and a configuration interface (frontend UI). The configuration must be persisted using gitdb.

---

🏗️ Architecture & Tech Stack

• Framework: SvelteKit
• Backend Path: src/lib/modules/auth (or equivalent modules folder)
• Frontend Path: src/routes/settings/server-access-keys/oidc
• Storage: gitdb saving to a file named server_oidc.json

---

📋 Backend Requirements (modules/auth)

1. OIDC Middleware / Validator

• Create a handler/validator inside modules/auth that intercepts requests with the Authorization: Bearer <JWT> header on protected API routes.
• The validator must read the active OIDC configurations from gitdb (server_oidc.json).
• Dynamically retrieve and cache public keys from the provider's JWKS endpoint based on the token's iss (Issuer) claim.
• Validate:
  1. Token Signature (using cached JWKS).
  2. Expiration (exp).
  3. Target Audience (aud) against the saved configuration.
  4. Required Claims (e.g., specific repositories or workspaces) based on the configured provider.

2. Supported Providers Logic

• GitHub Actions: Validate iss, aud, and repository claim against allowed repos.
• Bitbucket Pipelines: Validate iss, aud, and workspace_uuid/repository_uuid claims.
• Custom OIDC: Validate custom iss, aud, and an optional map of custom claims.

---

🎨 UI / Frontend Requirements (settings/server-access-keys/oidc)

Create a SvelteKit page and form to manage the OIDC settings.

1. Provider Selection

• Provide a UI control (Radio buttons or Select dropdown) to choose the OIDC Provider Type:
  • GitHub Actions
  • Bitbucket Pipelines
  • Custom

2. Dynamic Form Fields

Based on the selected provider, show the following fields:

• If GitHub Actions:
  • Expected Audience (Input)
  • Allowed Repositories (Textarea or Tag Input - e.g., org/repo-name)
• If Bitbucket Pipelines:
  • Expected Audience (Input)
  • Allowed Workspace UUIDs (Textarea or Tag Input)
  • Allowed Repository UUIDs (Textarea or Tag Input)
• If Custom:
  • Issuer URL (iss) (Input)
  • JWKS Endpoint URL (Input)
  • Expected Audience (Input)
  • Required Claims (Key-Value pair inputs for custom validation)

3. State & Form Actions

• Implement the SvelteKit +page.server.ts actions to handle form submissions.
• Read existing configuration on page load to populate the form.
• Save/Update the configuration payload to gitdb.

---

💾 Storage Requirement (gitdb)

All configurations must be serialized and saved to server_oidc.json using the gitdb integration.

Expected server_oidc.json Structure Example:

{
  "providers": [
    {
      "id": "github-1",
      "type": "github",
      "enabled": true,
      "audience": "[https://api.mycompany.com](https://api.mycompany.com)",
      "allowed_repos": ["my-org/my-repo"]
    },
    {
      "id": "custom-1",
      "type": "custom",
      "enabled": true,
      "issuer": "[https://custom-auth.example.com](https://custom-auth.example.com)",
      "jwks_uri": "[https://custom-auth.example.com/.well-known/jwks](https://custom-auth.example.com/.well-known/jwks)",
      "audience": "[https://api.mycompany.com](https://api.mycompany.com)",
      "required_claims": {
        "tenant_id": "12345"
      }
    }
  ]
}