feat(auth): add Workload Identity Federation (OIDC) support

[philross]

Description

Adds Workload Identity Federation (OIDC) support so CI/CD pipelines can authenticate without long-lived service account key files. The CLI exchanges a short-lived OIDC token for a STACKIT access token using the go SDK's WIF flow.

• New internal/pkg/auth/auth.go with env-var helpers (STACKIT_USE_OIDC, STACKIT_SERVICE_ACCOUNT_EMAIL, STACKIT_SERVICE_ACCOUNT_FEDERATED_TOKEN)
• Auto-detects token source: env var → GitHub Actions → Azure Pipelines
• No credentials are written to disk in WIF mode
• Updated AUTHENTICATION.md with setup guide

relates to #1327

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)

[philross]

Before I continue working on this feature: Is the introduction of environment variables (STACKIT_USE_OIDC, STACKIT_SERVICE_ACCOUNT_EMAIL, STACKIT_SERVICE_ACCOUNT_FEDERATED_TOKEN) mentioned in #1327 the right approach, or should CLI flags (e.g. --use-oidc) be added instead?

[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.

[philross]

Not stale, @GokceGK could you help route this to the right person/team to get an initial response on the question above?

[GokceGK]

Hi @philross,

thanks for starting this contribution. I will check your question and get back to you asap.

Regards,
Gökce from the STACKIT Developer Tools Team

[GokceGK]

Hi @philross,

you can use env variables, but please align them with the STACKIT Terraform Provider.

Regards,
Gökce from the STACKIT Developer Tools Team

[philross]

Thanks @GokceGK,

According to https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs/guides/workload_identity_federation, STACKIT_USE_OIDC and STACKIT_SERVICE_ACCOUNT_EMAIL are already compliant with the STACKIT Terraform Provider convention. In the case of STACKIT_SERVICE_ACCOUNT_FEDERATED_TOKEN, the docs just mention using service_account_federated_token in the provider configuration. But since the naming is consistent I think keeping STACKIT_SERVICE_ACCOUNT_FEDERATED_TOKEN should be fine.

[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.

[philross]

Not stale

[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.

[Fyusel]

This name is confusing here: OIDC is not set but the name implies that it is set

[philross]

You are right, the test does not make too much sense as is.
TestParseInput currently validates flag parsing only and does not consider environment variables, which would be needed to test the OIDC setup. Would you prefer that we extend this function/test scope to include env vars, or would it be better to keep parseInput focused on flags and add a separate OIDC-focused test in activate_service_account_test.go ?

[Fyusel]

I would keep TestParseInput as is. You already added tests to oidc_test.go to check the correct handling of the oidc flag, right?

[Fyusel]

I checked the TFP implementation against this implementation and found one thing which is different.

The TFP implementation allows to provide a use_oidc in the provider configuration. If this is set this has higher priority (than the environment variable).

See: https://github.com/stackitcloud/terraform-provider-stackit/blob/main/docs/index.md#authentication

1. Explicit configuration, e.g. by setting the field `use_oidc` in the provider block (see example below)
2. Environment variable, e.g. by setting `STACKIT_USE_OIDC`
3. Credentials file

In order to use the same mechanism here we need to add a cli flag as well (if provided -> cli flag has prio, if not environment variable is taken).