fix(cli): prefer user/api audience for mixed-aud JWTs

[SergioChan]

Summary

• handle JWT aud claims as an ordered set instead of trusting the first item in an array
• prioritize api-token-auth.chainloop and user-auth.chainloop ahead of generic chainloop when multiple audiences are present
• add a regression test for mixed-audience user tokens (["chainloop", "user-auth.chainloop"]) so user identity is selected instead of issuer fallback

Testing

• go test ./app/cli/internal/token

Related

• Fixes ERR failed to load issuer: authorization error: issuer not found: cp.chainloop #2812

[cubic-dev-ai]

No issues found across 2 files

[SergioChan]

Thanks for the checks — I force-pushed an amended commit with DCO sign-off so the DCO status should now pass.

No functional code changes were introduced in this push.

[migmartri]

Thanks for the contribution

Could you elaborate on what was the root cause of the problem?

Thanks

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for asking — root cause was in the CLI audience selection logic, not tmux itself.

Before this patch, we effectively trusted the first value when aud was an array. For affected user tokens the audience list can be mixed, e.g. ["chainloop", "user-auth.chainloop"], where the generic chainloop value may appear before the specific auth audience.

That caused the CLI to classify the token via the generic audience path and then fall back to issuer resolution (cp.chainloop), which is where the issuer not found: cp.chainloop error came from.

The fix changes audience handling to treat aud as a set and apply explicit priority (api-token-auth.chainloop / user-auth.chainloop before generic chainloop) so mixed-audience user tokens are classified correctly.

[migmartri]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[Piskoo]

The issue mentions a possible race condition between tmux sessions affecting the local config. Does this fix address the root cause? Consider adding a negative case for a multi-audience token where none match the known audiences (["unknown1", "unknown2"] → returns nil).

[SergioChan]

Good callout — thank you.

Short answer: this PR addresses the audience-selection bug in mixed-aud tokens (which surfaced as the issuer not found: cp.chainloop behavior), not tmux session coordination itself.

I’ll add the negative multi-audience case you suggested ([unknown1, unknown2] -> nil) and push an update.

[SergioChan]

Thanks for the suggestion — I’ve pushed an update that adds the requested negative multi-audience case:

• Added test case: aud = ["unknown1", "unknown2"] now asserts Parse(...) returns nil
• This complements the existing mixed-audience regression case and verifies unknown audience arrays do not get misclassified

Validation run:

• go test ./app/cli/internal/token

[migmartri]

Thanks for the contribution. But I'm still struggling to identify the root cause, because today it is not possible to have two audiences in the checkloop token. So the problem that we are solving here is non-existent.

[migmartri]

Some findings after investigating the root cause of #2812:

The user token audience (user-auth.chainloop) and API token audience (api-token-auth.chainloop) have never changed in the codebase. The control plane JWT builder (app/controlplane/pkg/jwt/user/user.go) always emits exactly one audience per token (jwt.ClaimStrings{aud}), so a token with aud: ["chainloop", "user-auth.chainloop"] cannot be produced by any version of the control plane.

The likely root cause of #2812 is a stale token + newer control plane scenario:

1. User has a cached JWT from an old control plane deployment (different HMAC secret)
2. Current control plane middleware fails HMAC validation for all standard providers (RobotAccount, APIToken, UserToken)
3. Falls through to the federated auth provider as a last resort
4. Federated provider sees iss: cp.chainloop and returns issuer not found: cp.chainloop

The fix in this PR (smarter audience selection via chooseAudience()) is a reasonable defensive improvement for hypothetical mixed-audience tokens, but likely doesn't address the actual issue reported in #2812, which is a server-side auth middleware fallthrough triggered by an invalid/stale token. The real fix for the reporter would be chainloop auth login.