Refactor to support separate auth for the SDK (and thus terraform) + small bugfixes

[franklouwers]

Description

Add API Authentication for Terraform Provider Integration

This PR implements the CLI authentication feature proposed in terraform-provider-stackit#880, enabling the Terraform Provider and SDK to use CLI user credentials instead of requiring service accounts for local development. (See stackitcloud/terraform-provider-stackit#719 for the issue that triggered this as well)

Overview

Currently, the STACKIT Terraform Provider and SDK only support service account authentication (Key Flow and Token Flow), requiring users to create and manage service account credentials even for local development. This PR adds a new stackit auth api command group that allows external tools to leverage the CLI's convenient OAuth2 user authentication.

I also fixed a bug with token refresh expiration times.

Changes

This implementation follows the RFC's preferred approach: keychain storage with file-based fallback.

1. Storage Context System

Refactored the storage layer to support multiple independent credential contexts:

• CLI context: For stackit auth login (existing behavior unchanged)
• API context: For stackit auth api login (new, isolated storage)

Storage locations:

• Keychain: stackit-cli-api (macOS Keychain, Windows Credential Manager, Linux Secret Service)
• File fallback: ~/.stackit/cli-api-auth-storage.txt (base64-encoded)

2. Token Refresh Fix

Critical improvement: Fixed token refresh mechanism to use actual JWT expiration instead of session expiration:

• Before: Stored session expiry (default 2h from config), causing SDK to think tokens were valid when they'd already expired
• After: Parse and store JWT exp claim (typically 15min), enabling proper automatic token refresh

This fix applies to both stackit auth login and stackit auth api login.

3. New Commands

Added stackit auth api subcommand group:

# Authenticate for Terraform/SDK (opens browser)
stackit auth api login

# Check authentication status
stackit auth api status

# Get access token with automatic refresh
stackit auth api get-access-token

# Remove API credentials
stackit auth api logout

Benefits

• No service accounts required for local Terraform development
• Automatic token refresh with bidirectional storage sync
• Independent credentials: CLI and API can use different accounts simultaneously
• Profile support: Each profile has independent CLI and API authentication
• Secure storage: System keychain with automatic file fallback

Usage Example

# User authenticates once
$ stackit auth api login
# Opens browser, stores credentials in isolated API context

# Terraform Provider can now use these credentials
# (Requires provider update to support CLI auth - separate PR)

Implementation Notes

• Maintains full backward compatibility with existing auth flows
• No changes to stackit auth login behavior
• Storage contexts prevent credential conflicts
• Test coverage

Related

• RFC: RFC 1: CLI Authentication in other STACKIT applications (SDKs, Terraform Provider) terraform-provider-stackit#880
• Terraform provider issue: Feature Request: Support CLI Authentication Fallback in the STACKIT Terraform Provider terraform-provider-stackit#719
• Follow-up PR needed in terraform-provider-stackit to consume these credentials

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see e.g. here)
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

[JorTurFer]

Hello
Probably this is a naive question, but which is the difference between the new stackit auth api login and the old stackit auth login. I mean, they look quite similar, just for different user profiles

[franklouwers]

@JorTurFer it's not a naive question at all, and I wondered the same thing when implementing this. The RFC preferred to have a different set of keys for cli vs api use, hence the second command.

[marceljk]

@JorTurFer The intention to separate it was, that users have explicit opt-in to the CLI Auth via the CLI itself. So just because there is already an active session in the CLI from stackit auth login, it should not be used, to avoid unexpected behavior. Even if the user has to opt-in on the SDK / Terraform side, we want to give the users control over the CLI itself, if the CLI Authentication should be really be used.

[github-actions]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.

[franklouwers]

Keep

[github-actions]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.

[franklouwers]

keep

[cgoetz-inovex]

Thanks for your contribution.
Also tested the changes locally.

From my comments I'd like the docs to mention the two different contexts and to enable outputformat: YAML in get-access-token and status.

Also wishing you nice holidays!
Cheers, Carlo

[cgoetz-inovex]

another note: when updating the branch you will probably get some compile errors. Package "github.com/stackitcloud/stackit-cli/internal/cmd/params" was renamed to "github.com/stackitcloud/stackit-cli/internal/pkg/types"

[franklouwers]

Thanks @cgoetz-inovex for the review. Branch updated (force-pushed, sorry about that, my local fork was a bit of a mess from previous attempts and me forgetting to clean up at the right time)