Refresh Keycloak tokens during long-running CaPyCLI SW360 operations #241

Overview

CaPyCLI obtains a Keycloak OAuth2 access token once when a command starts and uses it for the remainder of the command execution.

Some individual CaPyCLI commands can perform large numbers of online SW360 requests and run longer than the current 10-hour access-token lifetime. Later requests may therefore use an expired token and fail.

A concrete expired-token error message is not yet available. This issue is based on an observed command duration exceeding the configured token lifetime.

Goal

Provide a general, centralized solution for renewing Keycloak client-credentials tokens during long-running CaPyCLI commands that access SW360.

The solution should apply only when CaPyCLI has client credentials and can obtain a replacement token. A caller-supplied bearer token cannot be refreshed by CaPyCLI.

Initial implementation plan

1. Introduce a centralized token lifecycle abstraction for client-credentials authentication that retains the client ID, client secret, access mode, and token expiry.
2. Refresh the token shortly before expiry and transparently update or safely recreate the active SW360 client/session.
3. On 401 Unauthorized, refresh the token once and retry the failed request once, without retrying unrelated failures.
4. Preserve the existing behavior for caller-supplied bearer tokens.
5. Ensure write operations cannot unintentionally repeat a completed non-idempotent request.
6. Add automated tests for proactive renewal, 401 renewal and retry, refresh failures, read/write behavior, and non-disclosure of sensitive values.
7. Document the behavior and known limitations.

Acceptance Criteria

• Long-running CaPyCLI commands using -client_id and -client_secret continue to access SW360 after the original token expires.
• Token refresh is implemented in a shared layer rather than separately in individual commands.
• CaPyCLI refreshes the token shortly before expiry when expiry information is available.
• A 401 Unauthorized response causes at most one token refresh and retry of the failed request.
• Caller-provided bearer tokens continue to work unchanged and are not treated as refreshable.
• Write operations are not retried where doing so could duplicate a completed non-idempotent operation.
• Client secrets and bearer tokens are not written to logs, exceptions, or diagnostic output.
• Automated tests cover the token lifecycle and retry behavior.