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

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[bt701]

While this may be a different flow for interactivity, it would be nice if these were exposed to codespaces prebuilds. These seem to run actions, but dont expose the endpoints.

It makes prebuilds a bit of a pain, you can't prebuild anything with modern auth, and all our package services are doing that in interactive and GH actions, but codespaces prebuild you need opaque tokens.

[Luke-Corwin]

I’m testing Azure workload identity federation from GitHub Codespaces and noticed that the OIDC-related environment variables available in GitHub Actions (ACTIONS_ID_TOKEN_REQUEST_URL and ACTIONS_ID_TOKEN_REQUEST_TOKEN) don’t appear to be exposed in Codespaces.

As a result, I haven’t been able to use Azure federated credentials from a Codespace, even though the same repository, Azure identity, and configuration work correctly from GitHub Actions.

This seems to prevent secretless authentication scenarios such as:

• Azure workload identity federation
• User-assigned managed identities with federated credentials
• Non-interactive Azure authentication without client secrets

For organizations that restrict or prohibit long-lived secrets in development environments, this creates a significant gap between Actions and Codespaces.

I’m curious whether this is an intentional limitation of Codespaces or simply functionality that hasn’t been implemented yet.

If OIDC tokens are not expected to be available in Codespaces, what is the recommended approach for authenticating to Azure in a Codespace environment while avoiding stored secrets?

And if this is a known limitation, is there any roadmap or discussion around bringing OIDC support in Codespaces closer to feature parity with GitHub Actions?

Would appreciate any guidance from the GitHub or Azure teams, as well as anyone who has solved this in an enterprise environment.