---
title: "Call Google Cloud or Azure without a key: the while.sh docs"
url: https://while.sh/en/docs/building-blocks/federated-connections/
updated: 2026-11-09
---

# Federated connections

Your production app calls Google Cloud, Azure or another OIDC provider without any key: while signs a short-lived token, which the provider exchanges.

> You, to your agent: Let the app read BigQuery, without a service account key.

## What your agent writes

Your agent writes it in while.yaml, at the root of your app:

```yaml titre="while.yaml"
services:
  - name: web
    port: 3000
    connections: [stockage]
```

## What your app receives

Your app receives these environment variables at every deployment:

| Variable | What it holds |
|---|---|
| `<NAME>_URL` | The connection's address. while's relay adds the access token. |

## When to use it

Use it to call a cloud service without any key, through OIDC identity federation (Workload Identity Federation at Google, federated credential at Azure).

## How it works

A federated connection reaches Google Cloud, Azure or an OIDC provider without any secret. while signs a 5-minute token for a linked production app, and the provider exchanges it for an access token of one hour at most.

## What to know

Only the live version of a linked production app gets a token (`set_connection_binding`, strict approval), never a preview, a workstation or an agent. Each binding gives the exact commands to run at the provider (gcloud, az), with a condition on its exact sub: while does not run them.

A deny list refuses what creates a credential, changes permissions or runs code elsewhere. "Approve each call" grants a single-use right of 15 minutes. The trust base also includes the administrators of while's vault, and the connection's page says so.

With the box checked, approving a version of a linked production means letting it act at the provider with what was granted to its identity. A command then runs a file of the image (`node server.js`, `sh scripts/demarrer.sh`), never inline code (`sh -c`, `node -e`), and secrets arrive as files.

There are two paths to Google, and the choice belongs to a person. With a key (jwt connection, google template), a service account key is kept by while, never in the app, but it is a long-lived key, to be changed if it leaks. With OIDC identity federation (Workload Identity Federation at Google, federated credential at Azure) (federated connection), it is the same thing without any key, and only production calls Google. Federation also has a box on the binding, unchecked by default: checked, every production deployment of the project waits for the click of an approving person (someone other than the one who requests it, if there is another), and only approved code acts at Google.

## Your agent's MCP tools

Your agent handles it with the `declare_connection`, `list_connections` and `call_connection` tools.