Store OIDC client_id in config instead of hardcoding

[raballew]

TODO Comment

# TODO: store this metadata in the config

Location

python/packages/jumpstarter-cli/jumpstarter_cli/login.py, line 354

Context

@blocking
async def relogin_client(config: ClientConfigV1Alpha1):
    """Relogin into a jumpstarter instance"""
    client_id = "jumpstarter-cli"  # TODO: store this metadata in the config
    try:
        issuer = decode_jwt_issuer(config.token)
    except Exception as e:
        raise ReauthenticationFailed(f"Failed to decode JWT issuer: {e}") from e

The OIDC client_id is hardcoded as "jumpstarter-cli". It should be stored in the client config to support different OIDC configurations.

[mangelajo]

we should probably make this a login parameter instead, defaulting to jumpstarter-cli, @ambient-code, WDYT?

[ambient-code]

Investigation Findings

I investigated the codebase and found 5 locations where the OIDC client_id is hardcoded as "jumpstarter-cli":

1. python/packages/jumpstarter-cli/jumpstarter_cli/login.py line 354 — relogin_client() function (the TODO in this issue)
2. python/packages/jumpstarter-cli/jumpstarter_cli/shell.py line 91 — background token refresh during shell sessions
3. python/packages/jumpstarter-cli/jumpstarter_cli/auth.py line 124 — auth refresh CLI command
4. python/packages/jumpstarter-mcp/jumpstarter_mcp/server.py line 152 — MCP server token refresh
5. python/packages/jumpstarter-cli-common/jumpstarter_cli_common/oidc.py line 32 — default value for --client-id CLI option (this one is fine as a default)

The ClientConfigV1Alpha1 model in python/packages/jumpstarter/jumpstarter/config/client.py currently has no client_id field.

Proposed Implementation Plan

Responding to @mangelajo's suggestion — making it a login parameter that defaults to "jumpstarter-cli" and gets stored in the config makes sense. Here is the concrete plan:

1. Add client_id field to ClientConfigV1Alpha1

In python/packages/jumpstarter/jumpstarter/config/client.py, add an optional field with a default:

client_id: str = Field(default="jumpstarter-cli")

This field should be included in serialization (save/load) but excluded from display output (dump_yaml) to avoid leaking OIDC details unnecessarily, similar to how refresh_token is handled.

2. Populate client_id during login

In login.py, when building the ClientConfigV1Alpha1 object for new configs (around line 271), pass the client_id value from the CLI option:

config = ClientConfigV1Alpha1(
    ...
    client_id=client_id,
)

The client_id value already flows into the login() function via the @opt_oidc decorator (which provides a --client-id CLI option defaulting to "jumpstarter-cli"). During simplified login, it can also be overridden by the auth config endpoint response (line 206-207 already does this).

3. Read client_id from config in all re-auth paths

Replace the hardcoded "jumpstarter-cli" in all 4 locations (items 1-4 above) with config.client_id:

• login.py:354 → client_id = config.client_id
• shell.py:91 → client_id=config.client_id
• auth.py:124 → Config(issuer=issuer, client_id=config.client_id)
• server.py:152 → Config(issuer=issuer, client_id=config.client_id)

4. Backward compatibility

• No breakage for existing configs: Since the new field has default="jumpstarter-cli", existing YAML config files without a client_id key will load correctly and behave identically to today.
• Config serialization: For backward compat with older clients (similar to the leases field pattern), we could optionally skip writing client_id to YAML when it equals the default value "jumpstarter-cli".
• ExporterConfig: The exporter config does not need this field since OIDC re-auth is only relevant for client configs.

Potential Risks

• None for existing users: The default value matches the current hardcoded value, so this is fully backward compatible.
• MCP server: The MCP server in server.py also needs access to config.client_id. It already works with ClientConfigV1Alpha1 objects, so this should work naturally.