Codespaces does not expose GitHub OIDC tokens (ACTIONS_ID_TOKEN_*), blocking Azure workload identity federation

[andrescodas]

🏷️ Discussion Type

Question

Body

Problem

GitHub Codespaces does not expose GitHub OIDC token environment variables
(ACTIONS_ID_TOKEN_REQUEST_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN).

This makes Azure workload identity federation (OIDC) impossible from Codespaces,
even when Azure is correctly configured with federated credentials
(app registration or user‑assigned managed identity).

The same repository and identity work correctly in GitHub Actions.

Impact

This blocks:

• az login --identity
• Azure auth via UAMI / app + federated credentials
• Non‑interactive Azure access without secrets

This is relevant for enterprise orgs that prohibit secrets
in dev environments.

Question

Is this an intentional limitation of Codespaces?
If so, what is the recommended Azure authentication pattern for Codespaces, without secrets?
If not, is OIDC parity with Actions on the roadmap?

[davex-ai]

hey @andrescodas
GitHub Codespaces does not currently expose the OIDC token environment variables (ACTIONS_ID_TOKEN_REQUEST_URL, ACTIONS_ID_TOKEN_REQUEST_TOKEN) that are standard in GitHub Actions. While Actions can auto-generate OIDC tokens for every job to establish a security-hardened identity with cloud providers, this functionality is not natively mirrored in the default Codespaces environment. [1, 2, 3]

1. Is this an intentional limitation?

Yes, it is effectively a current platform boundary. GitHub OIDC was specifically architected for Actions workflows to provide short-lived tokens containing specific claims about a repository, branch, or job run. Because Codespaces is a persistent development environment rather than a discrete workflow run, it lacks the same automatic "per-run" token injection mechanism found in the CI/CD pipeline. [1, 2, 4, 5]

2. Recommended Secretless Azure Patterns for Codespaces

Since native Workload Identity Federation (OIDC) is blocked by the missing variables, use these alternatives for secretless auth:

• Azure CLI Interactive Login (Recommended for Individual Devs):
  For developers, the standard path is az login, which uses a browser-based flow. Once authenticated, the CLI stores a local token, allowing subsequent commands and Azure SDKs to use DefaultAzureCredential without needing environment-level secrets.
• Third-Party Identity Proxies (Enterprise Solution):
  Platforms like hoop.dev provide a bridge for Codespaces to use OIDC-like identity federation. These tools can extend OIDC trust from GitHub to cloud endpoints, allowing developers to fetch short-lived credentials automatically upon opening a Codespace without manual logins or shared secrets.
• Managed Identities (Only for Azure-Hosted Runners):
  Managed identities are the standard for service-to-service authentication. However, because Codespaces run on GitHub-managed infrastructure rather than within your Azure VNET, they cannot natively assume an Azure Managed Identity unless connected via a complex network bridge or a self-hosted runner model. [3, 6, 7, 8, 9, 10]

3. OIDC Parity Roadmap

There is no publicly committed date for full "OIDC parity" between Actions and Codespaces in official GitHub documentation. However, the community and enterprise users are actively advocating for dedicated service tags or improved identity federation to bridge this gap. [8]
Would you like a guide on configuring DefaultAzureCredential in your code to seamlessly switch between local developer login and Actions OIDC?

Pls mark as accepted answer if this helps