[waterWang]

Fixes #17600

Problem

When token-exchange-enabled is set to false, a session created by token exchange (AuthSession.fromTokenExchange) inherits the parent catalog config — including credential and exchangeEnabled=false. On refresh, OAuth2Util.refreshToken checks exchangeEnabled, finds it false, and falls back to the client_credentials flow using the inherited credential. The refreshed token now identifies the catalog client rather than the exchanged subject, silently changing the session identity.

Root cause

AuthSession.fromTokenExchange calls fromTokenResponse, which copies the parent config via AuthConfig.builder().from(parent.config()). This propagates both credential and exchangeEnabled=false to the child session. The exchangeEnabled flag was intended by #13809 to control how credential-derived sessions refresh, but applying it to token-exchange-derived sessions changes which principal the session represents.

Fix

After building the session from fromTokenResponse, clear the inherited credential and set exchangeEnabled=true on the child session. This ensures that:

• The child session always refreshes via token exchange (using the current token), not via client credentials
• The exchangeEnabled flag only affects catalog-level credential-derived sessions as intended
• The session identity is preserved across token refreshes

[uros-b]

@waterWang Is this already in progress (#17601)? cc @bharos

[bharos]

@waterWang Is this already in progress (#17601)? cc @bharos

@waterWang I already have a PR out for the fix.
Kindly review my PR, maybe we can close this as duplicate

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[github-actions]

This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time.