Skip to content

data-app: extend --auth flag to OIDC / GitHub OAuth / GitLab OAuth / JumpCloud / Auth0 #241

@ottomansky

Description

@ottomansky

Status snapshot per provider (as of v0.28.0)

Provider Status Notes
--auth password ✅ addressed (v0.27.0, behaviour unchanged in v0.28.0) Mints a 20-char hex simpleAuth password. Retrievable via kbagent data-app password (Manage token) or the UI's Authentication tab.
--auth public ✅ addressed (v0.28.0) Writes the canonical noneProxyAuthorization shape (auth_providers: [] + auth_rules: [{auth_required: false}]). v0.27.0 wrote NO authorization key, leaving the app-proxy unable to route (HTTP 503). Fixed live-validated end-to-end.
--auth oidc ⏸ deferred to this issue Generic OIDC provider (Auth0, Google, Microsoft Entra ID, Okta, custom). Per-provider config schema needs design: issuer_url, client_id, client_secret (encrypted), allowed_roles, etc.
--auth github ⏸ deferred to this issue GitHub OAuth with optional org / team / repository restrictions.
--auth gitlab ⏸ deferred to this issue GitLab OAuth with optional group / project / role restrictions; supports self-hosted instances via issuer_url.
--auth jumpcloud ⏸ deferred to this issue JumpCloud OIDC with optional role-based access.

Why the deferral

The v0.28.0 PR scope was already expanded once during live validation (the --auth public fix was added after a HTTP 503 surfaced on a real test app). Adding the SSO/OAuth providers in the same PR would require:

  • Per-provider config schema design (each provider has different required fields).
  • Encrypted-secret handling for client_secret values (similar to --git-pat-encrypted's flow but plumbed into the auth block).
  • Per-provider CLI flag surface (e.g. --auth-issuer-url, --auth-client-id, --auth-client-secret-env, --auth-allowed-roles, --auth-github-orgs, …) — at least 5–8 new flags depending on which providers ship.
  • Live validation against each provider type (each adds an external service dependency to the test plan).

That's a separate design pass. The v0.28.0 PR keeps the --auth enum at {password, public}; v0.27.0's behaviour for password is unchanged, and public is now correct.

Reference: canonical config shapes per provider

Public-source (anyone can read): keboola/job-queue-job-configuration AppProxyDefinition.php — defines the schema for auth_providers (each entry has id, type, optional allowed_roles, plus provider-specific extra keys) and auth_rules (rule trees with auth_required and a list of provider IDs in auth). The validator's invariants (e.g. when auth_required=false, auth MUST NOT be set) are the authoritative shape constraints.

Internal-source (Keboola org members): the keboola/ui repo's apps/kbc-ui/src/scripts/modules/data-apps/constants.ts exports per-provider input schemas in OIDC_PROVIDERS and the canonical noneProxyAuthorization constant. That repo is private; org members can read it directly. External contributors should rely on the public AppProxyDefinition.php schema and the v0.28.0 implementation in kbagent's _build_public_auth_block / _build_simple_auth_block as worked examples.

Acceptance criteria for the follow-up PR

  • One new --auth enum value per provider (oidc, github, gitlab, jumpcloud).
  • Per-provider flags driven by the provider's required-fields surface.
  • client_secret flows through EncryptService like --git-pat-encrypted (per-project KMS, fail-closed).
  • kbagent data-app validate-repo (also from v0.28.0) is unaffected by the auth-mode choice.
  • New (since vX.Y.Z) gotchas.md entry per provider; keboola-expert.md matrix gains a row per provider.
  • Live-validated end-to-end against at least the simplest provider (likely github), with a smoke run for one OIDC provider (Google or Microsoft Entra ID).

Linked from v0.28.0 PR

This issue is linked from the v0.28.0 PR under "Out of scope". Same orphan-prevention contract as issue #240 (logs / auto-log-dump): filed BEFORE merge so the deferred surfaces don't go invisible.

Suggested labels

enhancement, plus an area:data-app label if/when the maintainer adds one. (Could not apply labels via gh issue create due to repo permissions on this org.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions