`oc whoami --show-token` fails with ExecCredential (exec) auth plugins, e.g. `oc get-token`

Summary

oc whoami --show-token fails with:

error: no token is currently in use for this session

when the active kubeconfig context authenticates via an ExecCredential
(exec) auth provider — for example oc get-token, which is invoked through
the client-go exec credential plugin mechanism
(client.authentication.k8s.io).

Expected behavior

oc whoami --show-token should return a valid, current bearer token when the
active context is configured with an exec-based (ExecCredential) auth
provider, the same way it does for statically configured tokens.

Actual behavior

oc whoami --show-token errors out with no token is currently in use for this session instead of returning a token, even though the same kubeconfig
successfully authenticates every other oc/kubectl command against the
cluster (i.e. the exec plugin itself works fine for normal API requests).

Root cause (as I understand it)

In an exec-credential setup there is no static, long-lived bearer token
stored directly in the kubeconfig or in the in-memory client-go config, in
the form oc whoami --show-token currently expects. Instead, credentials are
obtained dynamically by invoking the configured exec plugin (e.g. oc get-token) — the same mechanism oc/kubectl already use to authenticate
every other API request. oc whoami --show-token does not invoke this exec
credential flow at all, so it has nothing to print and errors out.

Impact

Any workflow that shells out to oc whoami --show-token to obtain a bearer
token for use elsewhere (CI/CD pipelines, scripts, tools that wrap the
OpenShift/Kubernetes API, docs/automation that assume oc whoami --show-token is a reliable way to get a usable token) breaks for
clusters/users configured with ExecCredential-based authentication such as
oc get-token, even though the underlying auth mechanism is fully supported
by oc for normal API calls.

Suggested fix

Enhance oc whoami --show-token (and/or the underlying client-go/oc
credential resolution path it uses) so that when the active context is
configured with an exec-based (ExecCredential) auth provider such as oc get-token, oc invokes that plugin (respecting its caching/TTL behavior like
it does for normal requests) and returns the resulting token, rather than
only supporting statically configured tokens.

This would let oc whoami --show-token behave consistently across all
supported authentication methods, including oc get-token and other
ExecCredential providers.

Environment

• oc / OpenShift CLI (client-go exec credential plugin auth)
• Any cluster/user configured with an ExecCredential (exec-based) auth
  provider in kubeconfig (client.authentication.k8s.io), such as via oc get-token

Steps to reproduce

1. Configure a kubeconfig context to authenticate via an exec-based auth
   provider, e.g. oc get-token as the command in a
   user.exec.command/ExecConfig entry (client.authentication.k8s.io/v1).
2. Confirm normal oc/kubectl commands work against the cluster with this
   context (e.g. oc get projects), proving the exec plugin itself is
   functioning correctly.
3. Run oc whoami --show-token.
4. Observe:

   error: no token is currently in use for this session
   

Related

Filed as a Red Hat support RFE case: 04524345.

Start at the oc whoami --show-token command and trace how it resolves the current token, then compare that path with client-go's ExecCredential plugin flow. Reproduce with an oc get-token exec provider and verify normal API requests still work. Done means oc whoami --show-token invokes the configured exec provider, respects its credential behavior, and returns the resulting bearer token.